“Selling” Enterprise Architecture
I’ve blogged frequently about Enterprise Architecture (and its subset, IT Architecture) because I believe it is a fundamental, literally, foundational discipline for business enablement through IT, and yet is woefully under-served in most organizations. One reason is – it is tough – balancing competing needs for standardization on the one hand, and innovation on the other. The other reason is IT architects are often poor business communicators, and are inept in “selling” the effort necessary to do things in an “architected” way.
Architecture and the New York Subway
My temporary relocation to Manhattan has allowed me to experience the New York subway (and bus) system more fully than ever before – and it makes a great analogy for Enterprise Architecture – or its lack thereof!
New York’s public transport is a gem! No, it’s not world class (try Singapore’s or the Washington DC Metro system for examples of clean, quiet, fast systems) but it works. However, I have quickly become aware of many idiosyncrasies of the New York subway. Certain stations (e.g., 14 Street, 59th Street-Columbus Circle, Borough Hall) where you need to change lines, don’t seem to ‘line up’ properly – you have long underground walks, underground shuttles, or, in some case, have to surface to street level in order to go back down to the different line (these are aptly referred to as “station complexes” and complex they are!) Some connections between lines that should be simple, aren’t! It felt to me as if there wasn’t a coherent architecture to the subway system – so I did a little research to find out why.
Three Subway Architectures!
In 1898, the City of Greater New York was formed from several counties and their constituent cities, towns, villages and hamlets. The City recognized the need for an underground subway system, but also realized that no private company would provide the significant capital required for such an infrastructure. The City decided to issue rapid transit bonds and contracted with the Interborough Rapid Transit (IRT) to build and run the subways, sharing the profits with the City. IRT opened the first NY subway in 1904. Meanwhile, the Brooklyn-Manhattan Transit (BMT) was building and buying up the Brooklyn elevated rail lines.
In 1913, the city embarked on a “Dual Contracts” initiative, engaging the private IRT and BMT to expand their systems. By the 1930’s, the City realized that the independent IRT and BMT were making handsome profits, so the City of New York created its own third system, the Independent Subway System (IND). The IND introduced yet a third architecture, so that the IND, IRT and BMT were competing with each other.
The Challenge of Integration
This competition led to overlapping services and different standards (such as carriage width, carriage length, train stop safety mechanisms). In 1940, the City took over the transportation assets of the BMT and IRT under a program called Unification. However, to this day, due to different tunnel diameters, curves and clearances and the different rolling stock, asset utilization is sub-optimal, and for passengers, navigating the subway system can be challenging and inefficient. To eliminate overlapping and redundant services, certain stations and even some tunnels had to be closed. Also, costly “interfaces” had to be built between the three separate systems in the forms of tunnels, walkways and shuttles.
If New York City Were a Business?
Imagine the City of New York as a business, and the IRT, BMT and IND as separate divisions. Imagine that each division wants to create its own IT organization and IT capabilities. Imagine there is no overarching architecture or standards. Now imagine, as a business you recognize the synergies between your three divisions, and want to integrate and leverage as many shared services as possible. What do you find?
- It’s incredibly costly to achieve integration because your three IT infrastructures are incompatible.
- You discover you have excessive redundancy across the three IT infrastructures.
- The cost of keeping the IT infrastructures running is eating into your operating margin, and yet the capital cost of rationalizing the infrastructures is prohibitive.
- With eCommerce and Enterprise 2.0 possibilities, you need to collaborate more effectively across divisions than you do currently, but none of the three IT infrastructures will support that type of collaboration.
- You ask your CIO, “How could you let this happen?” as you look for a replacement!
- Your CIO points to the chief IT architect and blames him for doing an inadequate job of convincing the IRT, BMT and IND divisions of the need for an overarching architecture.
- Your chief architect commits suicide (by jumping in front of a subway train?)
The Value of Enterprise Architecture
So, what were the costs of the lack of a unifying architecture to the NY Subway system? Had the IRT, BMT and IND followed an overall architecture and set of standards, how much time and money would have been saved compared with the “each go it alone” approach? That is the value of architecture.
What analogies can you use that will resonate with your senior business executives to sell them on the value of Enterprise Architecture?
The Downside of Standardizing Too Soon
In all fairness, I must reference the fact that choosing standards too soon can and does stifle innovation. The beginnings of the New York Subway occurred while there was a fierce competition between Nikola Tesla’s Alternating Current (AC) and Thomas Edison’s Direct Current (DC) systems. DC won out (for good reasons at the time) but modern solid state technology and advances in electric motor and switching technology mean that AC would have led to a simpler, more flexible and less costly subway system construction.
Image courtesy of Blog Them Out Of The Stone Age