The word “architect” is derived from the Greek arkhitekton (arkhi, chief + tekton, builder”) and in the real world this is just what they are – chief builders – they plan, design and oversee a building’s construction. Translating their clients needs into a physical building.

Now in the world of IT we have ‘enterprise architects‘ who, unlike real architects, spend too much time in the rarefied air of extreme abstraction rather than down close to actual user problems and code. These are what Joel Spolsky calls architecture astronauts.

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line. […]

Another common thing Architecture Astronauts like to do is invent some new architecture and claim it solves something. Java, XML, Soap, XmlRpc, Hailstorm, .NET, Jini, oh lord I can’t keep up.

Enterprise architects aren’t involved in the specifics of a actual code, functions and operations; instead they focus on the strategic, the low detail organisational breadth, on process architecture. As Jeff Atwood might put it they are talkers not doers.

Software isn’t about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn’t the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can’t push 500 pages per minute through a RIP.

There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt. [Christopher Baus]

Don’t get me wrong patterns and practices have their place, but they need to be framed in the context of a specific user problem – that’s what architects (the ones who are responsible for buildings and bridges) do.

If you decide to place too many layers of abstraction between yourself, your solution and a specific real world end user problem then you aren’t a chief builder. You’re more like a town planner.

Town Planner’s don’t design buildings. They research large scale requirements, draw up and consult on their plans and map out how a town should develop over the next few years. This job needs doing but it is different from architecture. We need town planners to help make sure all the parts of a town fit together, to make sure that the town’s infrastructure is adequate. To make sure the town’s interoperability is looked after.

But you obviously don’t want town planners to design a town’s buildings. Likewise you don’t want decisions that impact a project’s implementation to governed by Enterprise Architects. As Roger Sessions concludes:

The general rule of thumb is that decisions that impact interoperability should be centralized. Decisions that impact implementations should be decentralized. Not knowing which decision is which is a common error in enterprise architectural departments.

Let’s look at some typical errors that come up in enterprise architectures:

Platform—Many organizations attempt to define a standard software platform, often debating endlessly between, say, Microsoft .NET, IBM’s WebSphere, or BEA’s WebLogic. This effort is misplaced. Platform is an implementation decision, and it has no bearing on how the applications on those platforms will work together. As long as the platform meets the organization’s interoperability requirements, the application team should be given latitude to choose the best platform for their application’s needs.

Data—Many organizations attempt to define a single data layer that will be shared by all applications in the organizations. This effort is often expensive and rarely successful. How data is stored should be treated as an implementation detail of an application.

Business Intelligence—Most organizations treat data and business intelligence interchangeably. Whereas data (such as how a customer is stored in a database) is an implementation detail, intelligence (such as what business we have conducted with a given customer) is an organizational asset. It is appropriate to decide how such intelligence will be shared. It is not appropriate to decide (at the enterprise level) how applications will keep track of the data that feeds this intelligence.

Code Sharing—Many organizations believe that reuse is achieved through code sharing. It is somewhat amazing that this belief persists, despite decades of failure to achieve this result. The best way to reduce the amount of code that a given project needs is through delegation of functionality (as in the case of Web services), not through code sharing.

Web Service APIs—Many organizations believe, correctly, that the use of Web services is critical to achieving interoperability. Many organizations think that this means that the way applications use the Web service APIs should be standardized. In reality, the Web service APIs are far below the level of concern of applications. Applications typically make use of a buffering layer that is vendor-specific—for example, the Windows Communications Framework layer provided by the Microsoft .NET platform. The purpose of this layer is to insulate applications from needing to understand the intricacies of the Web service APIs. This buffering layer is specific to the platform, and therefore, it is part of the implementation details of the application.

The bottom line is that enterprise architecture is not the same thing as application architecture. Application architecture is about the design of applications. These designs should be the responsibility of the group owning the applications. This is one of the ways we achieve economies of small scale. Enterprise architects should worry about how those applications work together, and thereby provide better value to the organization.

Photo: Tokyo Skyline Panograph, by Chalky Lives. Used under licence.