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:
- Multiple solutions, all independent but with overlapping goals, data and users. This is often exacerbated by acquisitions of software solutions.
- Each solution has their own team focused on their own problems and roadmap, other teams requesting features are given low priority and there is limited communication (if any) between teams.
- Wastage in overlapping features, duplicate code, inconsistent formats
- No central data lake to extract value from, each team has their own data storage solution and preferences.
- Often no multi-region strategy and solutions not architected for this because each team is focused on their own geographical region.
- Bad user experience for users of multiple solutions due to multiple logins, different branding, different UI controls, etc.
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:
- User Experience and branding, a common library of assets should be established
- Cybersecurity best practices and specific tests that should be applied to each solution
- Global solution best practices and standards, these are guidelines to work towards, not rules to be enforced on existing solutions. They offer a baseline for new projects and project teams and include things such as software recommendations, guidelines for agile methodology, design thinking, prototyping, etc. and libraries, sdks, templates and examples for coding and infrastructure standards (including multi-region strategies).
- Using the global solution best practices, the enterprise architect can engage each individual team on understanding how far their solution is from the best practices and a realistic timeline to work towards that. This can be done without forcing radical changes into the existing platform.
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.
- Multiregion server deployments are expensive and almost always underutilized in some regions. Serverless only costs based on actual utilization, not server uptime.
- Serverless architecture almost always includes an API backend, it is the only way front and backend can communicate with webapps compared to Java or PHP, for example, where an API is not necessarily needed.
- Microservices are incredibly re-usable. Think of them like a central app store within your organisation. For example, you would have an image processing microservice. You don’t need to have a different one for each solution, you can have 1 central image processor that all solutions can use.
- Serverless architecture can do highly accurate cost tracking on every request, stored data and transfer, and tie this back to specific users, teams, departments and projects for both internal and external billing based on actual usage.
- Moving to microservices when moving a legacy app to the cloud or when changing an existing solution to be consistent with others, does not have to be a massive project with a big budget. It can be a step-by-step process over a longer timeline moving small bits of functionality from the old app into a microservice. It is very manageable without adding excessive workload to the team.
Innovation
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.
- Challenge teams to continuously improve their solution, making it more global and collaborative
- Focus on the user experience, how can the experience be improved by leveraging existing solutions, shared features, improving workflows and UI
- Association across solutions and target audiences, where could there be opportunities to drive new sales, improve solutions with features from other solutions, get existing solutions into new verticals, etc.