The theory described here is part of the Dragon1 open EA Method
Stop Producing Un-used Architecture Principles
Every architect, whatever the type of structure, solution, or domain he designs, thinks or knows that architectural principles are important. Owners/clients and stakeholders believe or are aware that it is important. Even if they do not know exactly what principles are and what they look like. It's like a reflex reaction.
But how bad is it that all those thousands of architectural principles developed and documented are not used?
If you think Enterprise Architecture Principles are very important, so important that you take the effort of developing or documenting them, you'd better have them used. Or else it has been a complete waste of time. This article presents a framework for your enterprise architecture principles and patterns to ensure they are implemented correctly and effectively.
Tracking and Tracing Architecture Principles
Whatever the definition or statement of a principle, you should be able to track and trace them. We mean tracing back, walking down a path back to strategic requirements and literature: What is the cause, argument, reason, or justification?
Every architecture principle made part of an architecture should be documented and showable, what strategic requirement made the architect propose the principles to the owner/client and stakeholders. What literature contains best practices, experiences, and argumentation that application of the principle brings the desired benefits in a certain context.
With tracking, we mean from now on a path and seeing how, in later stages than architecture development, like the design and realization of a structure or solution, the principle is applied and what the feedback on applying the principle was.
If we can track and trace architecture principles and if stakeholders have taken decisions supported by principles or changed a design or realization techniques, only then can we say: the enterprise architecture principles were used. At that point, the enterprise architect was valuable, and the principle added value.
Structure and Architecture
In building architecture and landscape architecture, there is always an owner/client who contracts an architect to have a design created of a structure that suits the needs of the owner/client and the stakeholders of the structure. An architecture is a total concept, a unique combination of concepts applied to the structure in design and realization. This will result in a structure that is more robust, aesthetically pleasing, and usable/functional than it would have been if it were not designed using a total concept, but rather designed based solely on a set of requirements.
Everyone knows the Colosseum in Rome, Italy. The Colosseum is a structure, and a half-open amphitheater is a type of architecture (a total concept) used to design and realize the Colosseum. There are many amphitheaters, but there is only one Colosseum. In New York, we have Central Park. Central Park is a masterpiece of architectural landscape design. Central Park's architecture (total concept) is a romantic rural-urban park with an overarching artistic purpose. You can see that a mixture of landscape concepts has been combined to create a unique park that suits every New Yorker and world citizen.
In enterprise architecture, it is or should be the same as the word architecture from the other sciences: There is a structure and an architecture. And a project to design and implement the structure with an architectural application. The architecture is a total concept; the architect is a designer of total concepts and structures, as well as a supervisor of their realization.
The Making Of An Enterprise Architecture
Suppose an owner/client of a local shoe manufacturing enterprise wants to survive the digital era. He contracts an enterprise architect and asks them to design and implement a new and modern enterprise that his enterprise can migrate to or transform into. After consulting with the key stakeholders and drawing on his experience, the architect proposes the following high-level enterprise architecture to the owner/client: Why not become the best online company for people to design their shoes and sell their designs? If they want shoes, they upload a design that is produced or printed per pair.
The owner/client, after taking a deep breath, says YES to this proposal and now asks for a design sketch from the architect on this proposal and that he creates an architecture design that the people who are going to create a detailed design of the new enterprises and the people who are going to realize the new enterprise can use as guiding instrument.
The architect agrees and starts to create a program of requirements with the stakeholders. He uses this program of requirements, combined with his experiences and inspirations, to select a set of 30 concepts that together form a high-level architecture. Later, these 30 concepts will be grouped and further detailed. The concepts may collide, resulting in new, morphed concepts being invented.
The design sketch is created by visualizing every concept with an illustrative picture that shows recognizable situations and creating a nice composition in the context of these pictures.
By the law of nature, an architect fights entropy with a construction that gives room to operations in a certain space. The construction is covered with (functional) decoration. This goes for the building architect, landscape architect, and enterprise architect. The total concept must address constructive, operative, and decorative concerns and issues. The concepts must address these three aspects. And don't worry. You will later see that this also works in an enterprise.
The architect is on his way to creating an architecture for the structure of the owner/client. What is very interesting about architecture is that the architect can use all of his creativity and experience to create a unique architecture (total concept). As in building architecture, every structure can and should be unique.
From Concepts To Principles
This article is about principles and not concepts, you might say. In Dragon1, principles are defined as the way an entity (or system) operates, producing specific results. That means a concept, as a conceptual system, has a concept principle. And that concept principle explains how the concept works, producing results. The concept principle at the logical level tells how elements (logical functional parts) collaborate. At a technical level, the principle explains how components and objects interact and collaborate.
Every concept that is part of an architecture (total concept) for a structure is an architectural concept for a structure. And the principle of an architectural concept is an architecture principle.
For example, if 'Online Company' is an architectural concept for an enterprise, then the 'Online Company' principle is an architecture principle of that enterprise. By the way, the first principle of an 'Online Company' is: By always and only using the internet to provide all kinds of (self) services to the public whenever possible, the customers and the company always have the advantages of everything the internet has to offer, like cutting cost overhead, staying adaptive and agile, removing shackles in chains, reducing the carbon footprint, being forever scalable, and so on, and so on.
30 Architecture Principles Will Do
Based on experience, the enterprise architecture of big international companies can be documented at a high level with 30 architecture principles. That means an architect must worry about correctly formulating and visualizing (as a mechanism or pattern) 30 architecture principles.
It comes down to HOW to get the balanced set of 30 enterprise architecture principles. Of course, there are no limits; you can say that, for each type of architecture (business, data, application, solution, etc.) or project, you also establish 30 architecture principles. Well, that is completely up to you.
Related Posts
If you liked the blog, you probably also will enjoy the following related posts: