Clif's notes on architecture, leadership

What Does an Enterprise Architect Do?

Nearly every interviewer asked me the same question when I interviewed for the role. Here's how developers, application, solution, and enterprise architects fit together.

When I interviewed for my role as an Enterprise Architect, I had to interview with lots of different people, from company presidents and IT leads to corporate vice presidents and directors. The questions were generally the types of questions you would expect from those in high-level positions, except for one. That one question was asked of me by nearly all of the interviewers: “So, what exactly does an Enterprise Architect do?”

That question struck me as odd. How often in a job interview does the interviewer ask the interviewee what, exactly, it is that they’re going to be doing? Well, if you’re an Enterprise Architect then it’s more common than you might think. While the role of Enterprise Architect is not a new one, it is one that isn’t very widely understood.

For this reason, I thought it would be a good idea to go over the general job description for an Enterprise Architect. Before I do that, however, I’ll go over the responsibilities of a few other key application architecture roles so that you can see where there is overlap, and where there isn’t.

Developer

A developer gathers requirements, writes code, and performs any required governance-related activities. The developer usually writes or updates documentation for the application features that they update or implement. The developer should do their work in collaboration with the application’s architect to make sure that their changes are properly accounted for across the application.

Application Architect

An Application Architect designs applications. Where a developer may design and develop pieces of applications, the Application Architect is responsible for the design of the application as a whole, along with any necessary integrations. It is the responsibility of the Application Architect to make sure that the application’s documentation is kept up to date, that the developer has properly documented their work, and that the ramifications of their changes to other parts of the application are properly considered and accounted for. Application Architects often participate in the development process.

Solution Architect

A Solution Architect has a wider scope than the Application Architect and doesn’t have to have a development background, but should be highly technical. Their job is to consider a specific business need or capability and to search out an appropriate method for meeting that need. Their research should include off-the-shelf solutions as well as custom-developed ones. Solution Architects research potential solutions, participate in RFPs, and ensure that the selected application (or applications) meets the need or capability and is appropriately implemented or developed. They will ensure that the solution vendor (or developer) provides appropriately updated documentation and that the solution conforms to any necessary governance processes.

Enterprise Architect

Where the Application Architect is interested in just a few applications, and the Solution Architect is interested in specific business needs (which may span multiple applications), the scope of the Enterprise Architect is the entire enterprise. This role must consider the overall health of the organization. This role is a part of (and often leads) governance activities such as determining strategic technologies and approaches and evangelizing those technologies and approaches. The Enterprise Architect often works with C-level executive leadership to help translate the company’s strategic direction into real, tangible technological approaches and business process changes. In addition, this role is responsible for making sure that Developers, Application Architects, and Solution Architects are properly documenting their particular domains.

How the roles fit together

Keep in mind that this is only a general description of these roles. Many organizations come up with their job descriptions without a good understanding of what each of these roles actually does. Organizations also usually end up combining multiple roles into a single job function. For instance, Developers may also serve as Application Architects, Application Architects may also serve as Solution Architects, and so on.

While organization size may at times dictate role consolidation, in larger organizations you will have entire teams of the above roles, including Enterprise Architects. But while there will be many different teams of most of the above roles, there is often only one Enterprise Architecture team. That team will often be divided into different areas of specialization: Application Architects, Infrastructure Architects, Data Architects, Reporting Architects, and so on. Note that the roles above focus largely on the application architecture vertical. I didn’t specifically address the roles underneath each of the non-application verticals, but you should be aware that they do exist and will have a similar breakdown of roles unique to their area of specialization.

Take note that all of the above roles are technical, but they do not all align primarily with technology. Developers and Application Architects are the most strongly technologically aligned. Solution Architects and Enterprise Architects, however, are more closely aligned with the business as a whole.

You’ll notice that Solution Architects are typically aligned with business domains or specific business capabilities. Solution Architects often participate in business process development and refinement. They should be advocates of and for the business. It is extremely important that Solution Architects not get so aligned with a specific application or technology as to become biased toward it. For instance, Solution Architects should always consider off-the-shelf solutions in addition to custom-built solutions. Their loyalty is to the business, not to the technology.

Enterprise Architects are also aligned to the business, but their scope typically spans the entire organization and all of its business domains. They work to align the work of those business domains, and the technology systems that support them, to the overall company strategy. The Enterprise Architecture team operates largely at a strategic level but often gets involved in operational activities through the selection of strategic technologies and approaches for the enterprise.

The Enterprise Architect’s responsibilities

That’s the big-picture view of application architecture in the enterprise and where the Enterprise Architect fits into it. Now that you understand the big picture, you can more easily understand their more specific responsibilities. They are as follows:

  • Select appropriate technological systems and approaches to support the enterprise’s strategic direction.
  • Maintain an architecture repository containing current documentation of the enterprise, future (target) architecture designs, and reference architectures for design and research purposes.
  • Analyze and recommend new technologies as appropriate for enterprise adoption.
  • Fully understand how the organization functions, both from a business perspective and from a technological one.
  • Advise executive leadership on technical matters and help translate their wishes into technological directives.
  • Work with the business to make sure their needs are being properly addressed by the technology currently in use.

How does your organization implement the Enterprise Architecture practice?