I’ll start with a description of the responsibilities of both solution architects and enterprise architects as its important to understand the differences. If your organisation uses different titles then you can find the one that best matches the responsibilities.

My Definition

A solution architect is an experienced technologist that creates functional designs for a given solution. In some cases this is quite high-level and includes the cloud architecture and functional epics. In other cases, some solution architects include detailed technical specifications for each user story. Importantly, they are typically working on a single solution such as the digital platform for a startup. Solution Architects often have a development or IT background, they deeply understand the technical requirements, risks and opportunities of a solution and can add significant value in translating user needs into developer specifications.

An enterprise architect tends to have more of a project management background. Their focus is on a portfolio level instead of individual solutions. Their deliverables are not solutions, but policies, roadmaps and alignment between multiple project teams. A solution architect does not necessarily make a good enterprise architect because they typically come from different backgrounds and capabilities, but I have seen many enterprises trying to shoehorn solution architects into this role.

Enterprise Problems

Because of missing an enterprise architect, or because they are trying to force an unsuitable solution architect into this role, many enterprises face the following challenges:

There are 2 ways to address these challenges. You could force all of the teams to adapt their project to a consistent architecture and code base, ultimately developing a single platform that merges all of the separate solutions. This is doable if there are not many solutions and they are already mostly compatible but it tends to be an uphill battle and many of the team members will leave.

Guidelines for Common Areas

A better way to address this, in my opinion, is for an enterprise architect to understand the needs and challenges of the individual teams, let them continue to work in their own way, but to establish guidelines for common areas.

1. Standards and Best Practices

The enterprise architect establishes the standards and best practices for all solutions within the organisation. This includes:

2. Roadmaps and Priorities

The enterprise architect is responsible for collecting, maintaining and communicating the roadmaps for all solutions within the organisation.

They are responsible for setting priorities together with the teams and ensuring there is limited duplication of features across multiple solution. If a feature is available in another solution then the first step should be to try and use the existing feature or add to it, before reinventing the wheel.

Besides sharing the roadmaps, the enterprise architect is also responsible for centralizing the code repositories for each solution and working with the teams to ensure their technical documentation is complete and up to date at all times.

This will enable an internal “open source”-style approach to solutions within the organisation. When team B needs features added to team A’s solution then team B can add those features themselves while staying true to the established best practices. This means that team B no longer needs to wait for team A to “get to those tasks” and there is no pressure on team A to have to change their priorities.

3. Shared Features for User Experience

Users always need to be placed first. User experience should therefore always be a priority over internal goals and silos. It’s the enterprise architect’s responsibility to break those silos and sometimes make and enforce difficult decisions that place the user first.

One of those decisions are shared features. These are common features that are centralized within the organisation, taken out of an existing solution and given to a separate team to develop and support.

Which features will differ per organisation, but a common one is authentication. There should be a central login interface for both internal and external users. A user can be sent to this login, then returned to the solution they wanted. This also enables single-sign-on between all solutions and centralizes account and access management, user personal details (GDPR) and related features such as password reset, profile management, etc.

4. Open API and Schemas

Having API access to each solution may require some tough changes and additional workload, but it's too important to leave out. The enterprise architect will work with the different teams to establish what needs to be changed and a reasonable timeline to implement it.

The goal is that every solution has a well-documented API for every backend feature. A secondary goal that has a bit more flexibility, is that the schema to communicate with these API’s is as consistent as possible across multiple solutions.

When solutions have an API they are able to share features between different solutions, they can be connected together to provide a frictionless experience to the end user as well as integrate into any number of external solutions.

5. Data Storage

Data is too important to organisations to let it be managed entirely by independent teams. There needs to be a central point where data is stored. This can be the main storage of the solution or it can be replicated data.

The enterprise architect needs to understand all the data being created within the organisation and design a data lake and strategy that is capable of handling all of it. This includes a multi-region strategy to make data available to different teams around the organisation as-needed.

Serverless Architecture

I also want to share why Serverless Architecture is very relevant for this topic and could be considered as part of the standards to work towards and for new projects.


Lastly, I also believe that part of the role of an enterprise architect is to challenge teams and drive innovation. They have a unique bird’s eye view of all solutions within the organisation so they need to make the connections and derive insights that individual projects teams are unlikely to be able to do.