Without concerted effort, what was once neat and tidy becomes marred and messy. Just finding something in the garage feels like an archaeological expedition. Periodically, when someone dies, or relocates, or becomes disgusted, there's a whirlwind of activity to purge and reorganize. This cathartic experience is followed by a brief period of exhilaration, until time passes and entropy exerts itself once again.
So of course the airlines didn't intend to build "multiple old computer systems that don't share information well." When these systems were initially constructed (in the 60s and 70s), they were neat and tidy. Application requirements were defined from the point of view of a department and the needs of the people within it. The approach to programming reflected a simple and static world where it was the norm to embed data and business rules together with the logic necessary to support a business function — for example, to book and manage reservations. No one conceived that customers would book their own travel, that airlines would merge and spin off, that competing airlines would sell seats through code share agreements, or that competition would become so fierce as to necessitate greeting them by name and remembering their favorite drink.
To respond to these demands in a timely manner, IT did what we all do. They packed as much as they could in the existing "application" garages. When it became impossible to enter them without breaking something, they built new ones to store additional, but redundant, data, business rules, and logic. In an attempt to coordinate these applications to support business processes, they built a myriad of point-to-point interfaces between the applications. As a result of these seemingly efficient but short-sighted approaches, the systems architecture of the average 20+ year company looks something like this (aptly named, the "scare" diagram):
Because of this complexity, many companies don't have a definitive understanding of their customers, products, and performance and have difficulty modifying business processes in response to new opportunities and competitive realities. Furthermore, they devote the lion's share of their IT spend to maintaining existing systems rather than innovating new capabilities.
This isn't new news, of course. During the 1990's, we started to realize that IT systems often inhibited rather than enabled change. Since then, IT and business leaders have been working hard to increase agility by replacing systems and using new approaches to promote integration and commonality. Along the way, we have learned that:
- Across-the-board "scrape and rebuild" of systems usually doesn't make sense because often the gain isn't worth the pain. This approach is like knocking down your garage and throwing out everything in it. There's a lot of good stuff in your existing applications and there is no guarantee that the new systems will be that much better, less complex, or cheaper than the old ones.
- Hiding existing systems complexity using a "layer and leave" approach makes it easier to use and integrate existing systems, but doesn't reduce the costs of supporting inflexible and redundant systems. This approach is like hiring a garage "concierge" to find things and put them away. Unfortunately, you have to pay for the concierge service as well as the costs of maintaining the garages.
- The best way to manage complexity is to "clean as you go". This is a combination of the two approaches — implemented on a project-by-project basis. Each project is defined in a way that moves the enterprise closer to the desired "to be" architecture. Using our garage analogy, to move something in, one or two things must be reorganized or moved out. This approach includes layering, but also extracting critical data and functionality out from applications and rebuilding them so that they can be managed as an enterprise asset.
IT isn't alone in the need to simplify. As Rosabeth Moss Kanter pointed out, "Companies sow the seeds of their own decline in adding too many things — product variations, business units, independent subsidiaries — without integrating them." Keep in mind that, since IT architectures mirror the inherent complexity of the businesses that they support, it's impossible to have a truly agile and cost-effective technical architecture without simplified business architecture.
It's hard to say "no" to the extra product line, merger, reporting package or, for that matter, bicycle. Simplicity's just not that simple. How are you doing getting there?
