This is a translated version of an article that I wrote for Software Release Magazine. 

Application Lifecycle Management

In the past ten years, the costs of IT projects dropped significantly. In addition, the number of projects that turned out to be successful, rose. Nevertheless, only forty percent of all IT projects succeeds. This means that it takes less time today for a project to fail. Application Lifecycle Management (ALM) may help improve the return on projects. An efficient deployment of ALM requires the right scope and focus.

Today, many organizations regard Application Lifecycle Management (ALM) as one of the answers to their bad performing IT departments. With ALM, they try to get more grip on software development by integrating, coordinating and controlling the various phases of development. ALM guides an organization from software development until software implementation and management. Very often, an organization will limit its focus to optimizing the developer’s work processes and the communication between developers and project managers. An ALM tool is rolled out and its features are used to manage the progress of the project as well as the quality of the code. Deploying an ALM tool in this way is a step in the right direction but in practice it is not a guarantee for success. Without the right focus, software development will remain a stand alone activity without any relation to other parts of the organization, including business and operations. Additionally, research shows that companies spend on average 30 percent of their available IT budget on newly built applications. This means that they neglect an area of 70 percent, where optimization is also possible.

More return by shift in focus

With the right scope and focus ALM has much to offer. Figure 1 shows a schematic view of the lifecycle of an application that is to be developed. In this view de x-axis represents the time and the y-axis the value/cost of the application. In this figure, the extended curve shows the lifecycle of the application from development until end-of-life. The figure provides insight in the different phases of an application’s lifecycle. It also enables for determining the impact of ALM.

Figure 1. The lifecycle of an application

Reduce development costs

The lifecycle of an application starts in the first phase of development. As of the start of the project, costs are made for design, programming and testing. At this time, the application offers no value. All development costs are therefore to be regarded as costs. Often, organizations focus on these costs when deploying ALM and optimizing the software development process. Figure 1 shows however, that the development phase only accounts for a small part for the full lifecycle of the application.

Time to market

The figure also shows that the application will only add value to the organization when it has gone live. This means that the ALM activities need to be focused on getting the application (or a part of it) live as soon as possible. One of the ways to do this is using agile development methods, including iterative delivery. Shortening the time to market not only results in faster added value, it can also provide competitive advantage. In general, organizations that are first in addressing new needs or market changes profit the most from these developments. Organizations that are trend followers profit less; or even worse, they have to invest in order to stay in the market.  

Added Value

It is clear that an application will add value when it has gone live. Many organizations do no recognize this added value. ALM activities should focus on getting as much added value as possible. As the application is developed for the end-users , it is key to involve this group as much as possible in the development process. User involvement, support from the (executive) management, defining clear business goals and optimizing requirements are all equally important.

One of the ways to realize this is to optimize the communication between the user organization and IT and to create a common involvement for all stakeholders. In this way, stakeholders are better geared to state their demands. They are also better able to determine the consequences of their choices and to change priorities and requirements during the project, together with the project team. Here, it is also cost-effective to use short iterations, as changes in scope, priorities and requirements can easily be made. In this way, an organization can address new insights during the project, which may increase the added value of the application further.

Operational costs

When developing the application it is advisable to acknowledge in an early stage the need for application management. By creating consensus on the requirements for the management department, operational management costs of the application can be reduced significantly. The focus on management is paramount in an ALM approach.

Extending the lifecycle

By adding value and reducing costs, a developed application will provide return in the long run. By focusing on the value of an application and by constantly monitoring this aspect, an organization is better capable of determining the moment when value is replaced by costs. This early insight helps in deciding what to do with the application: adjust or phase out?

Phase out

When an organization decides to abandon an application, the knowledge of the application will lead to less abandoning costs. This is definitely the case when an organization combines this knowledge with the optimizations, provided by ALM in the earlier development phase of the application. An example is the right documentation on the application interface to other systems.

Figure 2. The new lifecycle of an application

The new lifecycle

