Infrastructure Architecture

 

Daniel Jumelet

March 2007

Summary: An introduction to a new branch of architecture that is urgently needed to support modern organizations, and needed to help architecture to mature as a whole. (4 printed pages)

Contents

Why Infrastructure Architecture Matters
The Importance of "Trust" in an Automated World
A Solid Infrastructure: Essential to Business Continuity and Agility
Why Infrastructure Architecture Is Decisive
First Steps

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

One night, I turned off my PC, brushed my teeth, and went to bed for a well-deserved night of sleep. It had been a busy day and, after my daily work, I had to arrange a number of things for a short vacation trip to Paris the following week. I went online to check my credit-card balance, decided to transfer money from my savings account to my checking account (by using my e-banking facility), and visited my travel agency's Web site to extend my hotel booking by one day (luckily enough, I had received an e-mail just in time that stated that an important meeting had been cancelled, which gave me a bonus day to visit the Montmartre area and its cemetery). And, if that was not enough, my digital agenda suddenly started to beep, which indicated that the deadline to send in my tax form was approaching.

It was not too hard to fill in the electronic tax-form application, but when I tried to send it, it appeared that my Governmental Digital ID needed reactivation. SMS sent a secret code, which I entered to complete my digital signature. Another duty fulfilled! The only thing left to do was to go to the corporate Web site of a company that I was due to visit the next day. I inserted the address data into my in-car navigation device, so that the next morning, all I had to do was put it into the cradle and hit the road.

Okay, time to sleep. But as soon as my head touched the pillow, a disturbing thought hit my mind: How could I be sure that all of the arrangements that I made would be carried out without error? I remembered the time that I had ordered flowers for my aunt, whose birthday I had almost forgotten. I was saved by an online flower service. To her and my surprise, she got those flowers twice—in all probability, because my first payment attempt had failed, due to an obscure "server connection time-out" that was reported by the Web-based order application. To make sure that a nice bouquet would reach her, I had re-entered the order; however, my credit card never was charged for more than one transaction.

Maybe this had been a software error, but as a Senior Infrastructure Consultant I already had come to the conclusion that many companies struggle with both their infrastructure landscapes and the management of the numerous assets that populate them. Instead of falling asleep, I realized how important a sound and reliable IT infrastructure is regarding "trust." What if infrastructure landscapes would grow too complex too handle, so that it would be hard to guarantee stability and availability? What if a major bank's infrastructure was disrupted for about a week? How would that affect the economy? And what would that do to the perception of the consumers, who base their daily activities on the ability to retrieve their money any time that they wanted? Wouldn't they start to save "real" money again, with a safe for every household? Automation brings a lot of convenience into our daily lives, but if important automated systems should prove to be unreliable or unpredictable, it could disrupt the economic ecosystem that is built around those systems.

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.

 

About the author

Daniel Jumelet is a senior infrastructure consultant and architect, with a specialization in networking technology and information security. At present, Daniel is developing an infrastructure-architecture methodology for Sogeti, which is called DYA® I Infrastructure Architecture. He is authoring a book on this subject that is due to appear in Q2/3-2007. Apart from his fascination with all matters technical, Daniel is interested in philosophical matters and human-science subjects, especially those that concern the interfaces between people, society, and technology. E-mail: daniel.jumelet@sogeti.nl

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.