The SDLC View

Let’s consider ALM from an SDLC perspective first. In Figure 1-3, you can see the different phases of a typical development project and the roles most frequently involved. Keep in mind that this is a simplified view for the sake of this discussion. We’ve also tried to fit in the different roles from the ALM process presented earlier.

First, somebody comes up with an idea based on an analysis of business needs: “Hey, wouldn’t it be great if we had a system that could help us do [whatever the idea is]?” It can also be the other way around: The idea comes first, and the business value is evaluated based on the idea.

An analysis or feasibility study is performed, costs are estimated, and (hopefully) a decision is made by IT and business management to start an IT project. A project manager (PM) is selected to be responsible for the project and begins gathering requirements with the help of business analysts, PMO decision makers, and users or others affected. The PM also starts planning the project in as much detail as possible at this moment.

When that is done, the architect begins looking at how to realize the new system, and the initial design is chosen. The initial design is evaluated and updated based on what happens during the project and how requirements change throughout the project. Development beings, including work performed by developers, user interface (UI) designers, and DBAs (and anyone else not mentioned here but important for the project).

Testing is, at least for us, something done all along the way—from requirements specification to delivered code—so it doesn’t get a separate box in Figure 1-3. We include acceptance testing by end users or stakeholders in the Development box. After the system has gone through acceptance testing, it’s delivered to Operations for use in the organization. Of course, the process doesn’t end there. This cycle is generally repeated over and over as new versions are rolled out and bug fixes are implemented.

As you can see, ALM doesn’t support a specific activity. Its purpose is to keep all activities in sync. It does this so you can focus on delivering systems that meet the needs and requirements of the business. By having an ALM process that helps you synchronize your development activities, you can determine more easily whether an activity is underperforming and thus take corrective actions.

The Service Management or Operations View

From a Service Management or Operations view, you can look at ALM as a process that focuses on the activities that are involved with the development, operation, support, and optimization of an application so that it meets the service level that has been defined for it.

When you see ALM from this perspective, it focuses on the life of an application or system in a production environment. If, in the SDLC view, the development life cycle starts with the decision to go ahead with a project, here it starts with deployment into the production environment. Once deployed, the application is controlled by the Operations crew. Bug fixes and CRs are handled by them, and they also pat it on its back to make it feel good and run smoothly.

This is a healthy way of looking at ALM in our opinion: Development and Operations are two pieces of ALM, cooperating to manage the entire ALM process. You should consider both pieces from the beginning when planning a development project; you can’t have one without the other.

The APM View

In the APM view of ALM, you see the application as a product managed as part of a portfolio of products. APM is a subset of project portfolio management (PPM).¹ Figure 1-4 illustrates this process.

This view comes from the Project Management Institute (PMI). Managing resources and the projects on which they work is very important for any organization. In Figure 1-4, you can see that the product life cycle starts with a business plan—the product is an application or system that is one part of the business plan. An idea for an application is turned into a project and is carried out through the project phases until it’s turned over to Operations as a finished product.

When business requirements change or a new release (an upgrade, in Figure 1-4) is required for some other reason, the project life cycle starts again, and a new release is handed over to Operations. After a while (maybe years), the system or application is discarded (this is called divestment , which is the opposite of investment). This view doesn’t speak specifically about the operations part or the development part of the process but should instead be seen in the light of APM.

The Unified View

Finally, there is a unified view of ALM. In this case, an effort is made to align the previous views with the business. Here you do as the CIO would do: You focus on business needs, not on separate views. You do this to improve the capacity and agility of a project from beginning to end. Figure 1-5 shows an overview of the unified ALM view of a business.

You probably recognize this figure from Figure 1-1. We want to stress that with the unified view, you need to consider all aspects—from the birth to the death of an application or a system—hence the curved arrow that indicates continuous examination of an application or system and how it benefits the business

Traceability

