We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anatomy of Agile Enterprise

Janne J. Korhonen

How Information Systems Learn

Vote 0 Votes

In his book "How Buildings Learn: What Happens After They're Built," Stewart Brand notes that building architectures are mainly designed from the spatial perspective, whereas the temporal dimension receives less attention. Building on the notion of Shearing layers, he states that buildings stand the test of time better, if it is taken into account upfront, how they can adapt to unanticipated future changes.

This dimension of time in architecture is emphasized in the context of information systems: in the increasingly volatile, uncertain, complex and ambiguous environments, flexibility and repurposability of IT solutions -- IT effectiveness -- is becoming more important than how perfectly they fulfill the requirements at any given time -- IT alignment.

The most lasting quality of a building is its location, the site. It specifies a context that outlasts generations. It is not irrelevant where the building is built: the permanence of the geographical setting, the city plan, the legal rights to the lot -- they are all important. In a similar vein, it is of essence in which environment information systems are situated: what technology standards and platforms are they based on; do these environments represent the past, today or the future? Who owns the environments?

The second lasting thing in a building is its structure: what are its foundations and its load-bearing capacity. Changing these properties afterwards is difficult, expensive, and often even dangerous. The same applies to information systems and solutions: are they designed to be open or closed in the first place; what architectural design styles (e.g. multi-tiered, object-oriented, service-oriented) do they adhere to?

Also the exterior surfaces of buildings change to keep up with fashion or technology. For instance, recent focus on energy costs has led to re-engineered skins that are air-tight and better insulated. To same extent, the separation of information systems into front- and back-ends simplifies development and separates maintenance.

The fourth thing to consider is the infrastructure, including services such as electrical wiring, plumbing, heating, ventilation, and air conditioning. They wear out or obsolesce every now and then. If the systems are too embedded, the building may need to be demolished, when the infrastructure falls into disuse. Similarly, information system design should take into account how, for instance, the database can be changed or application integrations can be updated in the future.

It should be possible to change the space plan of the building rather often. In some commercial spaces, the interior layout may need to be changed every few years. Similarly, the functionality of information systems in changing business environments needs to be changed relatively often. This can be achieved through modular services that are created, modified and retired according to changing needs and priorities.

The most changing part in buildings is the furniture, all the stuff that changes every so often. Furniture is called mobilia in Italian for a reason. In a similar vein, information systems have many moving parts and can be changed even on a daily basis: an additional data field here, changing a data type there. It should be taken into account in the design that such changes will not erode the original architecture and gradually render it inert.

Because of the different rate of change of its components, a building is always tearing itself apart. An adaptive building -- as well as an adaptive information system -- has to allow for slippage between systems that evolve at different paces: the site, structure, skin, services, space plan, and stuff. Otherwise, the slow systems block the flow of the quick ones and the quick ones tear up the slow ones with their constant change.

Embedding the systems together may look efficient at first, but over time it is the opposite and destructive as well. Building effective information systems that are adaptive to change calls for good upfront design. To "build to adapt" may cost more at the outset, but the overall lifetime cost will likely be much lower.


I often use the construction industry as the example of how the "IT" industry will evolve to a mature model. But before maturity comes that vital step to see Enterprise software take that big shift to being commoditised i.e. removal of the interpretation gap between users and IT by removal of coding to build adaptive custom applications. The rise of Adaptive Enterprise Software delivering “ACM” (Adaptive Case Management) much as you describe will support your “build to adapt”. The build of this front end driven requirement will be c 20% of current costs and puts business domain knowledge as the driver so the “pain” will not be as great as you think.

The building architecture metaphor is indeed used often. We need metaphors to understand stuff, sure, but I find the physical building one too restrictive and also a bit misleading. Enterprises and software systems are much too volatile. We need another metaphor: the biological world. As Gregory Bateson did ("Steps to an ecology of Mind") this metaphor can actually help in dealing with change, evolution, learning, inter-connectedness, fractal structures, and complexity. The building metaphor, although useful sometimes, brings with it the risk that we try to fit the complexity of the real world in concrete.

Janne J. Korhonen provides insights into how information technology can be applied strategically to catalyze organizational change and responsiveness. Drawing from both theory and practice, he discusses agile enterprise and its governance.

Janne J. Korhonen

Janne J. Korhonen is an independent business and IT consultant,specializing in enterprise architecture, business process management,service-oriented architecture and pertinent governance models. He has over ten years of experience as an architect and consultant in a variety of extensive and mission-critical IT projects. With strong theoretical underpinnings, his consulting encompasses systemic co-development of business, organization and information technology.

Recently Commented On

Recent Webinars

    Monthly Archives