Technical Architecture

Also known as technology 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, like networks, clouds, servers, clients, printers, tablet PCs, and smartphones.


Also, Robots, drones, end-user devices, operating systems, platforms, virtual environments, and documents, often within the scope of an organization, are part of this.

IT Infrastructure can be seen as a logical or physical structure. Architecture can be seen as the conceptual structure, i.e., a total concept.

The IT Infrastructure of an organization can be small, one computer, but also immense, like the data center of a banking company. Big IT Infrastructures also cost millions of dollars to keep operational (available) for their 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 be 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.

Thousands of technology concepts can be made part of a technology architecture.

We will list here the 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.

Common Concepts

Common Technical Architecture concepts are:

  • 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
  • Email server
  • DevOps
  • Virtual Machine
  • SaaS
  • IaaS
  • PaaS
  • Microservices

Technical Architecture Views and Visualizations

Now, we choose a high-level technical architecture (a total IT Infrastructure concept. The owner-client can sign off on this high-level model so it can be implemented by projects and paid 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 Views 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 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: sketch, drawing, diagram, and impression.

Technical Architecture Principles

Every concept consists of elements at the logical level, components and objects at the physical level, and technical products at the implementational level. The way the parts work together (collaborate) and produce results is called the concept's 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 needs to be implemented at a certain (maturity) level and 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, which 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:

  • TCPIP
  • DNS

Per concept, an architect draws a concept design sketch to have an owner/client approve of the concept (and IT implementation costs and impact). Also, per concept, he draws a diagram of principle details. 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. The concept will work optimally if 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 make decisions on implementing certain elements or components or not. Depending on the requirements and situational aspects, the architect will design a new, unique concept (often consisting of various generic concepts).

IT Infrastructure Landscape vs Blueprint

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.

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.

Architecting Solutions

DEMO: Concept Mapping Software

How to use Dragon1 EA Tool

Learn to generate architecture diagrams using repositories
DEMO: BPMN Onboarding Process Example

DEMO: BPMN Onboarding Process Diagram - Measure Rules Compliance

Manufacturing, Financial Solutions
DEMO: Enterprise Architecture Blueprint Template

DEMO: Generate an Enterprise Architecture Blueprint to discover and solve RISK

Banking, Logistics, Healthcare
DEMO: Data Mapping Software

DEMO: Generate Application Landscape for SECURITY

Automotive, Financial Services, Health Care
DEMO: Strategy Mapping Software

DEMO: Generate Strategy Map for CLOUD ADOPTION

Government, Logistics, Banking
DEMO: Process Application Map

DEMO: Generate Landscape for RPA AUTOMATION

Retail, Agriculture, Energy, Oil & Gas