Initially, architecture was primarily used to construct buildings, bridges, etc.; it was visible directly in the final result. For example, gothic or modern architecture is directly associated with actual buildings. As a result, the term “architecture” is often used to refer to two concepts: a set of rules and the design of an object based on those rules.
Having multiple meanings is not an issue when applied to similar replicated objects, such as machines, CPUs, software, etc. Even if the architecture is not visible, it is evident that it consists of a set of rules, while the object itself is designed, manufactured, or built according to those rules.
An enterprise is much more complex than any of those objects.
To be competitive, every enterprise must strive to be different, ideally unique, and protect and regularly renew that differentiation.
An enterprise comprises complex components such as domains, business units, data, applications, infrastructure, and security, each with internal architectures and designs.
As an enterprise and its components change over time, they need to manage various impacts and requests, both planned and unplanned, from internal and external sources.
An enterprise may also encompass other enterprises, such as merged or separate business lines, subsidiaries, products or services. These sub-enterprises could operate almost independently or share some components, but each must have its enterprise architecture and design to be considered an enterprise.
On the flip side, an enterprise must make the most of existing components and knowledge available to be cost-efficient.
People join and leave the company, and their knowledge, skills and experience must be as relevant as possible.
Building everything from technology to skills in-house would be highly inefficient and costly.
These challenging aspects pose methodological and non-functional requirements for Enterprise Architecture (EA) as an instrument to understand, design, support, and develop complex objects.
Methodologically, to deliver real value and be an effective instrument, enterprise architecture must define the enterprise in three primary dimensions:
1. Structure dimension: EA must encompass the enterprise from top to bottom, including management, business processes, technology, data, infrastructure, and machines.
2. Organization dimension: EA must cover the enterprise processes from left to right, upstream to downstream systems, marketing to sales, and after-sales support.
3. Agility and reliability dimension: The enterprise designed according to the EA must be robust in managing external and internal risks and shocks and agile and efficient in achieving goals.
The complexity of an enterprise prioritises three non-functional parameters of EA:
1. Adaptability: EA must be adaptable to new goals, innovations, shocks, and emerging technologies.
2. Usability: EA must be structured and modular to present a complex enterprise or a set of enterprises in manageable, consistent, usable modules.
3. Integrity: EA must integrate all other components and ensure that integration over time.
Storing all those aspects within a single entity would make it unwieldy to maintain over time and modify in line with changes in the organisation or its parts. This would necessitate a complex and labour-intensive management process involving multiple subject matter experts and requiring high-level approval for any alterations. Even splitting the entity into multiple documents would not be very helpful, given the need to coordinate changes across various documents with cross-references.
In many instances, this challenge has narrowed the scope of enterprise architecture, simplifying EA and diminishing its practical value in formal delivery.
This methodological issue often extends the scope to adjacent areas such as strategy and engineering, blurring the focus of EA.
The most effective way to address this challenge is to separate enterprise architecture from enterprise design.
Enterprise and component architectures form one hierarchy, while enterprise design and component design form another. These levels and hierarchies are connected and aligned through requirements. Please refer to the image below for a visual representation.
The green arrows are updates of the architecture when the design does not align with the architecture. Those design exceptions must be approved via governance, and changes must be incorporated into the architecture. The orchestration of design and architecture is mandatory and is the direct responsibility of the enterprise architect and architects/designers who designed the changes.
In that structure, the architecture provides stability and consistency; the design provides agility and integrity.
EA must integrate all dimensions at all levels and components with optimal abstraction and details. That set of rules, the enterprise architecture, must be integrated and orchestrated with the enterprise design, as shown in the picture above.
A “big picture” that includes EA, crucial environment parameters, risk management framework, business and technology strategies, and engineering designs forms an enterprise model that creates a powerful synergy effect for company management.
For a big company, the architecture and model are too complex for manual processing and management and, therefore, require automation through correct processes, data, skills, and tools.
The described approach is not new to us. We perform these activities and create models in our day-to-day lives, some continuously and some instinctively. That approach is sufficient for our tasks if we achieve the result.
Managers of complex enterprises must perform these activities continuously, correctly, and efficiently, without leaving gaps, and manage all risks while identifying opportunities.
These days, the right enterprise architecture with the synergy effect, processes, and tools is essential, not optional.
Молодец. Хорошее начало.