Figure 2 shows the new lifecycle of the application. This is the result of broadening the ALM focus as described earlier. The green field in the figure depicts the extra return of the application. This is possible by speeding up the go-live process, a longer life of the application and more added value for the user. The red areas in the figure represent the decreased development costs and the costs for abandonment.

Priorities of an organization

Figure 2 shows that the return on ALM increases when an organization not only focuses on the development phase, but also on the other phases of an application’s lifecycle. This optimization obviously pays off, but the question is how to relate this to the goals of today’s organizations. Many organizations focus on cost reduction, compliancy and risk management. How can ALM be related to these three priorities?

Cost reduction

A too strong focus on cost reduction may well lead to an imbalance in this area, resulting in a paralyzed organization in terms of productivity. By continuously executing cost reducing measures, tools and communication channels are lost. In the end, this can affect the productivity of employees negatively. By combining cost savings and productivity improvements this issue can be addressed.

A combination of ALM activities with a so-called high-performance workplace can be the answer. The high performance workplace is a physical or virtual environment which is especially designed for knowledge and information workers. It supports them optimally in executing non-routine duties. In these duties, exploring, learning, innovating, collaborating and managing are key.

The current generation of ALM tools already pays attention to optimizing communication and collaboration between stakeholders in an IT project. This shows that the awareness on effective collaboration is growing. It also requires the focus to be placed on the process and the human aspect of collaboration. Important success factors are creating joint goals and making sure there is a shared vision of the truth.

Compliancy

The current compliancy requirements demand a high level of control. In recent years, this control is expressed in continuous process optimization. The need for a process approach led to reduction of flexibility within an organization. It is becoming increasingly difficult to address market changes and needs without losing control. The focus on processes, tools and management also led to a situation in which up to twenty percent of project costs can be allocated to the developed software. The rest of the costs are related to project support and meeting internal and external requirements. The new generation ALM tools and corresponding methods, enable an organization to meet these strict compliancy requirements without affecting flexibility. These tools provide the necessary mechanisms and means of control to link requirements, quality metrics and the solution. This makes it much easier to prove that the solution meets all requirements. The full support of agile methods within the ALM tools ensures the required flexibility.

Risk management

Experience from the past shows that risk is inherent to projects. However, the higher the risk, the higher the return, as optimists say. It is not necessary for organizations to exclude all risks. They need to assess risks continuously on the return they can provide. The collaboration in a project, the commitment from stakeholders and the combination of business and ICT knowledge enable the right assessment of risks. This may lead to a situation in which a risk that is regarded as unacceptable by individual members, is controllable or even desirable.

Conclusion

ALM is gaining in popularity. Many organizations take their first steps in this area and start to purchase ALM tools. Seemingly without thinking, they focus on the development phase. This is an excellent first step but still they should not stop here. By broadening their focus and incorporating the full lifecycle of an application in their approach, they are able to increase their return on ALM significantly. The broader approach offers more insight in the added value of the application. By combining ALM and a high performance workplace, and by putting the human aspect first, it is possible tot create an environment in which collaboration is optimized. The result is a software development process with predictable results and sufficient flexibility to contribute to the three main priorities of an organization: cost reduction, compliancy and risk management.

A few days ago I was asked by one of my colleagues why I am spending a lot of my time experimenting with Visual Studio Team System 2010 (Team Architect), Blueprints, App Arch Guide and Application Lifecycle Management (ALM) in general. He noticed me ‘living’ in VSTS 2010 CTP for some time now and he was wondering if it isn’t a bit too early for this and what I did to convice to management to let me do this. My immediate answer to this question was ‘No, it is not to early!’ and I explained that we (Inter Access) expect VS 2010 to help us optimizing our Application Lifecycle Management practice. This answer was a bit too vague for my colleague and of course the next question was how will we benefit *exactly* from investing in VSTS 2010 and ALM. Will it make our life easier?, will it makes us better people?, will it improve quality?, will it save us time?, will it save us money?

