The Infrastructure Landscape: A Matter of Perspective

Daniël Jumelet

December 2007

Summary: This article offers a quick exploration of an infrastructure-architecture model that really works. (8 printed pages)

Contents

Introduction
Structure Through Perspective: The Building-Blocks Model
Structure
Functions and Relationships
An Architectural Embargo on Relations and Hierarchies
Lessons Learned and Takeaways
Critical-Thinking Questions
Further Study
Glossary

 

Introduction

I have been working on the infrastructure side of the IT industry for many years now. As the years have gone by, one particular notion has become clearer and clearer to me: We infrastructure specialists, and our employers and clients, are gradually losing control over the infrastructure landscapes that we manage.

Twelve years ago, I started my career as the only system administrator of a midsize retail organization. In my early days, the average infrastructure landscape was quite simple: Most midsize organizations possessed a few file and database servers, a simple network, and a number of personal computers (PCs). Most small organizations did not even own servers or a network, and relied on stand-alone PCs. Big organizations distinguished themselves from midsize organizations by their use of mainframes. The job of a system administrator could be complicated, but not because of the complexity of the techniques that were used in the network. Instead, it was the paucity of information about driver updates or error codes, or the user-unfriendliness of device interfaces, that made things sometimes challenging. Although these little annoyances sometimes spoiled my day, the job was quite straightforward for someone with technical affinity.

Life was good! My little server farm was nice and stable (thanks to a scheduled weekly reboot at 6:00 A.M. to sort out an annoying memory leak in one of our applications). I was the darling of the secretarial pool, and famed for the devilish ease with which I produced Microsoft Office Word macros to make their lives easier! Then, one day, someone knocked on my door and asked me to conjure up a Web server to host the corporate Web site. The Internet hype had struck!

This was just the beginning, because once you have a Web server, you also need a firewall; an extended, more reliable network; and a bigger, faster Internet connection—not to mention a content engine and Web site authoring tools.

The organization developed a dangerous addiction to IT "luxuries" like Internet e-mail and Web proxy services, data-warehouse services, and enterprise resource planning (ERP) services. The infrastructure landscape of the organization expanded faster than I could have dreamed. Every new automated application introduced new infrastructure equipment. Because all applications were implemented by specialized parties, and because each party brought its own box of tricks with it, standardization became only a distant dream. Occasionally, I tried to interest my IT Manager in a technical design or some piece of documentation, but he claimed that he was not really a man for these sorts of details. He only listened to guys who wore expensive ties, anyway. During those days, I was still the single system administrator of this organization, and the vastly growing infrastructure began to overwhelm me.

I decided to run. I bought a suit and a wide selection of fashionable ties (as I learned this to be a critical success factor), and went to work as a network technology instructor for an IT service provider. Through my work as a teacher, I acquired sound knowledge of networking technology. But, then, I started to grow into a consultancy role. Once again, I was faced with complex infrastructure landscapes, although (lucky for me!) the responsibility of maintaining these environments was no longer mine. However, this time, I decided not to run, but instead to accept the challenge of the problems of complex infrastructure landscapes. I decided that it was time to aid the development of infrastructure architecture—in my opinion, a badly neglected field of study.

Structure Through Perspective: The Building-Blocks Model

In my quest for an architectural view of infrastructure, I started out from an area with which I was very familiar: network technology. This is an area that has already seen a fair amount of standardization and rationalization. Some of the manufacturers provided a modular model that distinguished several types of functions within network building blocks. As a consultant, I already used this type of model to help several companies develop a sound networking infrastructure. I tried to apply this approach on a higher, more abstract level. As I found out, it was very helpful to describe infrastructural assets in a functional way, and to discuss nonfunctional aspects (quality attributes) in a way that was meaningful to the business processes that these infrastructure services were supporting. I started to formulate a building-blocks model to describe infrastructure landscapes. I was on the right track, but something was missing...

The Birth of the Building-Blocks Model

Then, I met Jack. Jack was a senior infrastructure architect for a large insurance company in Holland. When I met him, his company had just decided that it needed a specialized infrastructure-architecture unit. Many of its members, however, were not sure how to approach the task of creating a formal infrastructure methodology for enterprise architecture. I discussed my thoughts about infrastructure architecture with Jack by using a first draft of the building-blocks model to illustrate my ideas. To my great surprise and delight, he responded extremely positively. He, too, had been looking for a useful infrastructure-architecture methodology for quite some time. He invited me to work together, and persuaded other senior infrastructure architects whom he knew from other companies to join us. The infrastructure landscape of his insurance company provided the perfect case study to develop the building-blocks model further. During our first meeting, Jack shared an interesting idea with us:

