Get an Architecture Design Assignment
As an 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 built 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 the desired result.
So the owner/client turns to the architect and gives him a design assignment. This formal document contains a statement of work defining roughly the boundaries of what should be done.
The Architecture Building Process for getting an Architecture Design Assignment.
The architect gets the design assignment because he has put effort into inspiring the owner/client over the past years with visualizations and information about the added value and the power of enterprise architecture. For inspiring owners/clients, the architect uses a document called portfolio, filled with effective architecture visualizations from practice.
Creating a Program of Requirements
The owner/client wants to build a structure or solution or innovate their own structure. The owner/client selects which stakeholders should be interviewed by the architect so they can 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.
Each requirement has its cost. If possible, the architect indicates the costs or cost range and its importance as a requirement. It is the architect's job 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.
An iterative architecture building process will take place 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 can approve many design decisions and changes in the requirements.
The Architecture Design Book is a formal document 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 is clearly stated. Designing a solution that no one can afford to build makes no sense.
Concepts, Principles and Elements
Enterprises and organizations are unique. What basic fundamental elements are for one organization do not exist in another. So, a modeling language should not predefine or require the use of certain specific elements that much. Also, because architects have to deal with extreme and conflicting requirements and explore the solution architecture design space together with the owner/client and stakeholders, the architect must be able to start the 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 needs processes, services, or products (in Dragon1, these are only elements of concepts). Some organizations really can do without it. And because you as an architect want to be or need to be innovative, it makes no sense to make use of certain elements or components mandatory.
Yes, in Dragon1, you are free to choose and design whatever concepts, elements, 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 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 annotation.
We have created attribute symbols to indicate whether an entity like a concept, element, component, or object is manual, automated, mechanical, digitized, robotized, or nanosized. With these symbols, you, as an architect, can easily indicate the difference between the AS-IS and TO-BE situations of the architecture and structure. And in time when innovation arises, 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. The architect always creates a design sketch of the total concept, a blueprint, a roadmap, and an artist's impression of the architecture and the structure. Hence, various stakeholders have more insights and an overview of what the architecture is and what the structure will look like. They also use visualization to make or support their decisions. Every concept of the total concept implements one or more functions of the structure to fulfill the stakeholders' requirements concerning performance and quality.
During the realization of a structure or usage/application of an architecture, the architect makes decisions about designs and the realization or implementation. All the decisions and changes to these designs are in a formal document called the Architecture Realization Document. 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.
WAS, AS-IS, TO-BE, ENVISION
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 three years ahead, and ENVISION is 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, and dashed line style means an entity will be there in the present. A dotted line style means an entity was there, but it 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. 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 built or realized and put to use, the work of the architect is not over. When the structure or solution is used, it must be maintained and serviced every year. Now, things continuously need to be repaired and replaced. Sometimes, it is necessary that you, as an architect, are consulted or informed about what products or materials to use for the maintenance or servicing.
In time, needs and objectives will change, thus, the structure or solution requirements. Here, as an architect, you can advise or redesign extensions, renewals, and changes to the original structure but maintain its original architecture, concepts, and principles.
At enterprises and organizations, not every structure or solution often was built using an enterprise architecture. However, enterprises and organizations change continuously. Nowadays, in organizations, one or 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 make use of certain concepts, principles, elements, components, rules, norms, and standards, to move towards or stay within the boundaries of the TO-BE architecture.
Strange as it may seem, this is how working with enterprise architecture often starts in an organization. The architects have the job or task to re-engineer 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.