I've been using the metaphor of managaging enterprise software as something akin to city planning for some time now. It started when I happened across a McKinsey article called The Paris Guide to IT Architecture, which takes the position that we need to manage IT in a similar way to managing a complex city like Paris. This is well and good, but recently I've been thinking that the really interesting thing is the similarity between how cities and enterprise IT have evolved over time.
Imagine a landscape—the hills, valleys and rivers—as representing the business environment. A river might be a distribution channel, dropping product onto barges to be sent down the river. Our supply chain operations are in a building next to the river, with partner integration represented by the dock. Sales is the impressive building with the marble foyer. Production and the service department are grubby buildings in a less picturesque spot on the landscape. Finance and management are the large buildings on the hill. HR and other supporting functions cluster in the back alleys and laneways. The actually operations of the enterprise are represented by the employees running in and between buildings.
Historians usually tell us that a settlement starts when a few people throw up some bark huts at the edge of the river to support their business there (making flint tools, dancing around the fire, hammering clams, etc). If the spot on the river is a good one then the city will grow and more buildings are thrown up. Eventually the settlement might be successful enough to justify redeveloping the temporary buildings into more permanent structures. Add a wall for protection, a cathedral, plus a keep for upper management and we have a medieval city. (A medieval city had a cathedral, while a town had a church.)
This is similar to the early days of IT, or even the early days of a modern company. We might start a business, manufacturing our product by hand, maintaining our records on ledgers, and using face-to-face interactions with all our customers and suppliers. Eventually we’ll decide that we need to automate some key process, possibly something prosaic like accounts receivable or order management (think the Desk Set). We’ll start deploying applications, initially to solve small problems but eventually our business landscape will be dominated by fields of disconnected solutions to many of our business problems.
The Victorian Age
And so it continues, with our medieval city steadily growing until we hit the Victorian age. The problem with an average Victorian city was sewage. To this point cities had grown more or less organically as buildings where thrown up to house people and industry, but without much thought to infrastructure or support. Eventually these cities were on the verge of collapsing under the weight of the sewage they generated. Disease was rampant, the elite had moved to the country and the only people living in cities where the ones who had no other choice.
Enter the age of the grand engineering infrastructure project. The late Victorian was dominated by efforts to re-engineer cities and make them more liveable. Major projects were started to dig sewer systems, taking effluent from the city to the sea. (“Sewer” means “seaward” in Old English.) Similar projects were undertaken in cities like Paris. With the sewerage fixed, attention moved to changing the layout of streets to smooth the flow of traffic and eradicate gridlock. (The boulevards of Paris were created by bulldozing city blocks as part of such a project.) Pipes were laid down to support gas—a recent discovery—and new technologies were added to the infrastructure mix as they became popular, with electric power followed by copper for telephone lines. Some cities took this to an extreme, with the New York deciding that the existing lower Manhattan landscape was not conducive to business. They flattened lower Manhattan, pushing the hills into the valleys and covering the streams, laying a grid over the result and effectively reengineering the entire landscape.
We can compare these city engineering efforts to the early days of enterprise architecture in the 70s, and into the 80s. To this point companies had simply thrown up applications to fill immediate needs—building a new factory, warehouse or shop wherever there was room—with little thought to integration. What integration existed was more likely than not to be people running between buildings with magnetic tape canisters or hard disk platters. Industry knew that it could do better, and started to find ways to connect pairs of applications together. This expanded, and soon business partners were connecting their applications to ease the flow of information. Eventually industries came together to solve common problem creating Electronic Data Interchange (EDI) standards such as SWIFT.
This simple point-to-point approach quickly became too complex to manage, much like the early Victorian cities, prompting John Zachman to step in with the Zachman framework and popularise the idea of enterprise architecture. Rather than create applications reactively, enterprise architecture promised to help us plan IT development, reengineering the IT landscape to smooth the flow of traffic and ensure that the utilities are supplied. This time also saw the birth of IT strategy, which was really application strategy as it was focused on deciding what applications to use where and otherwise deal with the limitations of technology. Enterprise architecture strived to be like city planning; creating a planning board to mediate between the captains of business, the engineers building applications, and the residents to create a more efficient environment. We created our own grand projects with the development of enterprise integration strategies and application suites (SAP et al). Life in enterprise IT became a lot better.
City planning has continued developing since the grand engineering projects of the Victoria age. Our own Canberra is a good example of what can be done given sufficient motivation. As a city designed for cars it manages to keep traffic out of the neighbourhoods while maintaining low journey times and effectively avoiding traffic congestion completely. But Canberra is unusual, and it’s more likely that modern cities will develop into something like Tokyo.
What we commonly think of as Tokyo is really a greater urban environment that has grown organically to cover a number of cities and more than 35 million people. This is similar to the current business environment. The barriers between partners are being eroded as business talks about the extended value-chain. Modern business partners are tightly integrated, just like the cities in greater Tokyo, as they work together to achieve common goals. A mobile phone manufacture is a good example of this. The Nokias of the world typically only do design and marketing in house. While they manage product development and marketing, they do not own the fabs, factories, trucks etc required to create the product and take it to market. Cisco is an extreme example, as they have deployed monitoring hardware in the factories run by their business partners (at the partner’s expense) allowing them to shut down the production line if Cisco detects a fault. To support this drive for integration we’ve developed even more sophisticated tools, from EDI through MoM (Message Oriented Middleware) to EAI (Enterprise Application Integration), all with IT strategies to support them.
Today the problem is that it simply costs too much to create or modify an application, or to integrate it with the applications that surround it (either our own or our partners’). Solving a problem involves (re)developing an application at huge expense, and the current IT landscape is dominated by the isolated skyscrapers that are today’s generation of enterprise applications. Each of these applications is an ecosystem unto itself—a self contained IT solution designed to support a specific function within the business while hiding important logic and data behind an external façade.
This is where the Paris Guide comes in. Business is being forced to engage IT as a major engineering effort, much like the Victorian projects of the past. Every problem requires them to commission a new four year and $50 million project. It’s like our enterprise city only contains 100 story skyscrapers, where the successful cities in our analogy (Tokyo, Paris, London and New York) are predominantly low rise at around four to six stories.
There’s a reason for this: the average skyscraper is only around 60-70% efficient (in terms of space utilisation and energy usage) while a low rise building is around 80-90% efficient. What we need is a cost effective way of leveraging skyscrapers where appropriate (ERP, CRM, etc), while filling the space around them with low rise buildings to support those creative functions that enable a company to differentiate (product development, marketing, etc). The high cost of integration made this impossible, until now.
The introduction of prefabricated buildings, assembled from standard components created off-site, revolutionized building practices. A prefabricated structure allows you leverage standard, cost effective, components where appropriate while creating bespoke components for those elements that will make a building (or business) distinctive. Today you see pre-fabricated buildings everywhere.
Services enable us to take a similar approach to the construction of IT. A service is simply a small cohesive block of functionality, designed to support a specific business activity. Using services to construct a solution allows us to leverage pre-fabricated components (applications) where appropriate, snapped together via standards-based infrastructure, while reserving bespoke development for those services which will establish our company’s differentiation in the marketplace. The overall arrangement of services required is called a service-oriented architecture (SOA).
So this is why the future of enterprise software is similar to city planning. Cities are complex organisations created by people and for people to support their endeavours—just like businesses.
IT has matured greatly over the last 40 years, and we find ourselves in an environment where applications a ubiquitous and integration is both cheap and effective. Our focus is shifting from the medieval of how we deliver IT, to a modern focus on how IT can best support the business. Rather than taking an ad hoc approach or treating application development as a grand engineering process, we would like to approach IT support like the development and maintenance of a large low rise city like Paris or London.
The similarities between the two can provide us with valuable insight into how to improve our use of IT in today’s complex business environment.