Enterprise architects are town planners not architects

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.

Tokyo Skyline

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.

4 thoughts on “Enterprise architects are town planners not architects

  1. This is a good read to know the angst of a thinker from the bottom-up level. Dear Sir! What will you do when the OZONE layer depletes. Who is thinking about it. Yes, those who don’t have much oxygen to live on. But these guys do for they have genuine concern. This is tip of the ice berg. It is nice to learn how one has contributed to Adobe’s growth. But is Adobe alone good enough for an enterprise. In fact in terms of ROI, how much percentage does ‘Adobe’ alone contribute to a large enterprise. What fraction? Barely enough. And, ‘Adobe’ alone within a larger enterprise context will be dysfunctional in lack of a bigger picture that helps in achieving a co-ordinated functionality achieved from a matrix of application software portfolio/s.

    About the ‘talkers’ and ‘doers’. IBM took the ‘talker’ Rational and has got much better as a ‘doer’ – walking the talk I guess.

    Thanks
    srinidhi

  2. Ingine,

    I’m not suggesting that Adobe contributes very much to any enterprises bottom line – rather that Adobe is a very successful company in its own right because, according to Christopher Baus, they focusing on doing not talking.

    Nor am I suggesting that there should be no coordination. In the same way I don’t think towns should grow without coordination. But what I am suggesting is that this coordination role should be limited to those issues that concern interoperability this, I think, is analogous to the role of a town planner. When ‘Enterprise Architects’ stray outside this role and start dictating implementation issues we get in trouble – in the same way that we would be in trouble if a central planner tried to plan out how every building would be built, what materials it would use, what the design should be.

    One of the reasons we get in trouble is because to deal with a problem that large (architecting an entire town) requires such massive level of abstraction that they run out of oxygen. Let Town Planners and ‘Enterprise Architects’ (if you must call them that) worry about the central issue of interoperability and; Architects and System Architects + Software Engineers etc. worry about how to build a solution to someone’s problem.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s