What does an Enterprise Architect Do?

The first thing most people think when they hear the title “Enterprise Architect” is that this person does some sort or modeling or design activity. Architecture is and always has been a visual medium and in some sense that initial metaphor which connects IT architecture and brick and mortar architects remains valid. Most EA’s need to know something about design – whether it be in the context of a specific design tool or paradigm or just the ability to visually depict complex topics in an intuitive manner. What is important to keep in mind though is that there is no one “right way” to model or design and that these visualization activities represent only a portion of what the enterprise architect does within a typical engagement or project.

There are many who might disagree with the “right way” comment – some of those people may feel that a particular EA framework or perhaps UML is the one preferred way that work should be prepared. To some extent, UML has achieved a universal status of sorts and can be used within most other EA frameworks; however there are some things UML is still not good at representing. For example, high level Domain models and Use Case diagrams convey relatively little information yet there can be richer depictions of operational concepts at a high level (what is generally described as an OV-1 in DoDAF or ModAF or perhaps a BRM in FEAF). There will always be room for flexibility in the way that information can be presented visually and then the question becomes how important is it to capture aspects of the information being presented in a data driven tool. The secondary question might be whether a non-standard visualization is meant for one or more audiences. Often times what is useful for business stakeholders may not be helpful to developers who need more specific design notation to support application development.

Most EA artifacts begin w/ taxonomies - this one was used to develop a DoDAF TV-1

Now we come to one of the truly vexing aspects of working as an Enterprise Architect – each organization is going to view things slightly differently. There will be different opinions about role, process and deliverables from one engagement to the next. This may even be the case within a single organization but is certainly the case when crossing from one organization to another. What this imposes on the EA is the need to understand or be fluent in multiple different approaches and to be capable of developing new ones as needed. This was one of the reasons we made a point within the EA Manifesto of stating that the tools or products don’t drive Architecture, they merely support it. One of the main responsibilities associated with Enterprise Architecture is the ability to tailor tools to unique organizational expectations and still allow both to function properly.

Yet all this is still only part of a bigger picture. The EA is not merely expected to be able to model or design in different tools using different modeling paradigms – we’re also expected to:

• Understand all or most of the technologies involved (in a project, in a domain or across the whole enterprise).
• Be able to help develop, assess or implement strategic objectives or initiatives. These sometimes extend beyond pure technology-based capabilities.
• Be able to estimate scope, cost or schedule for initiatives or parts thereof.
• Be able to support functional and technical requirements gathering and validation.
• Be able guide product evaluation processes.
• Be able to evaluate new technologies in a less formal sense and project future impacts.

And the list goes on. The EA is not an executive position although on occasion EAs are also asked to provide various types of leadership, such as:

1. Solution Evangelism
2. Industry Thought Leadership (1 and 2 often work in tandem)
3. Oversight of specific projects
4. Tech Oversight of the enterprise

As you can see, it’s difficult with all of these types of expectations for an enterprise architect to become specialized in any one area – in fact if he or she did it would likely reduce their effectiveness in the role quite a bit. So, in answer to the title question, what an EA does is whatever the customer asks them to do at any one given time – keeping in mind all of the other expectations that relate to the immediate need and the role. EA is often viewed as entirely strategic, but the reality is that it is a pragmatic mix of strategic goals and tactical needs. This balance can be met if one side doesn’t give way entirely to the other. For example an EA that never becomes involved in the day to day operational issues of an organization may find themselves hopelessly out of touch after some time and the relative value of their strategic contributions would likely decrease proportionately.

Copyright 2012, Semantech Inc. All rights Reserved