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 PC, smartphones, Robots, Drones, end-user devices, operating systems, platforms, virtual environments and documents, often within the scope of an organization. IT Infrastructure can be seen as a logical or physical structure. Architecture can be seen as the conceptual structure, ie a total concept.

The 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.

There are thousands of technology concepts that 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. 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 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 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:

  • TCPIP
  • DNS

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 make 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.

Architecting Solutions:

DEMO: Concept Mapping Software

How to generate diagrams using Excel on Dragon1 EA Tool

Learn to generate diagrams using repositories
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 Process Application Landscape for RPA

Retail, Agriculture, Oil & Gas