Infrastructure Architecture

Why Infrastructure Architecture Matters

Infrastructure architecture is a new kid on the architecture block. Traditionally, a large amount of IT-architecture attention has been devoted to information and application architecture. However, several developments have fostered a growing desire for infrastructure architecture. But not only will an organization's infrastructure provisions benefit from the appliance of this new architectural discipline; IT architecture, as a whole, will mature. Being that infrastructure architecture is in its childhood, a lot of work has to be done to stimulate and create infrastructure-architecture methods, models, and tools. This paper includes a number of first steps in this new architecture discipline.

The Importance of "Trust" in an Automated World

For ages, "trust" has been the basis of our economic system. In our economic transactions, we rely on "trust"—confident, as we are, that things are carried out properly. Our confidence is based on our experience with—and the reputation of—the companies, governments, and individuals with whom we interact. Many of the services that we use are virtualized. For example, the amount of money in a bank account is no more than a record in the bank's database system. Contracts, bills, and receipts are produced to underpin our activities; however, in an increasingly automated world, even these documents tend to be virtualized. How many companies urge their clients to accept e-bills, e-contracts and e-accounts these days, instead of paper copies? Many! As long as they can be accessed by these clients, there remains some sort of cogent evidence that the system is still running. I started to wonder if these companies understood the important role of their infrastructures, because:

• Business drives everything.
• Information and communications technology (ICT) enable business.
• There is no ICT without infrastructure.

  And, therefore:

• There is no business without infrastructure.

A Solid Infrastructure: Essential to Business Continuity and Agility

Of course, it is not infrastructure services alone that support automation. Software applications contain most of the (complex) logic that drives automation. Therefore, it is not a surprise that a quick survey of the IT-architecture field shows that information and application architecture receive the greatest amount of attention.

Most methodologies and frameworks focus on application architecture. When a methodology or framework does pay some attention to infrastructure, it is remarkable that the level of abstraction is significantly lower when dealing with infrastructure services. This can be understood from a historical point of view. In most cases, infrastructure services have been "simple" during the first decades of IT development. While applications advanced in functionality and complexity, hardware only got "faster." However, the turning point came during the Internet hype. Infrastructure vendors innovated like never before.

Infrastructure started to become "smart," together with a massive growth of connectivity solutions. This coincided with the rapid development and deployment of new application types (such as e-marketing, e-commerce, ERP, and data warehousing), which demanded new infrastructure services.

Within the infrastructure field of work, a silent revolution took place. Many new and complex types of infrastructure services have been added to the field, while existing services gained a lot of functionality. Traditionally separated domains (such as telephony and video) are being integrated within the infrastructure domain, while generalized, standardized applications (such as mail, calendar services, and collaboration applications) are being added to this infrastructure domain. This results in complex infrastructure landscapes that are hard to manage and expand. Most current infrastructure landscapes are the result of a history of application-implementation projects that brought their own specific piece of hardware into being. Mergers and acquisitions make things even worse—leaving many companies with different sets of the same services that are hard to connect to each other, let alone integrate and consolidate.

Why Infrastructure Architecture Is Decisive

When organizations (out of necessity) pay attention to business-continuity management or want to save on costly administrative staff, they should invest in infrastructure architecture to rationalize, standardize, and structure their infrastructure landscapes. Organizations also benefit from infrastructure architecture when they want to be flexible and agile, because a solid and naturally scalable, modular infrastructure provides a firm foundation for quick adaptations at higher levels. The coming market, which is full of digital natives (forming "markets of one"), asks for a degree of flexibility that can no longer be supported by infrastructures that are inconsistent and hard to expand. These markets need infrastructures that are constructed with standardized, modular components.

Of course, proper project management, skilled design, construction, and operation are essential to implement and maintain reliable infrastructure services. But to make infrastructures consistent and fitting with business needs, architecture is indispensable.

However, not only infrastructure landscapes benefit from proper infrastructure architecture. To be able to translate business, information, and application architectures into solutions that really work in a real world, the supporting infrastructure services should be in line. The result would make architecture stronger as a whole and enable architecture to deliver solutions that are consistent from beginning to end. To enhance the effectiveness of architecture, we must pay attention to infrastructure architecture to complete the whole picture.

A nice incentive is that it directly pays off to invest in infrastructure architecture. Blessings that are delivered by a mature use of it include:

• Greater insight into and overview of existing complex infrastructure services by preparing a transparent and structured taxonomy.
• Development of a structured, standardized, and consolidated set of infrastructure services that optimally support business processes and applications. This prevents overlapping and diversity of services, and thus reduces the complexity of managed services and life-cycle management. Standardization produces greater flexibility bottom-up, because it makes it easier to carry out expansions, changes, and replacements.
• A balanced examination of the possibilities that are offered by new technologies and a concrete path towards solutions to the challenges that occur in business operations. Specialized expertise is used to dispel hype, but without missing opportunities. Architecture thus strengthens the demand side in an area that is frequently dominated by the supply side (that is, manufacturers and suppliers).
• Transparent and complete input—both technical and functional—for engineering, building, and testing activities. Architecture avoids a one-sided, technical approach to projects for building infrastructure services, and it also safeguards the alignment of delivered products with the predefined requirements for functionality and quality.
• Improved alignment with operational services, because architecture enables engineering that is driven by service-level agreements (SLAs)/operating-level agreements (OLAs). Service-level management and operational services play a role at an early stage of creating new infrastructure services. This results in better and more effectively supported SLAs and OLAs. In combination with standardization and consolidation, this reduces the complexity of service-level management and operational services, too, because there is less diversity in the SLAs and OLAs.

First Steps

Infrastructure architecture is a young and immature discipline. Available literature is scarce, and it is very hard to find schools and universities that include some of it in their curricula. Much of what is called "infrastructure architecture" can actually be considered as "design." However, this is quite natural for a discipline that needs to develop more abstract methodologies and models.

Structuring and rationalizing design is a first step. Architecture methodologies should be developed by elaborating design practices, because this is the only way in which they stay in touch with reality. The border between architecture and design should remain diffuse, because as soon as the distinction between the two proves itself in some way to be clear, it will create a painful gap. Architecture misses its goal when architects are not able to transform their abstract constructs and artifacts into real solutions, because designers, specialists, and engineers cannot understand the directions that the architects provide. If this happens, engineers tend to start building their own solutions that are related in some way to the interpretation that they have regarding the architect's high-level descriptions.