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 is a formal document containing 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 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 built 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.
Each requirement has its cost. If possible the costs or cost range is indicated by the architect together with 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.
Now an iterative architecture building process will take place 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 many design decisions and changes 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 is 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 stakeholders 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 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 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 annotation.
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 nanosized. With these symbols, you as an architect can easily indicate the difference in the AS-IS and TO-BE situation 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. 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 an overview of what the architecture is and what the structure will look like. And they 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 requirements the stakeholders have 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 put 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 3 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 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. 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. Every year when the structure or solution is used, it needs to be maintained and serviced. Now for that continuously things 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.
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 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.