"To achieve a meaningful overview, a proper perspective is crucial," he said. "Imagine a city, and think about what is necessary to produce a quick survey that describes the 'look and feel' of that city.

"At street level, you can examine the details of buildings in front of you, but these buildings stand in front of other buildings—stopping you from seeing them. It also is not possible to detect the interrelations between these buildings and their function. For example, the main post office might be located right behind the central train station, for sound business reasons; but I can't possibly see it if I just stand in front of the central train station. Of course, it is possible to travel from building to building within a city and exhaustively describe every single building and its interrelationships with surrounding buildings. This will provide an overwhelming amount of accurate data that defeats the objective of providing an overview of the situation.

"On the other hand, I could choose to use Google Maps and zoom into the city. Google Maps provides me with a quick superficial overview of the interrelations of the buildings within this city. All the rooftops are displayed, and the structure of the streets is provided; but we learn nothing about the function of these buildings or their characteristics."

"However, if I were a bird, I could survey a city quickly from several perspectives. I could use the high (Google Maps) perspective to decide how to divide up the city into sections. I could zoom in on a certain section, and then discover the distinctive buildings that provide a certain service within that section and the way in which those buildings relate to each other. I could even zoom-in on particular buildings to examine the way in which they are constructed (the street-level perspective).

"Let's try to find the proper dimensions that offer the right levels of perspective to allow us to formulate an abstract description of an infrastructure landscape—understandable for both business and information architects—that at the same time offers enough depth to make sense to the technicians who design and build the infrastructure."

It took us some time to find the right dimensions. Each architect contributed a unique viewpoint to the result. While no single viewpoint provided a complete description, we ended up with a collection of many viewpoints and perspectives, working at several levels—making it possible to provide efficiently and quickly a concise and meaningful overview of the infrastructure landscape.

We gave our finished product the name "building-blocks model." Although a primary feature of our model is the development of flexible, modular units of infrastructure functionality, it has several other important dimensions. Specifically, the building-blocks model serves two additional purposes: It provides a bridging function between architects and technical specialists, and it promotes reuse of architecture products.

The building-blocks model is particularly useful during the structured and modular development and definition of an infrastructure landscape. Functionality, quality attributes, and technology are clearly identified, without creating overly stringent dividing lines. This produces architecture documents that are structured, readable, and discussable. It provides a consistent translation between architectural functionality and specialized technology. Infrastructure services are identified clearly and transparently, which creates a scope for the consolidation of overlapping technologies. It helps to avoid the development of documents that intermingle organizational, business, functional, and technical descriptions.

The model yields reusable architecture products, because it promotes modular infrastructure development. Consistent application of the model creates a library of standard infrastructure services (building blocks), which in each successive engineering process and related implementation can serve as a reference and starting point. Building blocks can serve as a point of departure for situations that have new or very specific requirements. The use of building blocks and standard modules promotes the expandability and adaptability in an infrastructure landscape and, consequently, promotes flexibility.

Structure

The building-blocks model is structured in a primarily functional way. Building-block types are defined for each type of infrastructure service. Within each organization, several variants of a building-block type will typically occur, depending on the environment. The building-blocks model recognizes the following service groupings:

· Working area—A set of infrastructure services that, at a general, logical level, provide a certain kind of infrastructure functionality, such as middleware, storage, network, and client.

· Environment—In this context, a functionally demarcated domain (business context) in an organization's infrastructure landscape, such as "hospital workstations." Environments differ from each other primarily in the types of functionality that they offer. A further subdivision can be made according to location types, if infrastructure services at each location are different enough to justify a further breakdown.

· Building block—An infrastructure service or set of closely related infrastructure services that, in the context of an environment, provides uniform and delineated infrastructure functionality, such as "backup storage." Several variants of a certain type of building block might occur within an organization, depending on the diversity of environments and locations. (For example, file and print services at a small location might be implemented differently from a large location.)

· Element—Elements are technical components, functions, and/or protocols that are used to construct building blocks, such as TCP/IP or Linux.

· Quality attribute—Quality attributes, such as "response time," describe constraints on how a building block functions, and they are regarded as nonfunctional requirements. Quality attributes influence the elements that are used to construct a building block, and they can be applied to environments on a global level.

Functions and Relationships

Each of the preceding dimensions and components of the building-blocks model has its own purpose, and it is related to other dimensions or components in a certain way. To explain the working of the building-blocks model, I explain the functions and relationships of the different dimensions and components in the following sections.

Working Area

At the highest level, the building-blocks model allows a subdivision into working areas. Each working area has its own particular nature or type of infrastructure services. The working areas are aligned with the different areas of expertise that might typically be identified within the infrastructure field. The working areas that are defined within the building-blocks model are:

