Why IT Solutions Are Never Simple
10:37 AM Wednesday April 1, 2009
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:
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?