Some customers we’ve seen have stopped doing upgrades on systems running in production because their companies had poor or no traceability in their systems. For these customers, it was far too expensive to do upgrades because of the unexpected effects even a small change could have. The companies had no way of knowing which original requirements were implemented where in the applications. The effect was that a small change in one part of the code might affect another part, which would come as a surprise because poor traceability meant they had no way of seeing the code connection in advance. One customer claimed (as we’ve heard in discussions with many other customers) that traceability can be a major cost driver in any enterprise if not done correctly.

There must be a way to trace requirements all the way to delivered code—through architect models, design models, build scripts, unit tests, test cases, and so on—not only to make it easier to go back into the system when implementing bug fixes, but also to demonstrate that the system has delivered the things the business wants.

You also need traceability to achieve internal as well as external compliance with rules and regulations. If you develop applications for the medical industry, for example, you must comply with Food and Drug Administration (FDA) regulations. You also need traceability when CRs come in so you know where you updated the system and in which version you performed the update.

Automation of High-Level Processes

The next pillar of ALM is automation of high-level processes. All organizations have processes. For example, approval processes control handoffs between the analysis and design or build steps, or between deployment and testing. Much of this is done manually in many projects, and ALM stresses the importance of automating these tasks for a more effective and less time-consuming process. Having an automated process also decreases the error rate compared to handling the process manually.

Visibility into the Progress of Development Efforts

The third and last pillar of ALM is providing visibility into the progress of development efforts. Many managers and stakeholders have limited visibility into the progress of development projects. The visibility they have often comes from steering group meetings, during which the PM reviews the current situation. Some would argue that this limitation is good; but, if you want an effective process, you must ensure visibility.

Other interest groups, such as project members, also have limited visibility of the entire project despite being part of the project. This is often a result of the fact that reporting is difficult and can involve a lot of manual work. Daily status reports take too much time and effort to produce, especially when you have information in many repositories.

ALM 1.0

Forrester Research has introduced some very useful concepts for ALM,⁶ including different versions of ALM and ALM tools. This section looks at how Forrester defined ALM 1.0, then continues to the latest version: ALM 2.0+.

As software has become more and more complex, role specialization has increased in IT organizations. This has led to functional silos in different areas (roles), such as project management, business analysis, architecture, development, database administration, testing, and so on. As you may recall from the beginning of this chapter, you can see this in the ALM circle. Having these silos in a company isn’t a problem, but having them without any positive interaction between them is an issue.

There is always a problem when you build impenetrable walls around you. ALM vendors have driven this wall construction, because most of their tools have, historically, been developed for particular silos. For example, if you look at build-management tools, they have supported the build silo (naturally), but have little or no interaction with test and validation tools (which is strange because the first thing that usually happens in a test cycle is the build). This occurs despite the fact that interaction among roles can generate obvious synergies with great potential. You need to synchronize the ALM process to make the role-centric processes part of the overall process. This might sound obvious, but it hasn’t happened until recently.

Instead of having complete integration among the roles or disciplines mentioned at the start of this chapter, and the tools they use, there has been point-to-point integration. For example, a development tool is integrated slightly with a testing tool (or, probably, the other way around). Each tool uses its own data repository, so traceability and reporting are hard to handle in such an environment (Figure 1-7).

This point-to-point integration makes the ALM process fragile and expensive. However, this isn’t just a characteristic of ALM 1.0; it’s true for all integrations. Imagine that one tool is updated or replaced. The integration may break, and then new solutions have to be found to get it working again. This scenario can be a reality if, for example, old functions in the updated or replaced tool are obsolete and the new tool doesn’t support backward compatibility. What would happen if Microsoft Word (to take an easy example) suddenly stopped supporting older Word files? There would be more or less a riot among users until the situation was fixed. This can be hard to solve even with integration between two tools. What if you have a more complex situation, including several tools? We’ve seen projects that use six or seven tools during development, which creates a fragile solution when new versions are released.

Tools have also been centered on one discipline. In real life, a project member working as a developer, for instance, often also acts as an architect or a tester. Because the people in each of these disciplines have their own tool (or set of tools), the project member must use several tools and switch among them. It could also be that the task system is separated from the rest of the tools, so to start working on a task, a developer must first retrieve the task from the task system—perhaps they must print it out or copy and paste it—then open the requirements system to check the requirement, then look at the architecture in that system, and finally open the development tool to begin working. Hopefully, the testing tools are integrated into the development tool; otherwise, yet another tool must be used. All this switching costs valuable time that could be better put into solving the task.

