Architecture Building Process

Getting an Architecture Design Assignment

As architect you are a designer of a total concept. The owner/client and stakeholders of a structure or a location, where a structure is to be build or realized, they have a vision, ambition, objectives and a full set of requirements with regards to a structure or solution. The requirements will resolve their issues and fulfill their needs and concerns. Only some of the requirements are so extreme or even conflicting that designing and realizing a structure in the normal way would not lead to a desired result. So the owner/client turns to the architect and gives him a design assignment. This is a formal document containing a statement of work defining roughly the boundaries of what should be done.

The architect gets the design assignment because he has put effort in inspiring the owner/client the past years with visualizations and information about the added value and the power of enterprise architecture. For inspiring owner/clients the architect makes use of a document called portfolio which is filled with effective architecture visualizations from practice.

Creating a Program of Requirements

The owner/client wants to have a structure or solution build or wants to innovate a structure he or she owns. The owner/client selects which stakeholders should be interviewed by the architect, so they will make time for the architect.

The architect asks the stakeholders of the structure or solution what their requirements are for current and future use, based on their needs, concerns and issues. The architect draws a map with functions and capabilities per element of the structure and the stakeholders write down the needs, issues, concerns and requirements they have per function. With this a Program of Requirements (PoR) is created for the design, innovation and realization of the new structure. This PoR is a formal document.

Every requirement has its cost. If possible the costs or cost range is indicated by the architect together with its importance as requirement. It is the architects jobs to facilitate the process towards a filled, correct and approved PoR.

Creating an Architecture Design

Based on the requirements an architect selects concepts with certain principles and combines them into one total concept (i.e. an architecture) answering to all the (conflicting) requirements.

Now an iterative process will take place in order to go from conceptual architecture design, via preliminary architecture design and definite architecture design to a detailed architecture design.

During every iteration the architect creates a lot of visualizations (sketches, drawings and diagrams, so the owner/client and stakeholders are enabled to approve of many design decisions and changing in the requirements.

The Architecture Design Book is a formal document that is created by the architect for this and exists in four different detailed versions.

The architect makes sure that the cost of realizing or implementing a structure or solution using certain concepts, principles, elements and components are clearly stated. It makes no sense to design a solution that no one can afford to build.

Concepts, Principles and Elements

Enterprises and organizations are unique. And what basic fundamental elements are for one organization, not even do exist in another organization. So a modeling language should not predefine or require to make use of certain specific elements that much. Also because architects have to deal with extreme and conflicting requirements and explore together with the owner/client and stakeholder the solution architecture design space, the architect must be able to start to design without any restriction on the implementation side.

Therefore Dragon1 recognizes concepts as parts of an architecture. Elements are the functional logical parts of a concept. Components and objects are the physical parts of an element and technical products are the implementational parts of a component or object.

Dragon1 does not dictate that every organization or enterprise need processes, services or products (in Dragon1 these are only elements of concepts). Some organizations really can do without. And because you as architect wants to be or need to be innovative it makes no sense in making use of certain elements or components mandatory.

Yes, in Dragon1 you are free to choose and design whatever concepts, elements and components, objects and technical products you like, that are required by the owner/client and stakeholders.

Automation, Digitization and Robotization

Enterprises and organizations are continuously changing. In the early 1900s we saw mechanization taking place in our enterprises together with the introduction of series and mass production in standardized processes.

Starting from the 1980s we have seen automation in our organizations taking place.

Today we are busy with digitization.

And the next decade will be all about robotization, virtualization and nanotization.

It is therefore that we have created attribute symbols to indicate whether an entity, like a concept, element, component or object is manual, automated, mechanical, digitized, robotized or nanotized. With these symbols you as architect can easily indicate the difference in the AS-IS and TO BE situation of the architecture and structure. And in time when new innovation arise, the list of attribute symbols will grow.

Supervising the realization of a structure or a solution

An architect supervises the realization of the structure or solution using a detailed design of the total concept consisting of 50 to 100 concepts. Always the architect creates a design sketch of the total concept, a blueprint, a roadmap and an artist impression of the architecture and the structure so various stakeholders have more insights and overview of what the architecture is and what the structure will look like. And they use the visualization to take or support their decisions. Every concept of the total concepts implements one or more functions of the structure in order to fulfill the requirements the stakeholder have with regards to performance and quality.

During the realization of a structure, or usage/application of an architecture, the architect takes decisions with regards to designs and the realization or implementation. All the decisions and changes to these designs are put in a formal document called Architecture Realization Document. And if these designs need to be changed, they will be changed and the change will need to be approved by the owner/client and the stakeholders again.


Architects make use of plateaus, situations and periods. In Dragon1 we have defined WAS, AS-IS, PLATEAU 1, PLATEAU X, TO-BE and ENVISION as predefined names of plateaus. TO-BE often is 3 years ahead and ENVISION 5 to 10 years.

Suppose you want to draw a PLATEAU 1 architecture diagram. You want to show what entities used to be there and what entities will be there. In Dragon1 you can make that distinction with line styles: solid line style means an entity currently is there, dashed line style means an entity will be there in the present. A dotted line style means an entity was there, but now is not anymore.

Naming conventions

In Dragon1 we use the following naming convention for entities: [type].[class].[instance]. For example the sales business process of an organization would be: business.process.sales. And a monolithic application architecture would be: application.architecture.monolithic

On Dragon1 you can switch to shorthand notation (only the instance name will be shown in diagrams). The shapes fill in the type and class for you.

Maintenance, support and renewal

After a structure or solution has been build or realized and put in to use, the work of the architect is not over. Every year when the structure or solution is used, it needs to be maintained and serviced. Now for that continuously things needs to be repaired and replaced. And sometimes it is necessary that you as architect are consulted or informed to about what products or material to use for the maintenance or servicing.

Now in time needs and objectives will change and thus the requirements for the structure or solution. Here you as an architect can advise or redesign extensions, renewals and changes to the original structure but maintaining its original architecture, concepts and principles.

At enterprises and organizations not every structure or solution often was build using enterprise architecture. However enterprises and organizations change continuously. Nowadays in organizations one of more architects are employed and a TO-BE architecture is present, the architects play a role in advising how the design and realization should or could making use of certain concepts, principles, elements, components, rules, norms and standards, in order to move towards or stay within the boundaries of the TO BE architecture.

Strange as it may seem, but this is how working with enterprise architecture often starts in an organization. The architects have the job or task to reengineer the current architectures, with their concepts, principles, elements and components but also the implicit requirements, design decisions, etc...

When in the past architecture was reactive and project focused, people used to create Project Start Architecture. Today we prefer to use only Solution Architectures instead and create Solution Architecture Design Documents as formal documents.