Introduction
In IT being an “Architect” means something different for almost everyone and the role and responsibilities varies between industries, countries and continents. So here are my 0.02€ on this.
I like to divide architects into the following groups/layers:
- Enterprise Architecture (EA)
- Solution Architecture (SA)
- Infrastructure Architecture (IA)
They can, of course, be divided even further, but in my experience, this works at a high level. I firmly believe that EA, SA, and IA should remain as distinct functions within an organization, each with its own reporting structure. This separation ensures that Enterprise Architecture (EA) focuses on strategic governance, Solution Architecture (SA) remains embedded in product teams, and Infrastructure Architecture (IA) continues to provide the necessary operational foundation.
This approach aligns with Svyatoslav Kotusev’s research on enterprise architecture governance, which suggests that keeping these disciplines distinct leads to better strategic focus, executional efficiency, and organizational alignment. Additionally, insights from “Enterprise Architecture as Strategy” (Ross, Weill, Robertson) emphasize that EA should focus on high-level strategic direction rather than detailed execution. “Fundamentals of Software Architecture” (Richards, Ford) further supports the distinction between EA and SA, reinforcing that Solution Architects must remain closely aligned with engineering teams for execution. “Team Topologies” (Skelton, Pais) highlights the importance of structuring architecture teams effectively to support flow and autonomy, while “The Art of Scalability” (Abbott, Fisher) underscores how separating governance from execution helps organizations scale more efficiently.
By structuring these functions independently, organizations can maintain a balance between governance and execution while ensuring that architecture decisions remain both strategic and practical. This separation fosters alignment between business strategy, technology execution, and infrastructure stability, ensuring that architecture is an enabler rather than a bottleneck.
Enterprise Architecture
From Wikipedia:
Enterprise architecture (EA) is an analytical discipline that provides methods to comprehensively define, organize, standardize, and document an organization’s structure and interrelationships in terms of certain critical business domains (physical, organizational, technical, etc.) characterizing the entity under analysis.
The goal of EA is to create an effective representation of the business enterprise that may be used at all levels of stewardship to guide, optimize, and transform the business as it responds to real-world conditions.
EA serves to capture the relationships and interactions between domain elements as described by their processes, functions, applications, events, data, and employed technologies.
This means that EA exists in the grey area between business and IT. It’s neither one or the other but it takes insight into both in order to understand how the business is affected by IT and vice versa.
Because of the close proximity to the business it’s usually EA that writes strategies on issues which are cross organisational and multi-year efforts. This ensures proper anchoring of strategies where IT and business (finance) must agree on business directions.
I’ve seen EA divided into something like the following:
- Overall solution, application, integration, API etc. architectures
- Data: Master Data Management & Analytics
- Hosting: Cloud, hybrid, edge, HCI, Managed and Onprem
- Security: Physical, Intellectual, IT etc.
- Processes: IAM, SIEM, ITIL etc
- Special areas from the business depending on industry like: Logistics, brewing, manufacturing, R&D, IoT etc.
Solution Architecture
From Wikipedia:
Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components.
Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through to the final manifestation of the software, typically in a planned and structured process.
Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products
I like to add an additional role named Software Architecture to the Solution Architecture layer and I differentiate between the two through the following:
- A Solution Architect is in charge of the overall solution architecture of a solution that may span multiple IT and business domains using different technologies and software architecture patterns.
- A Software Architect is in charge of a part of the overall solution usually within a single business domain and technology stack.
Although both roles are highly technical the Solution Architect is a bit more of a generalist and the Software Architect is a specialist within a certain technology stack.
Depending on the size of a solution you only need a single person to handle everything to multiple people people in both roles. Usually there’s a single Solution Architect in charge.
I’ve seen SA divided into the following:
- Building things from scratch
- Customizing existing platforms
- Non and Cloud Architecture Focus
- Microsoft 365 (Workplace) Architecture
- Mega corporation stuff like SAP, Salesforce etc
Successful organizations ensure that EA remains a strategic function rather than absorbing all architects into a single unit. Solution and Infrastructure Architects must be embedded in product teams and technology groups, ensuring a continuous feedback loop between strategy and execution. Without this distinction, architecture becomes detached from real business needs, leading to governance-heavy, execution-poor outcomes.
Svyatoslav Kotusev’s [1] research on enterprise architecture governance supports this view, emphasizing that EA should function as a decision-support structure rather than an operational execution layer. His empirical studies highlight that centralizing all architects within EA leads to inefficiencies, as solution and infrastructure architects require proximity to delivery teams to ensure architectural decisions remain practical and aligned with business realities.
Infrastructure Architecture
From Wikipedia:
Information technology operations, or IT operations, are the set of all processes and services that are both provisioned by an IT staff to their internal or external clients and used by themselves, to run themselves as a business.
With some additional skills like:
- Data center-infrastructure management (DCIM) is the integration of IT and facility management disciplines to centralize monitoring, management and intelligent capacity planning of a data center’s critical systems. Achieved through the implementation of specialized software, hardware and sensors, DCIM enables common, real-time monitoring and management platform for all interdependent systems across IT and facility infrastructures.
- Data center asset management is the set of business practices that join financial, contractual and inventory functions to support life cycle management and strategic decision making for the IT environment. Assets include all elements of software and hardware that are found in the business environment.
The IA is responsible for the foundation upon which all IT solutions depends on. Without IT Infrastructure nothing in IT works.
Designing, implementing and maintaining IT infrastructure spans from your internet router at home to the unbelievable physical size and complexity of cloud infrastructure data centres with under ocean network connections.
The IA takes their requirements from EA and SA and implements accordingly.
I’ve seen IA divided into the following:
- Infrastructure Experts
- Cloud (AWS, Azure, GCP etc)
- On-premises
- IaC and Monitoring
- Hosting: Cloud, hybrid, edge, HCI, Managed and Onprem
- Management and support teams for managed services
Cross Organizational Collaboration
In order to make sure that everyone knows what is going on all architecture is controlled through the Architecture Forum where the leads from each discipline meets and has the final say over the usage of technology and implementation of policies.
Example of how an Architecture Forum could be organized – the specific areas are examples
References
- “The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment” – Svyatoslav Kotusev
- “Enterprise Architecture as Strategy” – Jeanne W. Ross, Peter Weill, David Robertson
- “Team Topologies” – Matthew Skelton, Manuel Pais
- “The Art of Scalability” – Martin L. Abbott, Michael T. Fisher
For more references see https://birkholm-buch.dk/2021/02/12/useful-resources-on-software-systems-architecture/
