Sunday, August 05, 2007

Enterprise Architecture?

Architecture seems to be a heavily overloaded term at the moment; as Martin Fowler notes, the title "architect" can cover a wide spectrum of roles. In my own experience I have seen the term architecture to mean everything from am abstract arrangement of requirements to a rack diagram showing the configuration and cabling of a number of servers. Accordingly one of my stock interview questions when hiring people is "what is architecture?". I won't embarrass anyone by repeating some of the answers I have had, but in general I am surprised by the number of people claiming to be architects who struggle with this question.

Drilling down the current buzz term is 'enterprise architecture'. However even for this term there is a variety of interpretations, even if there is a de facto definition of the term; the following is taken from wikipedia:

Enterprise Architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure and process architecture as well.

My own experience is that organisations are putting together enterprise architectures today, because that is what everyone in the industry says is required. However in most cases due to the absence of a business strategy enterprise architecture defaults to technical architecture - a description of an IT solution, perhaps phased over some period of time.

The situation is confused all the more by software architecture for enterprise applications. This is the architecture as captured by Sun's Certified Enterprise Architect qualification, and also as described in books such as Martin Fowler's Patterns of Enterprise Application Architecture.

Common to most of these ideas about architecture is that there is an abstract representation of a target IT solution, to some business problem. Therein lies the key difference from the rack diagram - there is no abstraction, it is a wiring diagram rather than a building plan. Which is why I don't think of the rack diagram end of the scale as architecture.