Having multiple tools for each project member is obviously costly as well, because everyone needs licenses for the tools they use. Even with open-source tools that may be free of charge, you have maintenance costs, adaptions of the tools, developer costs, and so on. Maintenance can be very expensive, so you shouldn’t forget this even when the tools are free. Such a scenario can be very costly and very complex. It’s probably also fragile.

As an example, take two coworkers at a large medical company in Gothenburg. They use a mix of tools in their everyday work. We asked them to estimate how much time they needed to switch among tools and transfer information from one tool to another. They estimated they spend half an hour to an hour each day syncing their work. Usually, they’re on the lower end of that scale, but in the long run, all the switching takes a lot of time and money. Our friends also experience problems whenever they need to upgrade any of the systems they use.

One other problem with traditional ALM tools that’s worth mentioning is that vendors often add features—for example, adapting a test tool to support issue and defect management. In the issue management system, some features may have been added to support testing. Because neither tool has enough features to support both disciplines, users are confused and don’t know which tool to use. In the end, most purchase both, just to be safe, and end up with the integration issues described earlier.

ALM 2.0

Let’s look at what the emerging tools and practices (including processes and methodologies) in ALM 2.0 try to do for you. ALM is a platform for the coordination and management of development activities, not a collection of life cycle tools with locked-in and limited ALM features. Figure 1-8 and Table 1-1 summarize these efforts.

Table 1-1

Characteristics of ALM 2.0

Characteristic	Benefit
Practitioner tools assembled from plug-ins	Customers pay only for the features they need. Practitioners find the features they need more quickly.
Common services available across practitioner tools	Easier for vendors to deploy enhancements to shared features. Ensures correspondence of activities across practitioner tools.
Repository neutral	No need to migrate old assets. Better support for cross-platform development.
Use of open integration standards	Easier for customers and partners to build deeper integrations with third-party tools.
Microprocesses and macroprocesses governed by an externalized workflow	Processes are “versionable” assets. Processes can share common components.

One of the first things you can see is a focus on plug-ins. This means, from one tool, you can add the features you need to perform the tasks you want, without using several tools! If you’ve used Visual Studio, you’ve seen that it’s straightforward to add new plug-ins to the development environment. Support for the Windows Communication Foundation (WCF) and Windows Presentation Services, for example, was available as plug-ins long before support for them was added as part of Visual Studio 2008.

Having the plug-in option and making it easy for third-party vendors to write plug-ins for the tool greatly eases the integration problems discussed earlier. You can almost compare this to a smorgasbord, where you choose the things you want. So far, this has mostly been adopted by development tool vendors such as IBM and Microsoft, but more plug-ins are coming. IBM has its Rational suite of products, and Microsoft has TFS.

Another goal of ALM 2.0 is that the tools should be repository neutral. There shouldn’t be a single repository, but many, so you aren’t required to use the storage solution the vendor proposes. IBM, for example, has declared that its forthcoming ALM solution will integrate with a wide variety of repositories, such as Concurrent Versions System (CVS) and Subversion, just to mention two. This approach removes the obstacle of gathering and synchronizing data, giving you easier access to progress reports and so on. Microsoft uses an extensive set of web services and plug-ins to solve the same issue. It has one storage center (SQL Server); but, by exposing functionality through the use of web services, Microsoft has made it fairly easy to connect to other tools as well.

An open and extensible ALM solution lets companies integrate their own choice of repository into the ALM tool. Both Microsoft and IBM have solutions—data warehouse adapters—that enable existing repositories to be tied into the ALM system. A large organization that has invested in tools and repositories probably doesn’t want to change everything for a new ALM system; hence, it’s essential to have this option. Any way you choose to solve the problem will work, giving you the possibility of having a well-connected and synchronized ALM platform.

