Holistic Architecture - Architecture Domains and Crosscutting Concerns

A business as an enterprise is like a complex organism. To represent it using architecture models is both an art and science. This big nebulous organism must be represented in layers of Conceptual, Logical, and Physical level of details to help various stakeholders to make sense of the architecture. (See Architecture - Eating an Elephant: One Bite at a Time)

These layers of architecture must be sliced further in a manner that can bring design details of individual areas of the business in focus. To represent a complex entity like a business in form of an architecture model one must consider all relevant structural and operational aspects of the business.

One way to bring some order into this representation is to focus only on one specific aspect of the architecture at a time. An architecture domain is that partial representation of the business in architecture model that addresses specific area of concern for specific groups of stakeholders. Collectively descriptions of all domains paint a comprehensive picture of a state of the business.

The diagram below depicts main architecture domains and key crosscutting concerns. The architecture of an enterprise is a multi-dimensional model where each dimension highlights specific aspect of its structure and behaviour in increasing level of details, from conceptual to logical to physical level.?

Business Domain

This domain captures a snapshot in time of state of a business. The models and model-views represented within the business domain are intended for the stakeholders from strategic and core business functions.

Associated with each operating model at its core is the value creation engine consisting of value chains, customer journey maps, and value streams, and associated business capabilities that operationalize the operating models. These are the main business architecture objects represented in the form of ontological models that typically show various relationships of business capabilities with other business objects such as programs, projects, people, roles, business processes, user interactions, and technology assets consisting of information, applications, infrastructure components and even cost.

These architecture ontologies and associated artifacts with varying levels of details at the conceptual, logical, and physical levels collectively provide stakeholder-specific views and present a holistic picture of what the business is, what it does or going to do, and how it does whatever it is that it does at any given time. Design for such holistic models of a business falls under the business architecture domain.

Data Domain

At the core of all business operations is information and data which is produced, consumed, and exchanged by the business within itself and shared with external stakeholders such as customers, partners, and regulatory bodies. All transactional data used by the business for its routine end-to-end operations must be identified to get good understanding of what value the data brings to the business and how this value flows within larger enterprise ecosystem, so this invaluable asset can be managed properly.

This data must be modeled with varying level of details depending on the stakeholders’ interest, for example, in the form of conceptual, logical, and physical level entity-relationships diagrams. These data models then can be used to design how the lifecycle (CRUD cycle) of the information is managed and how data is processed and shared with users for decision support and other analytics usage.

Having a complete knowledge and understanding of all the important data and information entities owned and managed by the enterprise and how lifecycle and flow of these data entities is managed within the enterprise is an absolute necessity to build a data driven organization. Everything related to lifecycle and modeling of data falls under the data architecture domain.

Application Domain

An application from the end-user’s perspective is the frontend user interface; however, behind this frontend there usually is a complex web of distributed and integrated systems that collaborate to provide the needed functionality to the end user. Applications manage lifecycle of data entities and provide a way for users to interact with the data to consume it, transform it, and use it to make decisions and take actions in variety of ways.

Applications automate many manual tasks within the context of a business process. More the automation, the better it is for the business from operational efficiency standpoint. In a business typically there exist several hundred (or even thousands) of distributed applications that are choreographed within many interweaved business workflows.

The model of applications at varying level of details – conceptual, logical, and physical with designs of application’s internal logic and their integrations with other application systems is presented with static and dynamic views as per stakeholders’ needs. Development of application models and associated artifacts at various levels of details fall under the Application architecture domain.

Infrastructure Domain

In today’s technology driven businesses all data and application systems run on a cluster of computers and storage appliances and these distributed clusters of computers are networked with other clusters of computers within the business (e.g., private data centers) and outside of the business (public clouds) in a complex web of networks that can span an entire nation or the whole globe.

These computer systems must store every transactional state of the data that they process and share with other systems and need adequate storage. The compute, storage and networking resources can be scattered all over the local and wide area networks as they can be hosted in private and public data centers and clouds.

