Section 1.1. Agony Versus Agility

1.1. Agony Versus Agility

In 2003, Nicolas G. Carr published the heatedly debated article "IT doesn't matter" in the Harvard Business Review, claiming that "... like electrical grids or railroads, IT would become a ubiquitous commodity." Regardless of your position on this issuewhether or not you consider enterprise IT a commodityenterprises heavily depend on the IT backbone, which is responsible for running almost all processes of modern enterprises, be they related to manufacturing, distribution, sales, customer management, accounting, or any other type of business process. Because of today's highly competitive global economy, these business processes underlie constant change: Enterprises must constantly sense changes in market conditions and swiftly adapt their strategies to reflect these changes. Therefore, it is a key requirement for modern enterprise IT that changes in company strategy be reflected quickly and efficiently in the company's IT systems, which are the backbone for executing the strategy.

This is exactly where the enterprise software dilemma starts: Today's enterprise software development almost always suffers from lack of agility and from inefficiency. This means that enterprises are not able to match business requirements onto underlying IT infrastructure fast enough, effectively limiting the capability of the enterprise to react appropriately to market demands. In addition, the inefficiency of enterprise software development means that the development that is actually done costs too much when compared to the actual output.

If we look at a typical enterprise software system, we can normally observe an initial phase of high productivity and agility, as shown in Figure 1-1. During this Green field phase, the system is built with much new functionality, and initial change requests can be implemented relatively quickly and efficiently. However, after the initial system implementation has been put in place and the first couple of change requests have been executed, the ability to make more changes to the system deteriorates dramatically, and maintenance over time becomes harder and harder.

Figure 1-1. Change requests reduce the agility of a system over time.

This stagnation phase, which almost any enterprise software system experiences over time, cannot be explained by a single reasona number of factors contribute to this phenomenon. Some of these reasons are related to software technology, such as the difficulty of making structural changes to an existing code base. However, most of the reasons are not of a technical nature but rather are related to reasons on the organizational level. For example, after the initial launch phase of a system, the project management and key domain experts are likely to move on to the next project, often leaving the maintenance of the system to less skilled maintenance workers, many times even without doing a proper hand-over. In addition, after the initial phase of euphoria about the new system, it might lose its internal lobby over time and thus the necessary political support within the organization. Tight project budgets often mean that fixes and changes cannot be done properly and are only done on an ad-hoc basis, without taking the existing order of the system into consideration. Typically, there is no time and budget for doing a proper refactoring of the system to ensure its long-term maintainability. Finally, critical structural decisions are often made on the side, without executing proper controlfor example, an engineer might quickly write a small batch program to synchronize data between two systems, and 10 years later, a small army of developers is needed to deal with the consequences of this ad-hoc decision.

When looking at enterprise software, we are usually not looking at isolated systems, but at large numbers of systems with complex cross-dependencies that have grown over many years and with a high level of heterogeneity and redundancies. We rarely have sufficient in-house knowledge about the different systems, and we often need to cope with very different design and programming styles. Finally, people are getting used to this situation and are starting to think in terms of workarounds, not in terms of the "right" structures.

Some organizations might have found better ways of coping with these problems than others, but it's hard to find any organization today that can claim that it has completely sorted out these issues. For this reason, many organizations require an enterprise IT renovation roadmap to help providing a sustainable transformation into a more agile IT organization that is able to quickly and efficiently adapt to changing business requirements. This chapter lays out the cornerstones of this roadmap as it is presented in this book.