Technical Architecture
Technical architecture, also known as technology architecture, technological architecture, or IT infrastructure architecture.
What is Technical Architecture
Technical Architecture is the name of the Total Concept that is applied to the IT infrastructure of an organization. IT infrastructure is a coherent set of interconnected hardware and software components, including networks, cloud services, servers, clients, printers, tablet PCs, and smartphones.
Robots, drones, end-user devices, operating systems, platforms, virtual environments, and documents, often within the scope of an organization, are also part of this.
IT Infrastructure can be seen as a logical or physical structure. The Architecture can be seen as the conceptual structure, i.e., a total concept.
One of the technical architecture views of an IT infrastructure.
The IT Infrastructure of an organization can be small, one computer, but also immense, like the data center of a banking company. Large IT Infrastructures also cost millions of dollars to maintain and keep operational for their users.
The whole company depends on whether your IT Infrastructure is big or small. So the business owner demands four things: 1) It must be strong (constructive) to withstand calamities, 2) flexible so it can be changed if new demands of technologies arise (adaptive),3) fit to service employees and clients for the job to be done (operative), and 4) appealing and inviting to use it (decorative).
These top-level requirements form the basis for the architect to design a total concept, including technology concepts.
Thousands of technology concepts can be part of technology architectures.
We will list the frequently used technical architecture concepts for certain functions here. Note that the primary difference between a function and a concept lies in the level of technology involved. If a word does not depict any technology, it is a function. In that sense, one could say functions are base-class concepts.
Common Technical Architecture Concepts
A list of technical architecture concepts is:
- Open system
- Closed system
- Computing
- Client-Server computing
- Server-based computing
- Client Computing
- Peer-to-peer networking
- Cloud computing
- Grid computing
- Computer Network (Star, Mesh, Tree, etc..
- Networking
- Network environments (OTAP)
- Networking computing
- Device
- Network Device
- Client (Fat, Thin, …)
- Server
- Switch
- (wireless) Router
- Hub
- (wireless) Bridge
- (wireless) Access Point
- (network) Node
- Gateway
- Firewall
- IT Security
- Virtualization
- Storage virtualization
- Application virtualization
- Network virtualization
- Client virtualization
- Centralized Computing
- Distributed computing
- Collaborative computing
- Consolidation
- LAN
- WAN
- Internet
- Intranet
- Extranet
- Internet of Things
- Sharing files
- Data Center
- Pool
- Shared pool
- Server cluster
- Single source of truth (SSOT)
- Connectivity
- Protocol
- Network Services
- Directory Services
- Printing Services
- Archiving Services
- File Transfer Services
- Application Services
- Messaging Services
- Infra Services
- Email server
- DevOps
- Virtual Machine
- SaaS
- IaaS
- PaaS
- Microservices
Technical Architecture Views and Visualizations
Now, we choose a high-level tech architecture (a total IT Infrastructure concept). The owner-client can sign off on this high-level model, allowing projects to implement it and the owner/client to pay for it.
But an owner/client demands a better-looking and more understandable visualization to base his decision on. In architecture, we call this a view: a representation of a model tailored to a stakeholder's viewpoint (their specific set of concerns).
A common list of technical architecture views is:
- Environments Views
- Domains Views
- Functions Views
- Services Views
- Processes Views
- Structure Vision (a combination of the five mentioned before)
- Architecture Vision
- Employees Views
- Financial Views
- Contracts Views
- Users/Connections Views
- Workplaces and Offices Views
- Traffic and Bandwidth Views
- Operational Views
- 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 or Principles View
- Elements & Components View
- Technical Products View
- Project-specific or 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 another and use it to make 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: sketches, drawings, diagrams, and impressions.
Technical Architecture Principles
Every concept consists of elements at the logical level, components and objects at the physical level, and technical products at the implementation level. The way the parts work together (collaborate) and produce results is called the concept's principle, aka the technical architecture principles. 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 needs to be implemented at a certain (maturity) level and a certain measure of rollout (%).
A list of common technical architecture principles is:
- Loosely coupled applications - ...
- Data Consistency - ...
- Data Ownership - ...
- Buy before build - Before reinventing the wheel, which is often much more expensive than buying, we check 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 use standards. Common standards for IT Infrastructure are:
Per concept, an architect draws a concept design sketch to have an owner/client approve the concept (and IT implementation costs and impact). Also, per concept, the architect draws a Principle details diagram. That diagram illustrates which elements and components should be in place and which should not.
If many elements or components of a concept fail, the concept will not work or produce results. The concept works optimally when all elements or components are available 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 decide whether to implement certain elements and components. Depending on the requirements and situational aspects, the architect will design a new, unique concept (often consisting of various generic concepts).
Landscape vs Blueprint
If you only draw the instances and types of a few classes that are part of the metamodel and not all of the details, the visualization is called a landscape.
If you draw all instances and types of all classes in the metamodel, along with all the details, you will have a blueprint.