· Servers. Servers embrace a wide working area that is focused on (logically) centralized delivery of processing and computing capability. Servers are usually associated with countless services in the form of generic, centralized applications and management tools that usually form part of an operating system or are closely associated with it. Examples are directory services, mail services, management services, and monitoring services.

· Middleware. A working area that is focused on applications that fulfill generic functions that support business applications and, as such, do not have a purpose of their own. They include messaging services and database-management systems.

· Storage. A working area that provides numerous types of permanent and semi-permanent data-storage capabilities.

· Network. A working area for the transmission of data, controlled and conditioned (or otherwise), between systems.

· Client realm. An infrastructure working area that provides various user interfaces. These include (mobile) workstations and printers.

Environment

Within an organization's infrastructure landscape, it is possible to identify different environments inside each working area. They form a functionally demarcated domain or business context. Environments offer their own distinct type of functionality, so that they differ from each other through the different infrastructure services that operate in them and the different requirements that the services must satisfy (both functionally and in terms of quality attributes). An example is a hospital that has office workstations, medical workstations, and visitor workstations within its client-realm working area. Another example is an organization that has defined an office LAN, a server LAN, a demilitarized zone, and a WAN environment within its network working area. Within environments, a further distinction can be made according to location types (such as a Head Office LAN and a Service Point Office LAN) if the infrastructure services differ so much as to justify a further subdivision. The different variants of building blocks will then be defined from location to location.

The purpose of defining environments is to create distinctions between building-block variants. To achieve the fullest possible standardization, it is important to keep the number of environments as small as possible. A separate environment should be defined only when required. On a global level, quality attributes can be assigned to environments, thus clarifying the nonfunctional requirements that are relevant to each one. When defining building-block variants within an environment, quality attributes can be worked out more granularly.

Building Block

A building block provides an infrastructure service or a set of closely related services. The definition of a building block consists primarily of a functional description, which includes its purpose, offered service, and method of use. The functional definition of a building block must be discussed and agreed upon with the other architecture disciplines (or, possibly, representatives of the company's management, if an organization's architecture process is still in its infancy). The quality attributes that an infrastructure service must satisfy will figure in this discussion. For each type of environment, it must be determined which building-block types are relevant and which variants of each type occur. Some examples of building-block types in the storage working area include centralized storage, distributed storage, back-up and restore, and archiving.

