The Role of the Enterprise Architect

I recently sat in a meeting where a group of Information System architects were discussing their experiences with developing Enterprise Level architectures. During the discussion and in the period following, I have contemplated the travesty that the information technology industry has made of the concept of an Architect. During the discussion there were questions about catalogues of terms, management of repositories etc.

The intent of this brief discussion is to suggest that a focus on these things, the province of the engineer, suggests a total lack of understanding regarding what it means to be an architect.

The information system industry seized on to the concept of the architect as a way of helping the enterprise (whatever that might be) to convey the linkage between the business of the enterprise and the information systems developed to support the achievement of the business goals of the enterprise. A noble aspiration, but one which has, sadly, in many cases, been misdirected in its efforts.

Let me explain why I say that. But in order to do so, it is necessary to step back and understand what it is has meant, historically, to be an architect. As an industry, the information system world has a sad habit of seizing on the use of roles such as engineer and architect but failing to establish the underlying disciplines which are necessary to claim that one is a true engineer or a true architect.

As I mentioned in my recent blog on Human Philosophy and Architectural Design, I had the opportunity several years ago to spend some time working in Europe. As I looked at the buildings which collectively catalogue over a thousand years of architectural development, it became very clear to me that through architecture communities express their aspirations.

The concept of the Architect in information systems design is the same. I have heard analogies such as the role of the Enterprise Architect is to tell people where the pipes are and how the services hang together. In the built environment this is the role of the Town Planner. Is the Town Planner an architect – well at some levels yes – but those levels are the ones where the Town Planner is helping to capture the will and the priorities of the community. Stating where the water main is located or where the power is to be connected is actually an engineering/architectural role. In the IT industry we would call them the solution architects.

In the design of the built environment the architect’s role is to understand the aspirations of the client. To understand what functions the client wants the building to fulfil. To understand how the people which use the building will interact with it. The built environment architect is not concerned with building repositories of information or identifying the detail of connection points for services etc.

So what then of this role we call the Enterprise Architect. It is my opinion that the key role of this position is to understand the aspirations of the enterprise and to turn those aspirations into artefacts that the solution architects and engineers can use to design the plumbing, develop the frameworks and ensure that the information system which is developed fulfils the aspirations and goals of the enterprise.

The Enterprise Architect is a challenging role. The EA, whilst not required to understand all the detail of designing and building ICT systems, must nevertheless know enough to understand what the limitations are. At the same time the EA needs to grasp at quite a depth the business of the client. The EA needs to be able to, for a time, walk in the clients moccasins and understand what they do, how they do it and how they want to do it.

This then is the role of the EA and as corporations and organisations grapple with seemingly intractable problems, the role of the EA is to understand the complexities of the clients environment and reduce the complexities to understandable artefacts that the engineers and solution architects can use to build the resulting system. To reduce the role of the EA to discussing catalogues and repositories for storing artefacts is to not only reduce an organisationally vital function to an engineering responsibility, but also to denigrate the role of the architect in all of its historical richness.

About slade

Slade is an Enterprise Architect, Business Analyst and Project Manager with extensive experience in the Defence, National Security, Emergency Services and secure systems environment. Slade has been in the IT industry since 1988, and is experienced in systems engineering, systems architecture, systems integration, security assessment and development of sustainment frameworks for new systems. He is also a thought leader in human factors for the design of critical decision support systems and environments and the development of enterprise and solution level architecture for high information workload environments. Slade is the Director of EcoThought Pty Ltd