Exactly these same questions popup when discussing ALM with customers. Apparently making the business case for ALM (and/or VSTS licenses) isn’t always easy. How come?

From our experiences we learned that currently most people and organizations are relating ALM to their development activities (Software Development Lifecycle). Therefore it is only logical that this is the area where people are trying to identify their benefits (costs savings) from ALM. But is this correct? Is this focus too limited?  Shouldn’t we focus on more than only development when it comes to cost savings? Especially if we keep in mind that, on average, only 30% of the IT budget is spend on new application development (the remainder is spend on maintenance/operations)!

How come most of us still only focus on development? Is it because we still focus too much on the tools instead of facilitating collaboration between ‘Business’ ‘Development’ and ‘Operations’?

Everybody experienced in VSTS 2005 and/or VSTS 2008 will come to the conclusion that these tools mainly focus on the different roles within the development team (developer, architect, project management). Source control, unit testing and quality assurance features of these products provide us with a professional development environment and help us improving the overall quality of the products that we deliver. Work item management, a centralized store, reports, portals, etc. improve the collaboration within the development team and support project management in tracking progress, staying in control and managing risks adequately. All of this is great and potentially boost the performance of the development teams but experience learns that these benefits don’t come ‘out of the box’! Installing the tools doesn’t make the development team collaborate by default and most certainly doesn’t stimulate collaboration with the Business and Operations!

Now we know where most of us focus on for their ALM related activities, let see how this relates to the complete application lifecycle. For this we will use an the graph below were the x-axis represents time and the y-axix represents value and negative value displayed as costs.

Obviously the lifecycle of the application starts with its development. During this phase we have to make costs to design, develop and test the application. At that time the application doesn’t bring us (actually the business) any value and the complete development phase of the project only costs money. From the moment the application (parts of it?) are installed into production the appliaction starts to generate value till the moment it needs to phase out where it starts to cost money again.

What we see is, that most organizations are focusing on reducing the developments costs and (sometimes) try to shorten the time to market. Btw. it doesn’t come as a surprise that these are exactly the areas where the current releases of Visual Studio Team System focus on.

Reducing costs and make the application add value earlier is good but if we have a look at the image above we can see that the application lifecycle doesn’t end at the moment the application goes into production (where lifecycle line crosses x axis). So, wouldn’t it be great if our ALM practices help us optimize (reduce costs and/or increase value) during the remainder of the application lifecycle also?

For example, one of the things we can do to increase the business value is to practice a proper User Experience design (see this post of my colleague Andries for more info on this). By taking ‘Operations’ into account during the design and development phase of the application we can reduce operations costs during the remainder of the lifecycle. These things combined will result in an application that is more successful for a longer period of time (because it adds more value and costs less to maintain). Also, because we have done a good job developing the application, we know exactly what it does, where it is interfacing with (something VSTA 2010 will help with) and most importantly when it stops adding value which will help reducing the ‘phase out costs’ of the application.

Adding this to the graphical representation of our application lifecycle results in a graph that looks like this.

Based on this, we can now draw our new  application lifecycle which might looks something like this (dotted line is new lifecycle).

The good news is that the green area between the ‘old’ and ‘new’ lifecycle is the area were we can make money by adding extra value. The red colored areas is the place where we can make money by reducing costs. Doesn’t that look great???

Please note that ‘Reduce operations costs’ might be misunderstood from this graph. We don’t mean less value but less costs. I didn’t know how to display this correctly

Of course, all of these things don’t come by itself. We have to actually work for that to make that happen and we can’t do everything at once. In this post I am not going to detail all the steps that we can do to make that happen and where we can use the current or future tooling for. However, hopefully this last image makes it very clear that there are others areas, besides development, within the application lifecycle where we can either reduce costs or increase value. So, if anybody aks you why they should invest in ALM this image should give you a starting point for your discussion…

At least, it *did* help me explain why I should spend my time on ALM and experimenting with VSTS 2010, Blueprints and App Arch Guide

