From Medieval to Pre-Fab Software

Publish date:

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 […]

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

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.

Medieval Times

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.

Modern Times

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 Future

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

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.

similarities between the two can provide us with valuable insight
into how to improve our use of IT in today’s complex business

Related Posts

Creative Design

Travelling to distant stars – a thought experiment

Peter King
Date icon April 2, 2019

At Capgemini Invent we bring to life what’s next for our clients by combining strategy,...


Chart your DCX strategy in four steps

Anuj Agarwal
Date icon May 31, 2018

Develop core capabilities to make the right connections that underpin digital customer...