ABSTRACT: Many organizations are now undertaking development of service oriented architectures, but the probability is that most will result in sub-optimal implementation. Most organizations will focus on a smaller set of objectives than they ought to, because they are overly influenced by project and or technical concerns, and not sufficiently focused on the broader business service view. We discuss a recent article by Pat Helland of Microsoft and contrast this with the thinking of Christopher Alexander, whose thinking has stimulated much IT process and pattern activity.
In a recent article published in the Microsoft Architects Journal Pat Helland explores the idea that information technology is evolving in a fashion similar to how American cities evolved over the last two centuries. He suggests that we are building boom towns with no end in sight, and similar forces that drove the maturation and sophistication of cities are driving IT today.
Helland’s article makes the following argument.
1 Progress requires standardization. (According to Helland, people didn’t even wash properly until they had standard clothing.)
2 Standardization is associated with commoditization.
3 Standardization requires concentration of power (and if this involves pathological distortions of socioeconomic relations, such as WalMart or dare we say it Microsoft, so be it).
4 Infrastructure requires central investment. (Since we may regard infrastructure as an act of local standardization, it follows that it must involve concentration of power.)
5 Central investment preserves the “sacred”.
Helland is already well-known for his exploration of physical analogues of computing structures, through his development of the Fortress Model of Trustworthy Computing (which we have discussed in previous Newswire).
In this article Helland explores a metaphor for the evolution of information technology into the world of service oriented architectures, and he contrasts components of the archetypal city to the IT world.
However, while Helland talks about boom times, he describes a relatively linear development process. While he does mention the huge inefficiencies and frustration caused by organic growth he does not link this to the crazy decisions that get made because city development is heavily influenced by politicians with, at best, short term goals. Perhaps the best analogy that Helland completely omits in this article is that city planners are just like IT architects, who are charged with creating elegant and efficient, yet complex and diverse environments, but more often than not are frustrated by cold hard realities.
We are puzzled that so few software gurus are aware of the work on city planning by the architect Christopher Alexander – particularly as Alexander’s early books (“Notes on the Synthesis of Form” and “A Pattern Language”) have been hugely influential in the software community – indeed, he is more highly regarded among software practitioners than among architects (who tend to regard him as a maverick). As far as we know, our regular contributor Richard Veryard was the first writer (back in 1994) to apply Alexander’s work on urban design to the management of software, and CBDI remains one of the few think tanks that is systematically developing this parallel.
STRONG ANALOGIES BETWEEN TOWN AND SERVICE PLANNING
In 1987, Alexander and a few colleagues published an account of a design experiment under the title "A New Theory of Urban Design". This book shows how order can be created without top-down planning, by a governance process that imposes some simple structural principles on all design activity.
There are some strong analogies between town planning and service-oriented architecture, which make it reasonable to translate Alexander’s governance process into the SOA domain.
1. The distribution of design. Detailed design decisions are taken within different organizations, each following its own agenda (e.g. commercial or political goals).
2. The constancy of change. Elements of the whole are constantly being redesigned and reconfigured, and new elements are constantly being added. Structures must evolve in robust ways.
3. The need for progressive improvement. Each design increment should not only make local improvements, but should have a positive effect on the whole.
4. The recursive nature of the architecture. Similar design tasks must be carried out at different scales (levels of granularity).
GENERALIZED PRINCIPLE THAT AVOIDS TOP DOWN PLANNING
Alexander formulates the following highly generalized principle: "Each new act of construction must create a continuous structure of wholes around itself." Alexander then spells out what is meant by the word "whole" in an architectural context. One of the key consequences of his notion of wholeness is that a designer tasked with constructing something of scale X must pay attention to three scales – larger than X, same as X, and smaller than X. Part of the governance process is to ensure that there is a reasonable balance of projects of different scales.
But the parallels between city and IT architects break down in some really important areas. For example, the city planner probably has considerable influence over the provision of basic services - often he or she is the equivalent of the service sponsor. Even in boom town situations, the users represented by the democratically elected representatives, while making political mileage out of debate and disagreement, are likely to coalesce around the "need" for common services. However in the business environment the IT architect is a mediator between multiple parties who often do not even "perceive" the need for common services, let alone understand their roles as service owner, provider or user. Nor is the service owner necessarily charged with providing common services to others.
SUPPLY/DEMAND ORIENTED SOA
In our report Business-Driven SOA, we examine what we refer to as the Supply/Demand oriented SOA architecture - driving the SOA from a business perspective. In the report we illustrate the problem with a very common situation - where the HR business unit should be the owner and provider of common services relating to employee data, but in most enterprises has been reduced to the role of data administrator, disconnected from the core business processes.
We show how to be successful a SOA must start by resolving these issues and determining the common services to be provided. We develop Christopher Alexander's thinking to provide explicit process guidance on how to develop the right SOA for your business.
AFTERTHOUGHT
Pat Helland ends his article with the thought - Just remember to invest in transportation systems!
we might end with the thought -
Just figure out who the real service owner ought to be! |
Home