Tools Over Process
Over my career, I have worked with thousands of clients, and one thing is consistent across the conversations I have.
The clients are more focused on the tools than the process.
The explosion of tools in the technology market has not helped this fact much either. Now that tools are virtualized, and we see more and more software-defined tools, the tool sprawl is in full growth mode. Need a load balancer? Load up on this virtual appliance. Need a new Firewall? Load up this IOS image. The server sprawl that we saw during the height of virtualization is probably going to be eclipsed by the tool sprawl we are about to see with software-defined infrastructures.
This tool sprawl has and will lead to tool-rich environments that are process poor. The impact of this will be massive security risks due to a lack of knowledge of tools and the increase in the total attack surface within an organization. We will also see outages with trickle down and much larger failure domains due to the lack of process maturity within some IT organizations. I can also see that just like in the past; there will be a tendency to blame the tool and capitulate from one tool/platform to another, and not address the foundational process issues within the organization.
History repeating itself
So why do we keep learning this same lesson over and over again? Mainly because gaining process maturity is hard and even more difficult is staying mature. Also, organizations typically don’t understand the value of process maturity in information technology service delivery. Usually, the time process maturity value is realized is at time of incident. These incidents could be an outage of a critical system, security event, or the competition is outmaneuvering them due to efficiencies gained through mature automated technology service delivery.
Over the last few years, I have been working with clients who want to migrate to the cloud, and my first question to them is why? The next question is what do they mean by “the cloud”? Usually, when I hear this from the client, I start trying to understand how they deliver their technology services today. I find that most have standardized or a common off-the-shelf toolset to simplify their service delivery. The providers of these applications are rapidly moving into a SaaS, delivery model. I encourage clients to migrate to these models for their applications if they are not doing custom development and the applications are not a differentiator for their business.
Right Tool for the Right Job
That brings me to the main point of this post. Use the right tool for the appropriate job. Using the correct tool in the right way is all about the process in which the tool is used. You would never use a powered screwdriver in the same way you would use a manual one or a nail gun as a regular hammer. You would lose the efficiency of the tool.
Many clients are doing this with cloud services today when they “lift and shift” applications on the cloud. Organizations gain efficiency in hyper-scale IaaS platforms like AWS and Azure by turning systems or processes off when they are not in use. This type of capacity management is a major change for most organizations. Most have been trained to “Deploy! Deploy! Deploy!” what happens to the infrastructure after deployment is not the IT departments responsibility or concern. These actions create massive amounts of sprawl, and sprawl in an IaaS cloud platform is a terrible thing. By not utilizing the tool the right way, organizations are not getting the cost efficiencies promised by cloud vendors. This tool use makes the IaaS cloud inefficient for many and leads them to the belief that cloud is not right for them. However, the tool was used the wrong way from the start.
Changing Capacity Management
So, then it is simple, right? Just change the way we do capacity management, and we should be good. I wish it were that simple. The issue is this. Evolving capacity management to align with just in time computing becomes a daunting task. As the organization tries to reduce its amount of compute inventory to realize the efficiency of cloud and deploy systems as thin as possible, the need for new process management around inventory and capacity management becomes critical.
The capacity management is also tied directly to the business need for capacity at the time the business needs it. This leads to the fact that the capacity management of IT resources needs to be directly tied to the business operations and be treated as a constraint to the organization providing its products or services, just like any other raw materials. This redefining of IT resources results in the restructuring of teams, measuring IT service delivery differently, using manufacturing efficiency principals and focusing IT service delivery on business results rather than traditional IT metrics. Therefore, migrating to the cloud is hard and requires a shift in people, process, and lastly tools to be effective. Many organizations migrate (lift and shift) the tool first and then try to fix the process under the duress of the inefficiency. These actions can and often do lead to a failed cloud implementation and a lot of tools and vendors taking the blame.
I will leave you with this final analogy. This situation is very similar to someone wanting to get into shape. One buys the gym membership, exercise equipment, new outfits, shoes and any other technology to get into shape. However, they fail to change their eating habits, he/she does not make time to workout, and sometimes he/she even hires a trainer who makes them sore. Then, the person gives up and blames all the stuff/tools they had around them instead of focusing on the root problem which is that it takes commitment and hard work consistently over time to see real results.