Technical Architecture Models and Views
This page describes in essence how the Dragon1 open EA method defines Technical Architecture and how to create and publish technical architecture on the Dragon1 platform.
Technical Architecture is the total concept for the IT Infrastructure. Other names used for this architecture are Technology Architecture and IT Infrastructure Architecture.
IT Infrastructure is a coherent set of interconnected hardware and software, like networks, clouds, servers, clients, printers, tablet PC, smartphone, Robots, Drones, end-user devices, operating systems, platforms, virtual environment and documents.
Purpos IT Infrastructure of an organization can be small, one computer, but also immense, like a data center of a banking company. Big IT Infrastructures also cost millions of dollars to keep operational (available) for its users.
Whether your IT Infrastructure is big or small, the whole company depends on it. So the business owner demands four things: the IT Infrastructure must be strong (constructive) to withstand calamities, it must flexible so it can be changed if new demands of technologies arise (adaptive), it must be fit to service employees and clients for the job to be done (operative) and it must be appealing and inviting to use it (decorative). These top-level requirements are the basis for the architect to design a total concept with technology concepts or IT Infrastructure concepts.
A total IT Infrastructure concept could look like the figure above. A concept is an abstraction of an implementation, an approach or idea. There are thousands of technology concepts that can be made part of a technology architecture.
We will list here ten frequently used concepts for certain functions. Note that the difference between a function and a concept is the amount of technology. If a word does not depict any technology, it is a function. In that sense, one could say functions are base class concepts.
- Networking: Virtual networking
- Printing: Follow me printing
- Mailing: Email
- Computing: Cloud computing, Server-based computing, Client Computing
- Client Computing: Tablet PC, Smartphone
- Application Management: Web applications
- Database Management: Relational Database Management Systems (DBMS)
- Security: Firewall
- Service Management: Skilled Help Desk
- Environment: Development Environment, Testing Environment, Production Environment, DevOps
All these concepts are used in the Technical Architecture Diagram above. Note that none of the words above are product names and note that some of the concepts are elements of other concepts.
Based on requirements in the Program of Requirements and on the creativity and experience of the architect, he proposes towards the owner/client (they on paying for it all) to make a concept part of the total concept.
Technical Architecture Views and Visualizations
Now we have a high-level technical architecture (a total IT Infrastructure concept. This high-level model we can have signed off by the owner client, so it can be implemented by projects and payed for by the owner/client . But an owner/client demands a better looking and more understandable picture to base his decision on. In architecture we call this a view: a representation of a model customized to stakeholders viewpoints (their set of concerns).
A common list of technical architecture views are:
- Environments View
- Domains View
- Functions View
- Services View
- Processes View
- Structure Vision (a combination of the five View mentioned before)
- Architecture Vision
- Employees View
- Financial View
- Contracts View
- Users/Connections View
- Workplaces and Offices View
- Traffic and Bandwidth View
- Operational View
- Vendor lock in View
- Security leaks View
- Platforms View
- Technical Debt View
- Open vs Proprietary Solutions View
- Contingency View (Cold / Hot standby View)
- Design Patterns View
- Building Blocks View
- Concepts View
- Principles View
- Elements View
- Components View
- Technical Products View
- Project specific View
- Solution specific View
- Concept Design Sketch
- Principle Details Diagram
- Artist Impression
- Technical Strategy Map
- Technical Architecture Roadmap
Depending on your job or role you might be interested in one view or the other and use it to take decisions, set goals, measure progress or (re)direct work or a project.
In Dragon1 a visualization is a graphical representation of views. We have four types of visualizations: sketch, drawing, diagram and impression.
Technical Architecture Principles
Every concept consists of elements at logical and of components and objects at physical and of technical products at the implementational level. The way the parts work together (collaborate) and produce results, is called the concepts principle. In Dragon1 a principle is not a normative statement, but a way of working statement.
Every concept that an architect makes part of the architecture need to be implemented at a certain (maturity) level and at a certain measure of rollout (%).
A list of common technical principles (the way technical concepts work) are:
- Loosely coupled applications - ...
- Data Consistency - ...
- Data Ownership - ...
- Buy before build - Before reinventing the wheel, that is often much more expensive than buying, we go and look if someone else already has a wheel we need.
- Single source of truth - The same type of data may only be stored in or retrieved from a certain database.
- DMZ (Demilitarized Zone) - Every firewall has a DMZ
- Remote Management - All devices can be managed remotely because of...
Next to principles and concepts we make use of standards. Common standards for IT Infrastructure are:
Per concept an architect draws a concept design sketch in order to have an owner/client approved of the concept (and IT implementation costs and impact). And also per concept, he draws a principle details diagram. That diagram shows what elements or components should be in place or not.
If many elements or components of a concept are failing, the concept will not work at all or produce results. If all elements or components are available the concept will work optimally and produce the intended results. With diagrams and colors, the architect has to make visible what is and what is not in place.
These visualizations are then used by stakeholders to take decisions on implementing certain elements or components or not. And depending on the requirements and situational aspects, the architect will design a new unique concept (often consisting out of various generic concepts).
IT Infrastructure Landscape view
If you only draw the instances and types of a few of the classes that are part of the metamodel and not all of the details, the drawing is called a landscape.
IT Infrastructure Blueprint
If you draw all the instances and types of all the classes that are part of the metamodel and all of the details, the drawing is called a blueprint.