Furthermore, ALM 2.0 focuses on being built on an open integration standard. As you know, Microsoft exposes TFS functionality through web services. This isn’t documented publicly and isn’t supported by Microsoft, however, so you need to do some research and go through some trial and error to get it working. This way, you can support new tools as long as they also use an open standard, and third-party vendors have the option of writing cool and productive tools.

Process support built in to the ALM platform is another important feature. By this, we mean having automated support for the ALM process built right into the tools. You can, for instance, have the development process (RUP, Scrum, XP, and so on) automated in the tool, reminding you of each step in the process so you don’t miss creating and maintaining any deliverables or checkpoints.

In the case of TFS, this support includes having the document structure, including templates for all documents, available on the project web site as soon as a new TFS project is created. You can also imagine a tool with built-in capabilities that help you with requirements gathering and specification—for instance, letting you add requirements and specs to the tool and have them transformed into tasks that are assigned to the correct role without you having to do this manually.

An organization isn’t likely to scrap a way of working just because the new ALM tool says it can’t import that specific process. A lot of money has often been invested in developing a process, and an organization won’t want to spend the same amount again learning a new one. With ALM 2.0, it’s possible to store the ALM process in a readable format such as XML.

The benefits include the fact that the process can be easily modified, version controlled, and reported on. The ALM platform can then import the process and execute the application development process descriptions in it. Microsoft, for example, uses XML to store the development process in TFS. The process XML file describes the entire ALM process, and many different process files can coexist. This means you can choose the process template on which want to base your project when creating a new project.

It’s also important for an enterprise to have control over its project portfolio to allocate and control resources more effectively. So far, none of the ALM vendors have integrated this support into the ALM platform. There may be good reasons for this, though. For instance, although portfolio management may require data from ALM, the reverse probably isn’t the case. The good thing is that having a standards-based platform makes integration with PPM tools much easier.

ALM 2.0+

So far, not all ALM 2.0 features have been implemented by most of the major ALM tool vendors. There are various reasons for this. One is that it isn’t easy for any company to move to a single integrated suite, no matter how promising the benefits may appear. Making such a switch means changing the way you work in your development processes and maybe even throughout your company. Companies have invested in tools and practices, and spending time and money on a new platform may require considerably more investment.

For Microsoft-focused development organizations, the switch might not be as difficult, however—at least not for the developers. They already use Visual Studio, SharePoint, and many other applications in their daily life, and the switch isn’t that great. But Microsoft isn’t the only platform out there, and competitors like IBM, Serena, and HP still have some work to do to convince the market.

In addition, repository-neutral standards and services haven’t evolved over time. Microsoft, for instance, still relies on SQL Server as a repository and hasn’t built in much support for other databases or services. The same goes for most competition to TFS.

The growth of Agile development and project management in recent years has also changed the way ALM must support development teams and organizations. There has been a clear change from requirements specs to backlog-driven work, and the tools you use need to support this.

It becomes critical for ALM tools to support Agile practices such as build-and-test automation. TDD is being used with increasing frequency, and more and more developers require their tools to support this way of working. If the tools don’t do this, they’re of little use to an Agile organization. Microsoft has taken the Agile way of working to heart in the development of TFS, and this book will show you all you need to know about TFS’s support for Agile practices.

There has also been a move from traditional project management toward an Agile view in which the product owner and Scrum master require support from the tools. Backlog refinement (the art of refining requirements in the Agile world), Agile estimation and planning, and reporting—important to these roles—need to be integrated to the overall ALM solution.

The connection between Operations and Maintenance also becomes more and more important. ALM tools should integrate with the tools used by these parts of the organization.

In the report “The Time Is Right for ALM 2.0+,” Forrester Research presented the ALM 2.0+ concept, illustrated in Figure 1-9 ⁷. This report extended traditional ALM with what Forrester called ALM 2.0+. Traditional ALM covers traceability, reporting, and process automation, as you’ve seen. Forrester envisions the future of ALM also including collaboration and work planning.

We take a closer look at these topics farther down the road. But before we do that, we examine a new topic on the horizon: DevOps. DevOps is important because it has the potential to solve many ALM problems.