Above the line and below the line

Across my career, I have helped in several IT consolidations. IT consolidations can be tricky to communicate. I find the biggest hurdle is explaining how an IT consolidation can help both parties. In most IT consolidation situations, you start with two groups that are managing up and down the "stack" of technology. A key goal is to leverage size and scale so each group takes on the role that is best suited to them, so you simplify the work and let people focus on their value to the organization.

For example, you might have a development team that creates web-based applications for the overall organization. To run their web-based applications, they need a web server, so they install and manage a traditional "LAMP" stack: their own Linux server with Apache, MySQL, and PHP. Except that in most instances, "manage" is an overstatement. The group needs to focus on maintaining the web-based applications they write, and the system administration of the Linux box, MySQL server and Apache instances tend to fall behind. Meanwhile, in another part of the organization, you have an IT infrastructure group that's dedicated to running and maintaining Linux servers, and MySQL databases, and Apache instances.

In examples such as these, IT consolidation makes a lot of sense. If you could peel off the "infrastructure" work from the development team, and move those to the IT infrastructure group, you gain efficiency. The development team can focus on writing new applications, and the infrastructure team can take on the system administration.

Unfortunately, not everyone sees IT consolidation in such plain terms. When you talk about moving part of someone's job into another group, emotions get involved and consolidation becomes more of a challenge than it is meant to be.

To help get around these issues, and communicate more clearly about the benefits of IT consolidation, I've developed a model that helps both sides understand how IT consolidation will work out to everyone's benefit. I call it "Above/Below The Line."

Like most of my examples, I prefer to communicate it visually. Applications come in different forms, so let's envision different examples of an application stack:

• Local development: You might have the above example, where an in-house development team writes an application. This usually runs in some kind of framework, such as a web server or other container. Underneath that, you need an operating system, which runs on a physical or virtual server, with storage and network.
• Business application: Many applications are instead delivered by a vendor that you just need to run somewhere. A classic example would be a client-server application, but you might have a vendor-delivered application running in a framework, similar to local development. Again, you also need an operating system, which runs on a server, with network and storage behind it.
• Databases: Whether the application is locally-developed or vendor-delivered, many will require a database system to store structured data. In terms of the "stack," the data schema is served by a database engine, which runs on an operating system on a server. Network and storage support the overall system.

You should see some similarities here. Each system shares several components or "layers" in an overall "stack." You can draw these components in a simple diagram, such as this:

Before IT consolidation, the development team might manage the entire "stack" in order to support their application. But post-consolidation, you need to separate what is "application" from what is "infrastructure" by defining roles. Having described the "stack," the next step is to define the separation of roles. Let me use color here: green to represent the application team and blue for the infrastructure team:

I've added an obvious line to indicate where most organizations choose to separate roles. After IT consolidation, the application team operates "above" the line, managing the local application development, configuring containers, managing business rules for vendor-delivered applications, managing data and database software. In this model, the infrastructure team operates "below" the line, supporting the operating system, servers, storage, and network.

This is a great model, but it's also a simple model. In any realistic environment, I find you need to make certain exceptions. You'll always need some cooperation between the two teams. The purple line becomes more difficult to draw, because it's position will differ based on your environment. An obvious example is installing software; in most organizations, the infrastructure team may need to be involved to install applications. Although usually the application team can take things after that:

And the opposite is sometimes true: the application team may need to do some things at the operating system level. For example, in a Linux system, the application team often is allowed to configure the web server software, and stop and start it using operating system rules (such as sudo). The line becomes less clear, but it is still visible:

I created the "Above/Below The Line" model before Cloud was a thing. But Cloud applications are easy to fit into the diagram. Cloud applications are hosted externally, similar to vendor-hosted applications. So Cloud applications rely on the organization's network, but otherwise live completely "above" the line. An integration team (which might be the same as the application team) manages business rules in the Cloud application:

When I've shaped an IT consolidation discussion using this framework, I find we experience fewer miscommunications and less stress. The "Above/Below The Line" model helps both sides understand the roles involved after IT consolidation. The key takeaway is the infrastructure team does the "heavy lifting" of managing operating systems, servers, storage and networks so the application team can focus on what they do best: building and supporting applications that drive the business.