For 2011 I picked three topics to focus on: Agile up-scaling, Application Lifecycle Management versus Build Management Systems and CM in the Cloud. These seem to be to me the three things that are garnering the most Management attention these days, so it seems appropriate...

Agile
There are many reasons why “Agile” came into being, among which are: pressure to compete without having to out-source development to locations with lower per-hour costs, shorter time to market development cycles, a need for meeting customer expectations instead of just deadlines (which were often missed anyway), a transition to new programming languages, and the desire by developers to actually work a normal day. All of these except the last were primarily of interest to Management. This last is, according to the press of the time, one of the major reasons developers got behind the push.

Skip forward to today and one finds that “Agile” is being scaled up to the point where it bears little relationship to the early days. According to Wikipedia[i], Agile include the following well known methods:

• Agile Modeling
• Agile Unified Process (AUP)
• Dynamic Systems Development Method (DSDM)
• Essential Unified Process (EssUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Open Unified Process (OpenUP)
• Scrum
• Velocity tracking

And to this list I should probably add Kanban. One of the things that happens when any of these scales up, is that parts of the process that had previously been abandoned have to be reimplemented. Such things as increased documentation, multiple parallel development efforts (variants, sprints, etc.), active management, difficulty in getting the proper stakeholder feedback due to the shear increase in the number of potential stakeholders, and the need to support multiple release tracks for existing releases.

None of this means that “Agile” will be going away anytime soon. What it does mean is that increased infrastructure (tools) will be put in place to facilitate the changes and that the tools themselves will force procedures to be followed. Either that, or human resources will have to be used instead.

ALM and BMS
ALM (Application Lifecycle Management) and BMS (Build Management Systems) are often confused since an ALM includes BMS functionality, but a BMS does not support all of the functions of ALM.

BMS tools are primarily solutions to running builds of various types (for example: normal, pre-flight[ii] or Continuous Integration[iii]). Many of today's FOSS[iv] BMS systems are tailored towards the Java language and may support Ant and/or Maven “build scripts.” An example of an up-and-coming FOSS BMS is Hudson. BMS tools provide an infrastructure, or framework, in which multiple CM tool chains (including integrations to Version Control, DIET[v] and reporting tools) can coexist and that multiple codebases can be supported.

ALM tools provide all of this plus gate-keeping (electronic approval validation and capture), post-build test execution and results collection, and Release Management functionality. They also are not normally limited to a single language.

The biggest problem with ALM tools is, since they are inherently more flexible and powerful, they currently take more to set up and administer. Technically and philosophically there is no reason for both tool sets to coexist, but Management typically wants to settle on only one tool set. Since BMSs are simpler, have a lower overhead and administrative cost and are often “free,” the tendency is to use them. From there it is only a matter of time until efforts are made to either extend them to provide ALM functionality or to add additional tools to provide the missing functionality. If this happens, it will end up costing much more in the long run, even if the ALM tool set is a commercial offering.

A smaller, but no less important problem is when multiple  development efforts are ongoing and not all of them require the overhead of an ALM. This becomes a problem when development team members are responsible for setting up, configuring and administering ALM tools for their efforts instead of there being a central person or group responsible for performing these functions. Unfortunately, even when there is a CM person or group within an organization they are overloaded and don't have time to do per-project customizations. This is unfortunate from the organizational level too as it means that things like security, traceability, required retention and auditability will probably not be implemented either correctly or consistently.

CM in the Cloud
The definition of “The Cloud” is still undergoing refinement, but all seem to agree that it provides a scalable computing architecture with high reliability and availability in a hosted setting. It also seems to be trending towards the inclusion of services (also called software-as-a-service). One can think of the Cloud as being similar to virtualized systems running on blade servers in-house. Some of the touted advantages are:

• Reduced tool-chain cost
• Tool-chain maintenance
• Reduced support and administrative head count
• Provide CM tool-chains for small or transient development efforts that do not have the resources to implement the needed tools in-house
• Potentially provide CM expertise not available in-house

This all looks good, but there are corresponding disadvantages too:

• Reduced security over in-house solutions, both of communications and content
• Often requires opening holes in firewalls, etc.
• You get what you pay for – mostly
• Customized solutions are difficult, expensive or not possible

For FOSS development projects or for small, low overhead projects, using CM in the Cloud is not a bad option. For larger or multiple projects, an organization should consider bringing CM in-house as it will eventually cheaper and will be more secure.

In Summary
2011 will be an interesting year as Agile continues to grow in scale, the roles of ALMs and BMSs will continue to confuse all of us as the feature sets converge, and the Cloud becomes more of a player in CM implementations. Things to watch out for are Agile being scaled up to the point that it causes as many problems as it solves, reacting to the lower costs of BMSs instead of selecting based on actual needs, and trying to migrate existing projects to the Cloud (and back).

[i] The Wikipedia link is http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods

[ii] Pre-flight builds are those that are performed prior to allowing changes to be committed to a Version Control repository. Whether or not these builds are performed depends on a lot of conditions, including the amount of time and/or resources a build requires or if CI builds are also performed.

[iii] Continuous Integration, or CI, builds are performed any time the content of a codebase is changed. There is often a slight delay in initiating a CI build to allow multiple commits to the same codebase to be made, especially when file changes are being tracked instead of Change Sets.

[iv] FOSS – Free/Open Source Software.

[v] DIET – Defect, Issue, Enhancement Tracking. Tools in this category include Bugzilla, Jira and Rally – though Rally also fills a role as a Project Management tool.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment