The Role of the Enterprise Architect

Hi,

Every once in a while I have to explain to people what the role of the Enterprise Architect is. And although this question isn't all that trivial at all, I still answer it with reasonable ease.

Disclaimer: I consider myself an Enterprise Architect, but with an IT perspective. This is important to note because it significantly limits my scope.

Another disclaimer, this post is from September 2011, since then, a lot has changed and although I've made some minor corrections in December 2014, you'll have to bear with me that the main gist of the post is 3 years old.

With that out of the way I can provide you with my answer to this question and explain it to you within the proper context.

Spoiler alert: The Enterprise Architect is responsible for formulating the vision for the mid and long term from a technology point of view, the IT Vision. A vision that is in-line with the business vision. He is responsible for defining a strategy that is to be followed in order to realize this vision, the IT Strategy. A strategy that is in-line with the business strategy. And consequently the Enterprise Architect is responsible for creating a roadmap that when followed implements the strategy, the IT Roadmap. The IT Roadmap consists of strategic business projects that implement key milestones and are fully in-line with the IT Strategy as well as strategic IT projects that facilitate in the implementation of the IT Strategy.

First of all I think that the Enterprise Architect's role differs from a Solution Architect's role in one very significant way; Where the Solution Architect is confronted with a problem and request to create a solution for it that complies with a given set of rules, laws, regulations, standards, guidelines and what not. The Enterprise Architect is confronted with the
current state of the world and an idea of how the world might turn out to be in the foreseeable future. And then is requested to define all problems to be expected to finally come up with solutions to all of them, such that they all comply with a set of rules, laws, regulations, standards, guidelines, etc. Some of which are unknown at the time the solution are defined.
Basically, the Solution Architect is given a problem and architects the solution, the Enterprise Architect has to come up with the problem first and then architect the solution.

With this out of the way, I can finally start answering the question: What is the role of the Enterprise Architect? His (or her for that matter) role is to create, govern and maintain the architecture of the enterprise from a technology perspective. Which more or less means that the Enterprise Architect is responsible for defining how the enterprise architecture as a whole is mapped onto technology. In the previous sentence I refer to the enterprise wide business architecture. And yes, I realize that this doesn't really has any meaning. Until, of course, I explain to you what I mean by enterprise wide business architecture. What I mean by this is the complete set of business decisions, visions, objectives, processes etc that have been formulated. It means the essence of the enterprise. The primary reason and motives of running the enterprise, its raison d'etre, if you would pardon my French.
The Enterprise Architect (from an IT point of view) is responsible for defining the IT perspective of this business architecture. He is responsible for defining which technology, principles, concepts, systems, applications etc are interrelated and how they are interrelated in order to enable the enterprise to meet its goals. And in addition he is responsible for maintaining this architecture, amending it as business goals evolve, and govern changes to it.

At this point I typically get the first blank stares from people. Rightfully so, because it is very abstract and Ivory Tower'ish. But there is a simpler answer which explains the role of the Enterprise Architect more clearly, in my opinion.

The Enterprise Architect is responsible for formulating the vision for the mid and long term from a technology point of view, the IT Vision. A vision that is in-line with the business vision. He is responsible for defining a strategy that is to be followed in order to realize this vision, the IT Strategy. A strategy that is in-line with the business strategy. And consequently the Enterprise Architect is responsible for creating a roadmap that when followed implements the strategy, the IT Roadmap. The IT Roadmap consists of strategic business projects that implement key milestones and are fully in-line with the IT Strategy as well as strategic IT projects that facilitate in the implementation of the IT Strategy.

Although the Enterprise Architect has to be constantly aware of the ever changing environment and adopt his architecture to remain in-line with the business architecture. This in part as a result of a changing business vision and consequently changing IT Vision. The Enterprise Architect will also have to reconsider his IT Strategy as well as his IT Roadmap based on a changing market. Typically in organizations this is a yearly recurring effort.
This caters for the creating and maintaining the IT Vision, IT Strategy and IT Roadmap in order to create and maintain the Enterprise Architecture. It does not cover the governance of the Enterprise Architecture. In order to implement governance, the Enterprise Architect is also responsible for defining and enforcing all policies and procedures that required for ensuring that project executed within the enterprise (both IT and business projects) are according to the set strategy.

For example, when the IT Vision is that the vast majority if not all (business) services are running in The Cloud [scroll down for a footnote on this 'vision'], and the IT Strategy is to implement in order a highly virtualized infrastructure which is then complemented with cloud administration services such that a private cloud is the result and finally all systems are moved to a public cloud as a means of out-sourcing the infrastructure.
The roadmap might be to initially select and implement virtualization technology, then migrate core systems to platforms that are supported in a virtualized environment, then select a cloud provider that supports the selected virtualization technology, then implement iteratively cloud administration tooling.
The Enterprise Architect is then responsible for ensuring that a set of policies, standards and guidelines are defined, implemented and enforced, that enforces applications to be cloud-ready. This may mean that certain paradigms are followed, for example that new infrastructure software and applications running on them are horizontally scalable in order to increase capacity such that performance requirements can be met.

It is utterly impossible to enforce compliance to IT Strategy for all systems, applications, projects etc. The Enterprise Architect, in collaboration with the business, will have to classify each project, system, application as being strategic, tactical or opportunistic.
Strategic projects (implementing core systems) will have to be completely compliant with the IT Strategy. These projects are implementing systems and applications that are planned to last for a long time within the enterprise and perform core functionality to the business. Typically they are planned to outlive the IT Vision or even the business vision.
Tactical projects can deviate from the IT Strategy but are required to be in-line with the IT Strategy. You could say they have to be in the spirit of the IT Strategy. These projects are typically implementing core business functions but for any reason cannot be implemented completely in-line with the IT Strategy. For example because the vendor does not yet support the selected virtualization technology for all components of the application.
Opportunistic projects are those projects that have a strong business driver to be implemented within a short time frame. Possibly because the particular bandwagon needs to be jumped on.

The interesting thing about an enterprise architecture is that treats those components that implement it on a physical level (hardware and software) as black boxes. At least to a certain level. The Enterprise Architect is concerned with the concepts of the various components but not so much with their implementation. By this I mean that the Enterprise Architect defines for example that all applications will have to run on a common application server infrastructure. This is the concept of farming, the infrastructure consists of a set of farms that host applications and applications components (application server farms, messaging farms, database farms). The idea behind this might be that infrastructural software is to be considered a commodity. How these farms are actually implemented (clusters of active nodes, clusters of active/passive nodes, etc) is not so much the concern of the Enterprise Architect but more for the infrastructure architects (middleware, database, etc), who in turn will be required to implement these farms compliant to the Enterprise Architecture. Even more interesting is that the Enterprise Architect is responsible for documenting the complete enterprise architecture as he own the enterprise architecture.

Although I realize that I haven't mentioned anything about the information architecture in this post, this is where I want to leave it to. Me for myself am not entirely sure whether the information architecture is part of the Enterprise IT Architect's responsibility. The thing with the Information Architecture is that it, in theory, is a business affair. The information architecture should be owned by the business. But practically I've seen it considered an IT affair in most pretty much every organization I've been. This is mainly due to the fact that the data architecture and information architecture are considered one and the same, which is in my opinion, because in most organizations it is considered to be impossible to create one enterprise wide information architecture. As a result, data architectures are not derived from a global or even local information architecture but from the physical needs of applications. But this is something worth its own post which I will work on some other time.

So this is what I consider the role of the Enterprise Architect as a role within an organization. But, there's more... Since the Enterprise Architect is one of the most senior roles within an IT department, if not the most senior role, I also think that as an employee within the enterprise the Enterprise Architect has also the responsibilities that come with this level seniority. In many cases the Enterprise Architect will have to act out of his seniority instead of his role. And this responsibility differs significantly from one enterprise to another.

Thanks for reading all the way to the end. It's become a long text, but I hope I've been able to explain my view on my role as an Enterprise Architect. Probably there's a lot you disagree with and I would love to hear about it.

Iwan

Footnote on the vision of having everything in "The Cloud"; Of course, it is not clear as to what the cloud actually is, even when you take the definition provided bij NIST. But the problem here is that everything in the Cloud is considered an IT Vision, which is of course not correct... but not uncommon, unless the  Cloud is considered placeholder terminology where the IT Vision is actually to no longer own physical infrastructure, not even from an outsourcing perspective.