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 architecture principles are important. Owner/clients and stakeholders think or know architecture principles are important. Even if they do not know exactly what principles are and how they look like. It's like a reflex reaction.
But how bad is it that all those thousands of architecture principles that are developed and documented, actually 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. In this article, we present a framework for your enterprise architecture principles and patterns to get them right and used.
Tracking and Tracing Architecture Principles
Whatever the definition or statement of a principle, you should be able to track and trace them. With tracing we mean tracing back, walking down a path back to strategic requirements and literature: What is the cause, argument, reason or justification. For every architecture principle that was made part of an architecture, it should be documented and showable what strategic requirement made the architect to propose the principles to the owner/client and stakeholders. And what literature contains best practices, experiences and argumentation that application of the principle, in fact, brings the desired benefits in a certain context.
With tracking we mean going forward on a path and see how in later stages than architecture development, like the design and realization of a structure or solution, the principle is applied on 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 we can say: the enterprise architecture principles were used. At that point, the enterprise architect was valuable and the principle had added value.
Structure and Architecture
In building architecture and landscape architecture there is always an owner/client that 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. The architecture is a total concept, a unique combination of concepts, that is applied to the structure in design and realization. This will result in a structure that is more robust, esthetic and usable/ function than it would have been if it was not designed using a total concept, but just designed given a set of requirements.
Everyone knows the Colosseum in Rome, Italy. The Colosseum is a structure and a half-open amphitheater is the architecture (total concept) that used for the design and realization of 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 architecture landscape design. The architecture (total concept) of Central Park is a romantic rural-urban park with an overarching artistic purpose. You can see that a mixture of landscape concepts have been combined to create a unique park that suits every New Yorker and world citizen.
In enterprise architecture it is or should be exactly the same as we borough the word architecture from the other sciences: There is a structure and an architecture. And a project to design and realize the structure with the architecture applied. And the architecture is a total concept and the architect is a designer of total concepts and structures and supervisor of the realization of structures.
The Making Of An Enterprise Architecture
Suppose an owner/client of a local shoe manufacturing enterprise wants to survive the digital era. He contracts and an enterprise architect and ask him to designs and realize a new and modern enterprise his enterprise can migrate/transform into. The architect, after talking with the most important stakeholders, and based on his experience proposes the following high-level enterprise architecture to the owner/client: Why don't you become the best online company there is, for people to design their own shoes and sell their designs. And if they want shoes they upload a design, and the shoes are produced or printed per pair.
The owner/client, after taking a deep breath says YES to this proposal and now asks a design sketch from the architect on this proposal and that he creates and 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 he starts to create a program of requirements together with the stakeholders. He uses this program of requirements and his experiences and inspirations to choose a set of 30 concepts that together form the high-level architecture. Later on, these 30 concepts will be grouped and the will be detailed. The concepts may collide, so new morphed concepts might be invented.
The design sketch is created by visualizing every concept with a metaphorical picture that shows recognizable situations and creating a nice composition in a 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 as well as the landscape architect and enterprise architect. This means that the total concept must address constructive, operative and decorative concerns and issues. The concepts must take care of these three aspects. And don't worry, you will, later on, see, that in an enterprise this also works.
The architect is on his way to create an architecture for the structure of the owner/client. And 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 architecture and structure can and should be unique.
From Concepts To Principles
Now this article is about principles and not concepts you might say. Well, the case is, in Dragon1 principles are defined as the way an entity (or system) works producing results. That means that a concept, as a conceptual system, has a concept principle. And that concept principle tells the way the concept works producing results. The concept principle at logical level tells how elements (logical functional parts) collaborate. At a technical level, the principle tells how components and objects 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 " 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 high-level with only 30 architecture principles. If the architecture principles are formulated and visualized (as mechanism or pattern) correctly, 30 architecture principles are what you only need.
The it comes down to the question: HOW to get the balanced set of 30 enterprise architecture principles. Of course, there are no limits, you can say that per type of architecture (business, data, application, solution, ...) or project you also put up 30 architecture principle. Well that is completely up to you.
The Framework
To be continued...