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.\nWhich leads to the question, What constitutes good technical architecture? Or more foundationally, What constitutes technical architecture, whether good, bad, or indifferent?\n[ Learn the 10 old-school IT principles that still rule and the 12 'best practices' IT should avoid at all costs. | Get the latest insights by signing up for our CIO newsletter. ]\nIn case you\u2019re a purist, we\u2019re talking about technical architecture, not enterprise architecture. The latter includes the business architecture as well as the technical architecture. Not that it\u2019s possible to evaluate the technical architecture without understanding how well it supports the business architecture. It\u2019s just that managing the health of the business architecture is Someone Else\u2019s Problem.\nWhy technical architecture matters\nIT always has a technical architecture. In some organizations it\u2019s deliberate, the result of processes and practices that matter most to CIOs.\nBut far too often, technical architecture is accidental \u2014 a pile of stuff that\u2019s accumulated over time without any overall plan.\n IT Catalysts\n\nFigure 1\n\n\nAs 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 \u2014 reduced maintenance and support costs, easier and less-fragile integration, and overall improved flexibility in addressing new business challenges \u2014 dwarf the initial investment.\nWhat constitutes technical architecture\nBefore we get started, no, what you\u2019re about to see isn\u2019t the well-known TOGAF architecture framework. It isn\u2019t inconsistent, but I\u2019ve 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.\n IT Catalysts\n\nFigure 2\n\n\nFigure 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:\nExternal factors\nThese include business drivers, architecture principles, and technology trends:\n\nBusiness drivers: These are the broad IT capabilities the company will need, as inferred from its strategic goals. These aren\u2019t requirements in the app dev sense. They\u2019re 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.\nArchitecture principles: As explained in the last installment of this series, these are broad principles that define what constitutes \u201cgood\u201d architecture in your business. They combine an overall knowledge of what constitutes good engineering with the company\u2019s business drivers.\nTechnology trends: No, you don\u2019t 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.\n\nTechnical architecture\u2019s building blocks\nIT architecture is layered and segmented. It\u2019s comprised of applications, data, and technology. Drilling down, it consists of:\nApplications: The portfolio of software programs business users make use of to do their jobs. The application layer is divided into three sublayers:\n\nSystems of record: The applications and application suites that serve as the authoritative source of information and business logic.\nIntegration and synchronization: The inter-application interfaces that make sure applications whose data and business logic overlap agree with each other.\nSatellite 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\u2019s 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.\n\nData: 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\u2019t, 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.\nThe data layer encompasses just the data themselves, not the DBMSes, content management systems (CMS), and document management systems (DMS) that contain them.\nTechnology: This consists of two sublayers:\n\nInfrastructure and facilities, which encompass: the data center itself (even if you\u2019ve gone full cloud there\u2019s 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 \u2014 stuff like that.\nPlatforms: 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.\n\nStandards\nAs a result of evaluating the information technology deployed in the application, data, and technology portfolios, IT establishes standards \u2014 guidelines the portfolios must conform to. Standards fall into two categories:\n\nProduct 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\u2019t approved for use violate an architectural product standard.\nEngineering 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.\n\nMoving from primer to practicality\nSo far we\u2019ve covered how to classify the bits and pieces of information technology you have into portfolios. That\u2019s 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.