‘A’ is for Architecture

Last week I posed the question, “What’s wrong with SOA?” For those of you who missed it, I’ll save you the trouble of reading it now. The answer, in a nutshell: Confusion. It reigns supreme in the SOA space. In several decades of covering IT, I’ve never witnessed the level of disagreement about the very definition of a major industry trend, such as we are seeing with SOA.

There is no shortage of industry research that validates momentum around SOA. Likewise, there is no shortage of books, papers, pundits and bloggers who espouse or otherwise agree with one or another definition of SOA. But the fact remains that any discussion of SOA quickly devolves into an IT version of David Ben Gurion‘s political maxim: “Wherever there are two Jews, there will be three opinions.”

Likewise, wherever there are two IT professionals, there will be three opinions of SOA. It’s odd, because at the end of the day, SOA is a simple concept that anyone in IT should grasp in a nanosecond. It’s also troubling, because unless we agree on (read: universally understand) the definition of SOA, the research and conclusions extrapolated thereof are simply garbage out, because the premise was garbage in.

For example, last week I cited an AMR Research report that projected IT investment in SOA will hit $52 billion over the next four years, with 77 percent of IT shops building SOAs. But if some of those surveyed believe SOA is a floor polish, while others believe it’s a dessert topping, the projection is flawed and, as such, not actionable.

I’m not singling out AMR. But having interviewed many a CIO who is leading the charge on a SOA implementation (several of whom I’ll feature here in podcasts over the coming weeks), I’m willing to bet that the folks AMR interviewed for their survey don’t agree on the definition of SOA and, further, that many are operating under a flawed definition of SOA.

It’s not a stretch to say this cognitive dissonance affects much, if not all, of the punditry and prediction bandied about on the topic today. It’s certainly shaping the response of IT technology vendors, who are chasing, delivering and evangelizing platforms designed around, in some case, wildly divergent approaches to SOA.

For global IT to truly benefit from SOA, we must first understand what SOA is. Let’s start with the ‘A’ in SOA, which stands for architecture; specifically, in the case of SOA, a software architecture. Rather than spark a debate about what constitutes an architecture, I’ll lean on the definition adopted by the IT Infrastructure Library (ITIL).

Dubbed ITIL v.3.0, this definition is probably the industry’s most widely accepted approach to IT service management. Its platform-neutral and vendor-neutral approach is successfully used by large organizations around the globe. It defines an architecture as: The structure of a system or IT service, including the relationships of components to each other and to the environment they are in. Architecture also includes the standards and guidelines that guide the design and evolution of the system.

CIO.com has plenty more ITIL resources, if you’re interested in the topic.

Sounds good. Heads nod. But what does this mean? Thankfully, some folks took the time to define architecture in plain English on Wikipedia. This definition is clearly oriented towards construction design, as this excerpt illustrates:

As a process, architecture is the activity of designing and constructing buildings and other physical structures by a person or a machine, primarily done to provide socially purposeful shelter.

But look at the next sentence. It maps perfectly to ITIL 3.0, and better still, is understandable by anyone, including a CIO or CEO without a deeply technical background (emphasis mine):

A wider definition often includes the design of the total built environment, from the macro level of how a building integrates with its surrounding man-made landscape (see town planning, urban design, and landscape architecture) to the micro level of architectural or construction details and, sometimes, furniture.

Who among us thought architecture simply meant a design, blueprint, flow chart or model? Don’t raise your hand; someone might be looking. The key distinction here is that an architecture, done right, never stands alone. It must always be designed to exist in the context of the total built environment—a distinction that opens up a can of worms or a world of opportunity, depending on your point of view.

Got time for a canonical example of architecture? Consider Frank Lloyd Wright’s Fallingwater. Most architects then, and now, would have designed the mountain retreat to be erected in a clearing. Not Wright. He engineered the building’s integration with the surrounding natural environment. He also designed the walnut furnishings, fixtures, artwork, lighting—every detail of the interior space was considered, including how and why (!) residents would see the building’s namesake. (Hit the links.)

Wright’s architecture was more than a set of sterile blueprints for a building. He accounted for the design of the total built environment. The result is one of the greatest examples of modern architecture. It’s also the perfect muse for a service-oriented software architecture.

That’s because a software architecture must define more than the structure of the resulting implementation. It must define the relationships between the pieces (components), the environment in which the resulting system will operate, and—just like the architecture for Fallingwater — provide guidelines for current and future builders (programmers) regarding how everything should fit together, and into the environment.

In the case of SOA, this means how everything fits together, and into, the business environment. So if your organization’s SOA isn’t designed, or being designed, in the context of the total built environment, guess what? It’s an SO, not an SOA.

Conversely, there are architectures, and there are service-oriented architectures. More on this next week.