Organizations are obviously free to choose their own categorization and define their own building blocks—appropriate to their own IT landscape. For the primary description of the building blocks, a functional approach should be adopted as far as possible to avoid a technical and product orientation in the primary description. Building blocks are defined with specific scopes. Those that are defined for a reference architecture (in which an organization's infrastructure landscape will be described and defined and, thus, standardized) are reusable across an organization, while those that are defined informally will be relevant only for specific projects.

Element

A building block is composed of one or more technical components that are referred to as elements. Building-block descriptions include an overview of the elements that make up those building blocks. Elements specify the hardware and software, protocols, and standards that are used. Building-block variants can consist (partly) of different elements, depending on the requirements that an environment imposes on an infrastructure service.

The composition of building-block variants will be determined in cooperation with infrastructure specialists who are brought in at an early stage of the architecture and engineering process to make the architecture documentation sufficiently concrete and contain clear specifications. Not only is this important in terms of the architecture process, but it also helps procurement departments in their decision-making processes. Because specialists would already be involved in the architecture phase, later engineering phases will inevitably take place much more quickly.

Quality Attribute

Quality attributes determine the "appearance" of environments on a global level and on a more granular level than building blocks. The most relevant quality attributes will be determined in the architecture process, as will the weightings that will be assigned to them. In the engineering and building processes, the quality attributes will be specified and quantified in greater detail. Quality attributes influence the definition of building-block types and variants, and they are also a guiding principle for selecting the correct elements.

An Architectural Embargo on Relations and Hierarchies

An important lesson that is learned is to abandon predefined relations or hierarchies between infrastructure services and building blocks. Why? Because the design places things into context.

In my career as a consultant/architect, I have seen many representations of the infrastructure landscape that tried to fix relationships or hierarchies at the architectural level. Typical infrastructure overviews of this genre contained services that were depicted in an infrastructure "map" that was divided into categories such as "basic networking services," "advanced networking services," "added value networking services," "communication services," "messaging services," and so on. Common to this approach were the lengthy discussions between architects about where to put which service into what category. "Is DNS a basic networking service, an advanced networking service, or a value-added networking service—or, perhaps, a client-support service?"

If you really want to define all relations between all infrastructure services, you end up with an unmanageable number of associations, because the formula to calculate the maximum number of relations in a case such as this is n(n-1)/2, where n stands for the number of services. Relationships start to be meaningful within actual contexts, and it is the job of a designer to select and use predefined building blocks to create solutions for actual problems. For instance, road designers can make use of predefined streetlights and road signs to create a road plan for a specific situation. Precisely because the designers have the freedom to select these items as needed, and not because there is a predefined relationship or hierarchy between the road and these items, they can perform their job without compromising standardization.

Lessons Learned and Takeaways

We started to use the building-blocks model to create an infrastructure reference architecture for Jack's insurance company. The Model was extremely successful, although it cost many technically oriented designers and engineers a lot of effort to get themselves to think on a more abstract level. The model aided them greatly; but senior architects had to guide them in thinking about the functionality that was provided by these services, instead of how services worked and how they were constructed. However, after a few months of hard work, a substantial part of the infrastructure landscape was described in a way that was meaningful to business and information architects, project leaders, business representatives, engineers, designers, and key users. Furthermore, we discovered that there were many more areas in which the building-blocks model provided additional value.

Service-Level Management and Managed Services

The use of building blocks with clearly described quality attributes and elements simplifies the preparation and maintenance of service-level agreements (SLAs) and/or operation-level agreements (OLAs). As infrastructure services are defined as services (in the building-blocks definition), no extra translation is needed for the use of service-level management. It is possible to draw up SLAs/OLAs in concrete terms as early as the engineering phase, and to adopt them as the guiding principle when developing new infrastructure services. System administrators are involved in projects at an early stage, and the complexity of management is reduced, thanks to standardization.

Life-Cycle Management

The building-blocks model promotes standardization and a modular structure of infrastructure services. This helps life-cycle management to succeed. By offering a greater overview of the infrastructure landscape and more insight into the functionality that infrastructure services offer, the phasing out and replacement of infrastructure solutions (the most difficult step within LCM) will take place more responsibly and with greater predictability.

Procurement

Use of the building-blocks model ensures that specialists will be involved as early as possible in the architecture phase and that technical components (elements) will be laid down unambiguously. This gives procurement departments an opportunity to request sufficiently detailed offers in the market—thus, avoiding the choice of unsuitable or poorly suited facilities.

Information Security

As the building-blocks model places an emphasis on a functional description of infrastructure services, it enables better alignment to a company's information security policy.

It is close to impossible to draw up security measures for the technical components themselves, because they provide no clarity about the role and function that they perform within the context of the infrastructure landscape. However, security measures can very well be linked to infrastructure services in the context of a concrete infrastructure landscape. The building-blocks model specifies the services and the context in which they function (in the form of building-block variants and the environment in which they will be implemented), and provides a manner—using quality attributes—to associate security aspects to these facilities during the architecture phase.

There are, thus, different situations in which use of the building-blocks model (and, in a more general sense, architecture) will demonstrably be worthwhile. It provides overview and structure, and ensures that infrastructure services are properly aligned with an organization's processes and needs. It creates a renewed grip on innovation in the infrastructure and curbs increasing complexity. The infrastructure will function as it is intended to function—namely, as a solid basis on which an organization and its IT services can build upon, without any obstructions, because it is both flexible and reliable.

Critical-Thinking Questions

To organize, consolidate, and standardize the infrastructure landscape is one thing. However, the challenges do not stop there:

· Most information/application architects will not be in favor of a standardized, consolidated infrastructure. All they want is flexibility and the least of their concerns is manageability of infrastructure environments. How does the building-blocks model help you to deal with this?

· You finally made it: a standardized, consolidated, and rationalized infrastructure landscape that is very easy to secure and to manage. Then, people who have high influence within the organization start to batter the CIO. They demand more freedom in using infrastructural assets (for example, regarding their own desktops). The CIO succumbs, and promises a more flexible approach. How do you respond, and how does the building-blocks model help you?

Further Study

A white paper on the DYA | infrastructure-architecture method and its building-blocks model (on which this article is based) is published in Dutch, in the e-magazine Via Nova Architectura:

· [Jumelet, 2006] "Whitepaper DYA | Technische Architectuur." Via Nova Architectura [e-magazine], November 14, 2006. [Cited January 10, 2007.]

An English-language copy of this white paper can be obtained via an e-mail to its author (Daniel Jumelet).

More information on the DYA Dynamic Architecture initiative can be found at the official DYA Web site:

· [Sogeti, 2007] Official DYA info-site

Glossary

Infrastructure landscape—A collection of infrastructure assets that provides the infrastructure services of an organization

About the author

Daniël Jumelet is a senior infrastructure consultant and architect, with a specialization in networking technology and information security. At present, Daniël develops 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 Q2/3-2007. Apart from his technical fascination, Daniël is very much interested in philosophical matters and human-science subjects, especially concerning the interfaces between people, society, and technology. You can reach Daniël via e-mail at 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.