The design and modeling of compute, storage, and networking resources with varying levels of details – at conceptual, logical, and physical levels and putting them all together to create a snapshot of the business’s complex technology landscape falls under purview of the infrastructure architecture domain.

A complete view of business is represented using these four domain models along with description of the following crosscutting concerns. These crosscutting concerns, as the name suggests, cut across all the four main domains. Current and future state architecture models of business must capture a state of the business taking into consideration the crosscutting concerns to represent a complete and realistic state of the business.

Security

Security is pervasive throughout every operation of business. Security design, in and of itself, is a vast topic. It is evident from ever increasing number of high profile and large-scale data breaches and cyber attacks every year in today’s information age that security is one of the most discussed topics inside boardrooms in terms of potential enterprise risks.

Prevention is the best cure when it comes to security and all aspects of security within business must be planned, and sufficient security controls that are commensurate with likelihood and severity of the risks to the business must be developed and put in place. The state of business’s current and future security posture must be captured holistically at all levels i.e., conceptual, logical, and physical levels of the architecture models across all the main architecture domains.

Each of the main architecture domains pose number of security challenges and designers must plan sufficient security controls in the solution design to identify vulnerabilities, provide sufficient protection, detect intrusions, and respond to them quickly, and recover quickly from the incidents.?

The planning and development of security controls in all layers of the OSI model (Physical, Data Link, Network, Transport, Session, Presentation, and Application) and beyond come under the purview of security. Physical security falls outside the cybersecurity realms however the designers must keep it in mind while developing comprehensive security solutions.

All forms of governance around - physical and system access, authentication and authorization and everything related to these areas including policies, all areas of application lifecycle security from development, integration, to deployment via DevSecOps processes, data security in the form of encryption at rest and in transit, and finally security of infrastructure (compute, storage, and networking) itself with appropriate capabilities for monitoring, auditing, detecting, and alerting, fall within the purview of security concern.

Integration

Hidden integration efforts is one of the main factors behind the cost overruns in most large enterprise initiatives and oftentimes the integration designs are overlooked due to bad planning. Integration impacts must be identified and planned and represented with a varying level of details at conceptual, logical, and physical levels for all main architecture domains.

Designers must understand all integration touchpoints between business-to-business (B2B) and business-to-customer (B2C) interactions so that efficient business processes can be designed from the very start. Providing a seamless application user experience requires integration among various backend systems over application programming interfaces (APIs) and development of efficient data pipelines that support those applications. These two areas of integration collectively provide automation within business processes.

And finally, ensuring all needed infrastructure (compute, storage, and networking), regardless of its location, is seamlessly integrated to provide a single uniform IT landscape is a key part to be considered under integration concern.

Performance

Business must be designed from the start with optimal performance. Business performance can be managed by identifying and improving inefficient business capabilities. Business capabilities themselves consist of people, process, information, applications, and infrastructure components.

Therefore, the improvement in business performance is directly tied to the improvements in performance in individual architecture domains – Business, Data, Application, and Infrastructure.

It is very important to ensure that the performance goals and expectations are well-understood by the architects so the business capabilities can be developed and represented with a varying level of details at the conceptual, logical, and physical levels in the architectures for delivering the expected performance. The planning and development of the right solutions to address business performance falls under the purview of performance concern.

Availability

Business is expected to provide uninterrupted operations and services to its customers. However, interruptions do occur time to time and cause of the interruptions can be internal or external to the business. The business must eliminate root causes of interruptions, stemming from internal reasons. It must become resilient to the interruptions and be able to recover quickly and preferably automatically. It must maintain continuity of its operations and availability of services.

High availability of services is a critical factor and key indicator of business’s credibility and brand value. Some businesses promise 24/7 availability year-round and must do so despite natural disasters, so they must at all cost adhere to the promise to retain customer’s confidence and trust.

