Print
Close

The IT Cake Boss

August 20, 2012

It’s a universal problem for IT project managers everywhere. When you’re managing a system implementation you are responsible for the total solution--that means application and infrastructure.

The problem is that these two camps haven’t always gotten along in perfect harmony. They each have their own interpretation of where their high-tech areas end and where the other party’s high-touch zone begins. They each speak in a slightly different language, and they can each be counted on to defend their own turf at nearly any cost.

I faced this same challenge numerous times several years ago. However, I backed into a useful and valuable framework that allowed me to communicate and collaborate with infrastructure and applications while allowing all team members to get the job done rather than lose precious time talking past each other or pointing fingers at one another. At the end of the day, all anyone cares about are results. If you ever find yourself in one of these grey area skirmishes, it might just be time to give the “cake approach” a try.

Baking the Cake
My project team and I were sitting around a conference room dealing with a particularly challenging situation. We were an IT hosting vendor and we were having trouble with an offshore application development team wanting progressively more and more access to areas of the server that they felt they were entitled to--but we didn’t agree.

The first turf war was around the database. We tried negotiating, but each side clearly had a different perception of what “hosting” meant and, as a result, approached the situation with different expectations. We tried to communicate with pictures, but architecture diagrams can sometimes complicate things more than they clear them up. To make matters worse, we each had a signed contract--just not with each other.

We each had agreements with our mutual Client “A” (in legalese, the Third Party). We signed one for hosting and they had one for software development. We each had also independently signed up for service levels that didn’t synch up with each other (e.g., didn’t accommodate offshore business hours). Client “A” further absolved themselves of this dilemma by insisting that both of us settle our differences directly with each other--just leave Client “A” out of it.

As we thought about it more, the reason this arrangement was so complex was because of all the different types of technologies that were involved. The technologies were not only complex, but interdependencies and sequencing between the technologies made the picture worse. “Change something in this configuration and it will ripple through to all of those other areas,” one team member observed.

That’s when the image of a layer cake hit me. Each layer of the technology stack was foundational and built on the layer previous to it. While it shares an approach with the famed network transport model (OSI), it actually has a broader scope. Just like the individual layers of a cake are carefully baked and set on top of each other, so were our technology stacks (minus the frosting). You can’t set the third layer on the cake stack if the first layer was still baking!

So we set out to define the layers of our technology stack--once that was done, the rest of our project was a piece of cake (relatively speaking)…

The Cake (Tech Stack) Model
When building any technology platform (or stack) from scratch, you usually start with one or more physical (or virtual) servers. From there it is simply a progressive elaboration of adding layers until you get the complete stack configuration that you want. Granted, some of the layers can be combined and some layers assembled in parallel. However, thinking through the logical progression of the layers helps to compartmentalize the work and technology zones, and clearly defines the handoffs between logical layers and players. The layers are:

• Layer 1: Physical Hardware--This is made up of the physical elements that will perform data processing, application logic and data storage/retrieval. This includes servers, backup tape hardware, uninterruptible power source (UPS), SAN, connecting cables, cards and all other physical aspects. It’s the things you can touch and have to order. This layer also includes the operating system: installation, configuration, and maintenance of the OS on all hosting platforms as well as all the virus protection of individual components. This serves as the foundation on which you will build everything else.
• Layer 2: Network--Once you have a physical box, you need to communicate with it.This level is all connectivity and communications: switching and routing services, creating logical paths (for mounting resources), virtual circuits for transmitting data from node to node, FTP permissions capabilities, etc. In other words, once you have your physical foundation built you now connect it (via the network) with the rest of your environment so can start communicating with the tech stack. Things like security, addressing, internetworking, error handling, congestion control and firewalls are found here.
• Layer 3: Security--Now that you can get to your new environment, you have to protect it. This layer ensures that the appropriate IDs are created, maintained and have the proper level of security clearances for the environment in question. Intrusion detection and assessment of policies for HIPAA or SOX or any other recognized compliance are addressed here as well.
• Layer 4: Monitoring--This layer encompasses monitoring of the various application layers that are required for operations. Monitoring includes physical server (box up/down), network monitoring (link up/down), application monitoring (database, applications tiers, etc.) This layer provides for the installation of your monitoring software.
• Layer 5: Database--If the application(s) requires use of a database, then installation, configuration, permissions and tools are addressed here. This layer provides for database container creation, space allocation and table definitions. There is also another subtly in this layer: system DBAs and application DBAs. Simply stated, a system DBA creates database containers (or spaces) and allocates disk space or SAN storage, memory and processing threads to a given container. This is typically (but not always) an infrastructure job. An application DBA defines tables and SQL procedures and so forth that pertain to a specific application. The application DBA needs more memory; they work with the infrastructure DBA for more resources. How you expect this interaction to work should be defined here.
• Layer 6: Supporting SW--Most applications today leverage third-party software to function. This layer addresses any additional software required for the COTS package installed on the system. This could include, but is not limited to, ODBC drivers, web server plug-ins, O/S drivers, LDAP software, PDF writing software, third-party charting applications, etc.
• Layer 7: Interfaces--Most applications either consume data, produce data or both. This layer addresses establishing any inbound or outbound data feeds necessary for your system. The building all interfaces occurs here.
• Layer 8: Application--This is the application itself. It is supported by all of the previous layers of the technology stack. This can be a vendor package (Commercial Off The Shelf, a.k.a. COTS) or a custom developed application
• Layer 9: SLAs--Once your entire stack is complete, you could add the final and ninth layer as a bucket to handle all of the details with moving the stack into a support or sustainment state. This layer is a holding place for things like Service Level Agreements (SLAs) and reporting metrics, application. Support procedures, change control process as well as disaster recovery/business continuity processes and all of the service-oriented agreements that support the technology stack.

The simplicity of this model is that each logical component of the stack is separated and able to be changed or negotiated on its own merits. If a layer can’t be changed--like in our particular hosting agreement--we can easily explain why and point to the ripple effect that a particular security access would have across the rest of the layers, or the impact it would have with other clients.

Having Your Cake and Eating It, Too
This model has served me in multiple ways--and more times than I can count during my IT career. I have used it to:

• Plan the Build--It provides a great way to plan technology implementations and really assists with performing timing estimates for builds from a project management standpoint. It may not be same in all organizations, but I have found the cake layers tie nicely to functional teams as well.
• Isolating Problems--When troubleshooting problems with a new technology, my teams isolate each layer to determine where in the stack we were seeing the issue. It really helps for teams to explain what they believe should be happening between stacks.
• Hosting Menu--When negotiating new hosting agreements with companies, we use the cake (or tech stack) diagram to explain the layers of our technologies and mutually agree what level of access a customer needed. I have used the opposite as well. When we need to negotiate access to someone else’s systems, we use the cake diagram to explain exactly what level of access we are looking for.
• Negotiating Map--When problems or turf wars arise, we always go back to the cake diagram to lead our discussions and agree to “rules of engagement” when a client needs access to something (like the OS, for example). Having the cake illustration has saved us countless times in reaching agreement.

Almost without exception, problems need to be solved and technology builds need to occur in quick fashion. Having a handy framework like the Cake Diagram enables teams and PMs to segment work and come up with plans by area (divide and concur). Your team’s quality will improve, implementation times go down and everyone’s understanding goes up.

And when everyone marvels at the results you and your team have produced, you can just say, “Forgettaboutit! Just call me the IT Cake Boss!”