Technical architecture: What IT does for a living

Technical architecture is the sum and substance of what IT deploys to support the enterprise. As such, its management is a key IT practice. We talked about how to go about it in a previous article in this series.

Which leads to the question, What constitutes good technical architecture? Or more foundationally, What constitutes technical architecture, whether good, bad, or indifferent?

In case you’re a purist, we’re talking about technical architecture, not enterprise architecture. The latter includes the business architecture as well as the technical architecture. Not that it’s possible to evaluate the technical architecture without understanding how well it supports the business architecture. It’s just that managing the health of the business architecture is Someone Else’s Problem.

Why technical architecture matters

IT always has a technical architecture. In some organizations it’s deliberate, the result of processes and practices that matter most to CIOs.

But far too often, technical architecture is accidental — a pile of stuff that’s accumulated over time without any overall plan.

IT Catalysts

As Figure 1 shows, during initial IT implementations, managed architecture costs more than just ignoring the subject and hoping for the best, but pays for itself over time as the advantages of a well-managed architecture — reduced maintenance and support costs, easier and less-fragile integration, and overall improved flexibility in addressing new business challenges — dwarf the initial investment.

What constitutes technical architecture

Before we get started, no, what you’re about to see isn’t the well-known TOGAF architecture framework. It isn’t inconsistent, but I’ve found what follows to be more concrete and an easier fit to real-world IT portfolios. But whatever framework you use, its purpose is to sort the bits and pieces of stuff IT manages into portfolios of parallel components for ongoing analysis and planning.

IT Catalysts

Figure 2 shows the components of technical architecture. It includes the external factors that influence it, its building blocks, and the standards it generates. One at a time:

External factors

These include business drivers, architecture principles, and technology trends:

• Business drivers: These are the broad IT capabilities the company will need, as inferred from its strategic goals. These aren’t requirements in the app dev sense. They’re broader than that. Examples might be machine learning, automated language translation, and facial recognition. Business drivers have a direct impact on the architecture; they also affect it indirectly by helping guide formulation of the architecture principles.
• Architecture principles: As explained in the last installment of this series, these are broad principles that define what constitutes “good” architecture in your business. They combine an overall knowledge of what constitutes good engineering with the company’s business drivers.
• Technology trends: No, you don’t have to be trendy. But you do need to recognize when a trend in the external technology marketplace will invalidate some components of your technical architecture or could create an opportunity to do something differently and better.

Technical architecture’s building blocks

IT architecture is layered and segmented. It’s comprised of applications, data, and technology. Drilling down, it consists of:

Applications: The portfolio of software programs business users make use of to do their jobs. The application layer is divided into three sublayers:

• Systems of record: The applications and application suites that serve as the authoritative source of information and business logic.
• Integration and synchronization: The inter-application interfaces that make sure applications whose data and business logic overlap agree with each other.
• Satellite apps and Integration APIs: By themselves, systems of record can be unwieldy ways to address all the fine-grained automation opportunities various business constituencies need addressed. Sometimes it’s better to implement specialty apps that connect to the systems of record, either directly through the integration sublayer or through APIs exposed by the integration layer that provide an integrated, idealized view of the underlying data and business logic.

Data: IT provides capabilities for managing two types of information: structured, aka data comfortably represented in tables and forms; and unstructured, aka content and documents more free-form in nature. Business users don’t, by the way, ever interact directly with data of any kind. They interact with applications that interact with data repositories, ingesting it, managing it, and representing it.

The data layer encompasses just the data themselves, not the DBMSes, content management systems (CMS), and document management systems (DMS) that contain them.

Technology: This consists of two sublayers:

• Infrastructure and facilities, which encompass: the data center itself (even if you’ve gone full cloud there’s a data center lurking around somewhere); networks; servers, whether physical or virtual; storage, whether SAN, NAS, or direct-attached; plus systems monitoring, management, and administration tools — stuff like that.
• Platforms: The software on which everything in the higher layers is built and run, including server operating systems, development languages and environments, DBMSes, CMSes, and DMSes, and enterprise service buses (ESBs) and equivalent integration systems.

Standards

As a result of evaluating the information technology deployed in the application, data, and technology portfolios, IT establishes standards — guidelines the portfolios must conform to. Standards fall into two categories:

• Product standards: The specific products approved for use for delivering each IT capability. MS Word, for example, is the word processing standard for most businesses today. Applications, data repositories, and technologies that are in use but aren’t approved for use violate an architectural product standard.
• Engineering standards: In addition to specific products, the technical architecture also consists of approved ways to structure its various components. As an example, most IT shops consider normalization to be their standard way of organizing structured data; many are in the process of establishing microservices as their standard way of organizing application logic.

Moving from primer to practicality

So far we’ve covered how to classify the bits and pieces of information technology you have into portfolios. That’s everything except what matters. The next articles in this series will cover using the results to evaluate the architecture you have and plan how to morph from it to the architecture you need.