To ensure the promised availability limits (i.e., recovery time objectives), all the business-critical capabilities must be kept available according to the business’s needs and customers’ expectations. The business availability must be planned from the start of development of those capabilities.

Business availability and continuity requirements together referred to as resiliency requirements must be addressed for all components of the affected business capability, starting from people’s availability to process availability, all the way down to data, applications, and infrastructure availability.

Planning and development of architecture at varying level of details, at the conceptual, logical, and physical levels to ensure promised availability of business operations and services falls under the purview of availability concern.

Scalability

All businesses aim to grow every year (unless some disaster strikes) and therefore, they must plan to scale proportionately with the expected growth rate, with a better performance than previous year, or at least with the same performance levels. Also, with seasonal ebbs and flows in business, it must utilize costly resources effectively. Therefore, business must be designed to adjust for the scale variances in all architecture domains.

Critical business capabilities that must adjust to the scale variances must be planned and developed from the start to ensure they can cope with the variances. Starting with optimal staff planning and utilization, optimal business processes designs, all the way down to ensuring the transaction volumes generated under best and worst conditions can be handled by its business processes without degradation of services. This may require designing automatically scalable application, data, and infrastructure resources.

Planning and development of architecture at varying level of details, at the conceptual, logical, and physical levels to ensure scalability of business operations and services falls under the purview of scalability concern.

Reliability

Businesses aim to provide consistent superior quality of service all the time. In other words, they expect to be perceived by their customers to be reliable providers of goods and services. Businesses must be designed to handle unexpected interruptions due to errors (human and originated from technology). So, they must deploy defensive controls in anticipation of potential interruptions to minimize the impact or disruptions to their services and be able to recover gracefully out of the interruption.

All business-critical capabilities should be ideally designed from the start to be resilient, reliable, and antifragile. The designers must ensure that they plan the critical capabilities and all their constituent components to be resilient. Business must ensure that provisions are made within the organization to ensure sufficient people are available to routinely maintain and handle rare and unexpected outage incidences and ensure there exist skilled staff to develop, maintain and support the technology stack (i.e., application, data, and infrastructure resources). It should ensure that technology components are developed and deployed such that they can recover and heal easily (preferably automatically) after the incident.

The architects must ensure that appropriate observability controls are designed in the solutions and monitoring and proactive notification mechanisms are designed for the staff to prevent or minimize the impact of potential interruptions.

Business should consider formally establishing (or improving, if already exists) the reliability engineering capability to ensure everything related to business reliability is addressed with sufficient level of rigor commensurate with risk. Planning and development of architecture at varying level of details, at the conceptual, logical, and physical levels to ensure reliability of business operations and services falls under the purview of reliability concern.

Cost

Some may argue that cost concerns do not belong under architecture; however, in todays ‘pay as you go’ business environment it is increasingly becoming evident that designers of business capabilities must consider total cost of ownership of a given business capability right from the start.

Cost is another crosscutting concern of the architecture that applies to all architecture domains and designers must factor in the cost during assessment of solution alternatives e.g., buy vs build, own vs rent, on-premises vs fully managed/ hosted, etc. for a given business capability increment and work closely with the vendors and product/project management to keep the total costs of the solution down from the vey beginning of the planning stage.

Planning and development of architecture at varying level of details, at the conceptual, logical, and physical levels to ensure low or reasonable costs of business operations and services falls under the purview of cost concern.

A good architecture design of enterprise must represent all aspects of the business comprehensively and holistically by producing only the relevant architecture artifacts sought by the stakeholders for each of the main architecture domains and must consider potential impact from the crosscutting concerns and produce the models with conceptual, logical, and physical level of details.

Author: Sunil Rananavare, IT Strategy Planning and Architecture (CIO Advisory)

Follow me on LinkedIn to stay informed.

The views in the article are author’s own and not necessarily of his employer.