Classic Enterprise Architecture Domains
The most common enterprise architecture domains describe different parts of the enterprise architecture. Specialist architects usually develop domain architectures independently. When the domain architectures are put together, you have a complete enterprise architecture.
Each enterprise architecture domain will be useful on their own. When used independently, you must assume all other domains are static.
Good enterprise architects break the enterprise architecture into domains because it is easier to analyze and describe like things. They use the same techniques and skills to describe and analyze the components of an architecture domain.
There are many enterprise architecture jobs on a leading enterprise architecture team. If you want to explore the roles instead of the domains, jump over to the different enterprise architecture jobs.
Business Architecture Domain
Business architects develop the business architecture. It is the foundation for all other enterprise architecture domains. It will explain the operating model, organization, operational practices, and information flow of the enterprise.
Best practice enterprise architecture teams will be engaged in developing the target state and supporting improvements in business operations. Many IT-centric enterprise architecture teams use their business architects to document and explain business decisions to IT-centric architects.
We have a strong example of a business architect in the Business Architect's Approach to Architecting the IT Department.
When we are building enterprise architect's skills, developing an enterprise architecture team, or delivering TOGAF Certification Training, we have two central facts about Business Architecture. First, when business architects translate hopes, fears, and pre-built change plans from 'the business' they are doomed to low maturity. Second, assuming business architecture is developed and then the other domains are built to support it you will always develop a low-quality architecture.
Business Architecture development is explained in TOGAF ADM Phase B.
Security Architecture Domain
We also refer to security architecture to as information systems security architecture, and security architecture. This architecture domain is always very focused on IT. A security architect develops the controls that effectively manage risk associated with information and information technology. The goal of the security architect is to protect the enterprise, not the technology.
Best practice security architecture follows SABSA to balance the need to protect against the drive to succeed. Security architecture is also pervasive. Every domain, every element, and every decision must be considered in terms of risk and security.
Information Systems Architecture Domain
Information systems architecture is part of TOGAF. It encompasses all application and data architecture. A broader view of information technology architecture extends the domain to include infrastructure and other technology.
Data Architecture Domain
Do not get wrapped into a long-semantic discussion between information architecture and data architecture. Best practice will align information analysis with business architecture and data architecture with IT issues. A solid data architecture provides the most important constraints on your application architecture.
Application Architecture Domain
Best practice application architecture will focus on critical constraints about your software and integration. It will specify whether your organization should use SaaS, commercial software, large suites or specialist software, or undertake custom development. The application choices support different business activities. The selection is driven by your business architecture. As well, system boundaries and integration standards are critical. Without these top-level constraints, detail inside an application is of little practical value.
When we are building enterprise architect's skills, developing an enterprise architecture team, or delivering TOGAF Certification Training, we have two central facts about Application Architecture. First, until you have an Application Development Model, you cannot proceed. Until you know how your application choices enable and constrain your business architecture, the details of your applications are pointless. Second, if you jump into application functionality and integration, you will always develop a low-quality application architecture.
We explain Application Architecture development in TOGAF ADM Phase C - Application Architecture.
Technology Architecture Domain
TOGAF refers to a technology architecture domain. Other refer to infrastructure architecture. Do not get tied into a long semantic discussion.
A strong technology architecture provides enterprise agility and enables agile software development. It will balance between efficiency and enterprise agility.
Successful technology architectures guide and constrain:
- Other enterprise architect domain architects to the art of the possible
- Infrastructure planners on the criteria of success
- Solution architects and specialist technology architects on criteria to judge, criteria to succeed and priority
Learn about in TOGAF® ADM Phase D – Develop the Technology Architecture.
Infrastructure Architecture Domain
Your technology architecture is concerned with the technology, or infrastructure, that supports applications, data, and communications.
Modern Enterprise Architecture Domains
All enterprise architecture domains cover part of the enterprise architecture. Domains are created so a specialist architect can use techniques and skills appropriate to the problems of the domain. We also will create a domain to address difficult change challenges.
Modern enterprise architecture domains continually arise. We absorb most into a classic enterprise architecture domain as new techniques become mainstream.
Cloud Architecture Domain
The rise of public cloud services is changing how we address infrastructure architecture and application architecture. We find it interesting that classic infrastructure tried to define services that applications would consume, and that infrastructure and platform cloud architectures depend on this approach. The same this happens with SaaS. Software-as-a-Service clearly defines functionality and access through API, the two classic topics of application architecture.
Private Cloud Architecture and Public Cloud Architecture have a significant difference. When you need to develop the architecture of a Private Cloud you need to worry about how the services will be delivered. WIth Public Cloud you are selecting the available services.
Service Oriented Architecture Domain
Service oriented architecture, and micro-service architecture, are examples of enterprise architecture domains that arose, and folded into classic architecture domains. A few years ago, SOA was a big deal. It was going to transform everything. Today, it is part of a good application architecture.
Focus Enterprise Architecture Domains
All enterprise architecture serves two primary audiences - decision-makers and implementers. Decision-makers use the architecture to decide what changes to undertake, and to ensure the change is delivering expected value. Implementers use the architecture to ensure they understand the measures of value, and the constraints on their freedom.
Besides identifying different architects by the domain they work in, we will identify different architects by what type of problem they work on.
Agile Architecture
With the rise of modern agile software development practices, there has been considerable interest in how enterprise architecture relates. We find there are six use cases that cover enterprise architecture and agile. Good architecture development that supports the right purpose is independent of any change method. We find that enterprise architecture and agile fit together wonderfully.
Solution Architecture
Solution architects typically have a broad focus across multiple IT-oriented domains at the level of a project or solution. Solution Architects will work within the constraints of an enterprise architecture. They are typically very focused on supporting Implementers.
SABSA Domain Model
The SABSA Domain Model has nothing to do with Enterprise Architecture Domains. The word Domain simply means an area of knowledge or activity. The SABSA Domain Model simply uses this meaning.
Use the SABSA Domain Model to break an organization into examinable parts. Use the parts to establish risk ownership and governance.
The key to using the SABSA Domain Model is ensuring every domain has a definable boundary.
There are many enterprise architecture jobs on a leading enterprise architecture team. If you want to explore the roles, jump over to the different enterprise architecture jobs.
Do it Yourself Downloads for Enterprise Architecture Domains
Guidance on creating an architecture of composable services - whether business services or application services.
Industry Standard EA Capability Reference Model
Guidance on addressing risk and information security in your enterprise architecture.
Find the question you need to answer for a successful digital transformation