As always, it's best to start with a bit of perspective. Whether you've begun reshaping your IT environment and organization to be cloud native, or are yet to embark on the journey, you need to understand how the majority of organizations are organized to design, build, and run current IT systems.
As an example, let's consider an insurance company that offers several products to its customer base (home, life, and auto insurance). Internally, it has several teams, which help support its products: policy developers, field sales teams, statisticians, HR, programmers, marketing, actuaries, and so on. Each of these teams consumes the services of the IT team (whether it's servers for emails, clusters to run statistical models, databases to store client information, or websites to be a storefront for the public).
The IT team is in turn separated into several groups based on domain competencies. Network, security, database, and ops are typical teams found in these outdated organization models. These teams sit parallel and separate from the development teams, which are totally focused on writing code:
The preceding diagram exhibits the organizational structure of a typical company developing a product. There is strict separation between the technology domain experts and the product/service owners.
The problem here is that fundamentally these organizations are at odds with each other. The view of a CEO is that the left-hand side of the diagram is trying to maximize revenue and capture more business/customers. The right-hand side of the diagram is viewed by the typical CEO as a cost center—a group to be minimized and streamlined ad infinitum.
This mentality has ingrained itself in the behavior of individuals, the corporate culture, the psyches of leaders, and the cross-border collaboration efforts between these two groups. IT teams view LOB teams as foreign entities making unrealistic demands to build systems in too short a time, with unrealistic features for very little cost. On the other side, LOB teams find the IT teams disconnected from the core organizational purpose and the customer problem they're trying to address. IT doesn't seek to understand business goals and seems to react with intransigence at every request.
This is further compounded on the IT side since each domain works within teams comprising like-minded individuals. Security professionals work primarily with and sit alongside other security professionals. Likewise for network, DB, operations, and architecture. While this may make sense in a top-down view, this model facilitates echo chambers where the same ideas reverberate from person to person without being challenged or tested in a meaningful way by someone who is a foreigner to their area of expertise. Under this model, domain approaches became inflexible and brittle. Any challenge to this is how we handle X is met with stern no or long exception processes involving senior leadership and review boards. This siloing of resources also does the individuals a disservice. As they are cut off from the rest of the enterprise and technical teams, the chance to learn and expand their knowledge is more limited in general.
Each of these team leads (security, network, and so on) became protective of their resources and cut out turfs to entrench their role within the organization. They sought to put limits, guardrails, and processes around how their team members engage with other teams. They put rules around when and how other teams could leverage their people, and dictated what areas required their approval. Not only do they try to control the rate at which the team members can work, but they limit the ability of other teams to develop quickly without roadblocks.
For endeavors that required a mix of resources across multiple technology teams, a strict review process existed where leaders must review, give input, make a commitment, and provide oversight before a mixed joint team could be assembled. Oftentimes, these joint teams still run into many of the obstacles discussed earlier. These efforts typically devolved into a reporting structure where team leaders still had to be consulted before any real decisions could be made. These structures are the antithesis of an independent, autonomous team that can make decisions and evolve a product iteratively.
The apotheosis of these organizational structures and mentalities is the Change Approval Board (CAB). CABs developed out of a necessity to control any changes to a monolithic system, where a change can have many downstream effects. A minor configuration adjustment could create a cascade of issues downstream, crashing revenue-generating systems and causing dozens of severity 1 events.
The CAB was created out of necessity during a time where systems ran on shared hardware resources, services within the system were tightly coupled, and there was little visibility into the performance of the system overall (other than the output rate of the system). As technology evolved and system architectures progressed, the CAB remained as a holdover institution. CABs are still prevalent across many enterprise IT organizations, despite the technology limitation that necessitated the CAB in the first place no longer existing.
Alongside the CAB arose the Change Management Database (CMDB) and the Configuration Management Database. The purpose of these systems was as follows:
- Control and track the planned changes made to a monolithic system
- Track the current state of a sprawling system
Both of these systems arose out of necessity, but are obsolete in a cloud native world. This is because of the manual processes needed to keep the information stored within the CMDBs relevant. The practicality of maintaining these systems is lacking when they often store very little higher-order information that makes a data store like this useful to a user. The data stored has to be refreshed and maintained regularly, otherwise it goes stale and loses all relevance. In order to maintain its relevance, a significant amount of upkeep is required from the organization. This requires expending time and effort, which can drag on the productive time of resources to develop and build products. We will introduce the successors of CMDBs later in the chapter, but suffice to say that things should be automated, persistent, and relevant.
Alongside the CABs and CMDBs, email arose as the most important facilitator of project management and progression. Each of the domain teams leverage email to ensure that there was a written trail leading up to a decision. Teams use email for everything. Simple decisions that could be made in a five-minute face-to-face conversation are relegated to email. Email creates an important contextual history to understand how we came to a decision, but it does not enable teams to get the what as rapidly as possible. The same five-minute conversation in person could take a day or longer depending on how often resources answer their emails.