Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Characteristics of Good Architecture

It is difficult to define what the characteristics of good architecture are when there is still vigorous and lasting debate about what the term 'architecture' actually means in the context of enterprise systems in the Twenty-First Century. The Roman architect Vitruvius defined three characteristics of good architecture in his treatise De Architectura more than 2,000 years ago. Interestingly it is the only surviving text from antiquity describing architecture. These principles are:

  • Durability (Firmatis) – It should stand up robustly and remain in good condition
  • Utility (Utilitas) – It should be useful and function well for the people using it
  • Beauty (Venustatis) – It should delight people and raise their spirits

These ancient characteristics can be elaborated on and expanded to apply to the Enterprise Architectures that are developed in the Twenty-First Century.

Enterprise Architecture quality example modeled in Sparx Systems Enterprise Architect

Qualities of Good Architecture

To be effective, an architecture must have a number of qualities or characteristics. Enterprise Architect provides an extensive set of features and tools for helping the Architect produce architectures that are of high quality. This table contains some of the most important qualities, with a description of how Enterprise Architect can be used to ensure the qualities are built into Architecture created and maintained in the tool.



See also


An architecture should be strong and not be vulnerable to minor changes in the business, information, application and technology systems. Enterprise Architect can assist in ensuring that the architectures are well integrated and related to each other and provides a number of tools such as the Traceability window, the Relationship Matrix and the Insert Related Elements feature that can be used for this purpose


An architecture that cannot be implemented will mean that the goals and objectives of the enterprise will not be met. It is best to identify these requirements as quickly as possible so as not to disappoint the party who requisitioned the architecture work. Enterprise Architect can assist by allowing architects, designers and developers to discuss the architecture and determine its feasibility using the Discuss & Review window and by mapping the Enterprise Architecture to Capability or Solution Architectures.


An Architecture must have utility that, when implemented, will result in practical outcomes. Architectures that are elegant but do not provide demonstrable and measurable value to the stakeholders or the parties that requisitioned them will ultimately not be successful. Enterprise Architect has tools that allow an architecture to be visualized and understood by a diverse group of stakeholders, allowing any problems with utility to be discovered early in the architecture process.

Relationship Matrix


An architecture is a living entity that describes a target state and - once implemented - will become the new baseline state. The architectures should prove to be durable with the passage of time and be resilient to changes in the business and technical environments that might occur over the lifetime of the architectures. This implies that they must - as much as possible - pre-empt the future conditions and environments.


The architectures must be flexible and be able to adapt to changing conditions and also provide enough guidance for implementation teams that have the knowledge of their discipline to make the important and necessary decisions about technical problems and opportunities. Architectures that are created with too much detail will often result in brittle and inflexible designs and implementations resulting in systems that cannot adapt to changing circumstances and environments. Enterprise Architect has a wide range of features that can assist with change including the Change element, the Baseline facility and the Kanban diagrams that allow Requirements Features, User Stories and more to be visualized and prioritized.


It should be possible to verify that the architecture will perform as designed and that there would not be side effects that result from the architecture and the parts of the enterprise that it impacts. The ultimate test of this is whether it delivers the business value that was promised in the Vision Statement. Enterprise Architect can be used to model the measures that are defined to verify that the Business Objectives (and therefore the Goals) have been attained.


Architectures must have both form and function and it is a good test of an architecture to measure its elegance. An architecture that is well designed will tend to be elegant and have a simplicity of form that will be obvious to those that take the time study it. Enterprise Architect has extensive features that allow the elegance of an architecture to be visualized including the ability to create professional publications that can be generated automatically from the tool using a series of built-in or user defined templates.


An architecture is a description of the an enterprise at a particular level of detail and does not exist in isolation but is typically related to business drivers and goals and other architectures at the same level or higher or lower and to implementation programs and projects. Enterprise Architect allows elements to be traced in any direction and provides a number of useful tools to visualize the traces including the Relationship Matrix, the Traceability Window and diagrams. The Insert Related Elements facility can be used to automatically construct a diagram of traces almost magically creating expressive and never before seen views of the repository.