In a previous post we already mentioned Blueprints as a means for integrating architectural guidance from the p&p App Arch Guide in the VS2010 IDE. Clemens already mentioned how we can capture some of this knowledge in an item template and use the IWizard interface to populate the diagram. Now, let’s see how we can use Item Templates in a slightly different way and use them in a Blueprint to unfold a predefined architecture (Layering Diagram) in VS2010.

The first step is to capture the architectural guidance in a Layering Diagram that we can reuse. To do this we can we create a new Modeling project and add a Layering Diagram to this project.

In this diagram we can model all layers, dependencies, etc. to make it reflect our architectural guidance. Once we are done it might look something like this.

To make this diagram reusable we have to create an Item Template for it. Unfortunately VS2010 doesn’t let us select the layering diagram in the Export Template Wizard so we have to manually create an item template for our layering diagram. The easiest way to do this is to create an Item Template for another file type (i.e. C# class) and modify the ‘MyTemplate.vstempate’ file in the .zip file that VS2010 generates and add the two diagram files (.layer and .layer.diagram) to the .zip file. The modified MyTemplate.vstemplate file should look something like this.

Now we are done creating a reusable layering diagram we can integrate this with a Blueprint. (of course we can create more item templates for other architectures defined in the p&p App Arch Guide)

In this post we will not explain how to create a Blueprint from scratch but this is pretty easy. Especially after watching the How To videos. Once we have created our Blueprint we can use a Workflow Foundation based workflow to actually add our predefined layering diagram to our solution.

To do this, we first have to add a Workflow Command to our Blueprint (screen cast for more details) that will enable our Blueprint users add a layering diagram to their solution. The documentation that comes with the Blueprint Workflow Command provide us with the code we need to execute a workflow. However, this code assumes we are executing a ‘XOML only’ workflow. In our case we choose to use a codebehind for our workflow so therefor we use the ‘ExecuteWorkFlow’ method instead of the ‘ExecuteXomlWorkflow’ method. The code in your command might look like this (added some hardcoded paths instead of calls to helper class to get the correct paths).

Now that we have the command in place we have to create the actual workflow that we execute from the command. After installing Blueprints we get a few extra activities that we can use in the workflows in our Blueprint. Below we can see how this workflow might look like.

The ‘ShowDialog’ activity in this workflow is a normal ‘Code’ activity that in this case shows the (very simple) dialog that is displayed below. This dialog lets the user select the architecture that will be used in his solution.

Once the architecture is selected, the workflow continues with the ‘CheckProjectExists’ activity. This Blueprint specific activity checks if the current solution contains a ‘Modeling project’ with the name ‘Architecture’ (I am sure you can come up with a better name ;)). If not, the project is created. After that the ‘AddLayeringTemplate’ activity is executed to actually unfold the selected item template that will add the predefined layering diagram to our modeling project in our solution.

In this post we deliberately left out some implementation details that you might need to implement this yourself. However, hopefully it does explain the basic scenario of how to add some architectural guidance from p&p App Arch Guide by using Blueprints and VS2010 Layering diagrams. In future posts we will ellaborate on this scenario, share some more technical details and eventually might even end up with a working solution that we can share .

For some (experimental) work that I am currently doing with Clemens we needed a version of Blueprints that installs on the current VS 2010 CTP. I am sure every developer already knows how to modify an .MSI package by using ‘Orca’ (part of Windows SDK) so I am not going to explain in detail how to do that. However, the good news is, that if we open the Blueprints 2.1.2 CTP in Orca, replace every occurrence of ‘Visual Studio 9.0’ by ‘Visual Studio 10.0’ and save it again we are good to go. No other changes needed. The modified installer runs without issues on VS 2010 CTP and so far we haven’t found any problems with Blueprints on VS 2010.

If you are interested in the work we are doing, I suggest to go read an introductional post that Clemens just posted which describes some early ideas. Expect some more details in the next coming days, weeks, months on both Clemens blog and/or this one.