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.