Based on job descriptions posted on recruiting websites, it is easy to get confused about the role of enterprise architects (EAs) versus solutions architects (SAs). Both types of postings often require years of experience in specific industries, business applications, programming languages, and infrastructure technologies, as well as skills such as communication, project management and leadership by influence. Both EAs and SAs need a strong understanding of business needs, technological trends, and the ability to communicate effectively with stakeholders. They both work towards aligning IT capabilities with business goals. In some organizations, individuals, typically titled as enterprise or chief architects, fulfill both roles.
The roles have distinct definitions, though. An enterprise is a single organization or multiple organizations that share a mission, e.g., cooperating government agencies or supply chain partners. EAs focus on creating holistic models of an enterprise’s current and desired strategy, structure, behavior, information, and IT assets. These models, which include fundamental concepts and the principles by which they evolve, are known as enterprise architectures. EAs then develop realistic architectural roadmaps, i.e., sequences of baseline, transition, and target architectures that align with the enterprise strategy, i.e., its goals and the methods it has chosen to reach them. They also develop standards, principles, guidelines, and reference architectures that guide the implementation and sustenance of enterprise architectures.
Enterprise architectures and roadmaps guide complex and fundamental change, a.k.a. transformation, which spans the structure and function of the enterprise, i.e., business architecture, as well as change in its data, applications, and technology. They may guide change across the entire enterprise or focus on part of the enterprise or one of its capabilities.
EAs work with program and project managers to plan initiatives that progress the enterprise through the roadmap. To transition from one architecture to the next in a roadmap, an organization must find solutions that address challenges such as creating a new business organization or process; creating or augmenting a new data repository; modernizing or replacing a suite of applications; or embracing innovative technology for computing, networking, hosting, or storage. Therefore, implementation programs consist of projects that deliver solutions, and SAs guide these projects by delivering solution architectures and guiding or performing solution design and development. SAs deliver their work within the constraints set by EAs.
In general, EAs are more strategically focused, while SAs tackle specific challenges that stand in the way of implementing the roadmaps produced by EAs. In some organizations, particularly larger and well-established ones, there are clear distinctions between the two roles. EAs sometimes lead teams of SAs that work within their assigned domains, which could be part of an organization, or specific applications, technologies, or capabilities.
Increasingly, though, organizations are embracing agility, which welcomes and incorporates new discoveries and requirements continually, and requires continuous feedback between all participants in enterprise transformation. Agile methods divide work into small, releasable units that are demonstrated to stakeholders, so that their feedback and new requirements are reflected in subsequent work. Therefore, as businesses embrace agility, EAs, SAs, project and program managers, delivery teams, end users and other stakeholders rely on feedback from each other to sustain value delivery in the face of new discoveries and changing business conditions. As they participate in agile processes, EAs and SAs must quickly deliver minimum viable architectures for each sprint (fixed time interval) in the scrum approach to agile, or each task or group of related tasks in the kanban approach.
Smaller organizations and those focused on delivering a few products often combine strategic and tactical architecture roles in single positions that can be titled enterprise architect, chief architect, or product architect. Small, product-focused organizations such as startups often can use off-the shelf SaaS solutions for their non-product needs, and have less of a need for true enterprise architecture.
Therefore, there is a continuum between EA and SA roles. If a solution becomes complex and multifaceted, it may require a roadmap that integrates it with the rest of the enterprise, and consequently require more attention from an EA. Also, in many mid-sized organizations, EAs perform both enterprise and solutions architecture. In all organizations, however, close collaboration between EAs and SAs is critical to their mutual success.
Finally, EAs and SAs can use some of the same frameworks, methods, and tools for their work. The TOGAF Architecture Development Method (below) is designed for EAs, but is also useful for SAs working on more complex solutions, since its comprehensive approach enables consideration of all implications of a solution architecture.
Figure 1 The TOGAF Architecture Development Cycle
The ArchiMate language, which is aligned with the TOGAF framework and designed for EAs, is also useful for solutions architecture, especially when combined with discipline-specific languages such as BPMN for business process design, entity-relationship (E-R) diagrams, and UML for software design. The cross-disciplinary nature of the ArchiMate language makes it useful for collaborating on solution architectures with diverse stakeholders.
Figure 2 Relationship between the ArchiMate language and the TOGAF ADM
Many multi-language modeling tools allow the modeling of correspondences between ArchiMate model elements and BPMN, UML, and E-R diagrams. Finally, both EAs and SAs can increasingly use commercial generative AI tools based on large language models to create first drafts of architectural specifications.
