When I was a child, my grandparents took me to see the Disney movie based on Johann Wyss’ The Swiss Family Robinson. This was in the days when seeing a movie meant going to a theater, and I recall the sense of wonder where anything could happen in that big magic box of a building. The most lasting memory, though, of that childhood experience is of the sprawling tree house the Robinsons built with its connecting paths high in the trees. It occurred to me recently that the art/discipline of IT orchestration, better known as Runbook Automation, is a real-world adaptation of that tree house. The Robinsons had a simple need: to navigate their environment safely and without undue costs (effort, materials). Notice we don’t say ‘efficiency’ – more on that later.
Where the Robinsons had trees and vines to work with, we have IT systems and processes, and there are notable parallels between these two sets of resources. Consider the following statement: “We have these big moving structures that have been shaped over time by the environment into imperfect symmetries.” Are we talking about trees or about IT systems? “We need to get from where we are to where we want to be using these structures.” Again, you choose the subject.
Like trees, IT Orchestration must grow and adapt to changing environments
When dealing with IT orchestration, we build pathways among our systems and processes using a similar approach to the tree house pathways. Experience has shown us that the best pathways share some common qualities; they are safe, flexible, adapt to growth, can be used to reach more than one destination, and sadly are by their very nature impermanent creations. Like the trees, the systems and processes among which we build our orchestrations are always moving, sometimes a little bit at a time, and sometimes quite a lot over a short time. The purpose of the orchestration is to perform a defined workflow within a given environment, and it is equally unreasonable to expect an orchestration to last indefinitely as it is to expect our suspension walkway to last forever. Trees sometimes grow in opposite directions; sometimes a tree falls in the forest. Sometimes IT systems are changed to fulfill new requirements, and sometimes they are retired. We must make peace with the reality of IT orchestrations not being a “set it and forget it” type of construct. So then how do we obtain good value from our orchestrations?
From a tree to a staircase made of mahogany
One of the critical enablers to building good value orchestrations is the skill set of the builder. As years have passed, many IT professionals have evolved from being technology generalists to being specialists in some specific area. Many of us focus our learning and skills on service desk automation, performance management, or on database engineering. Orchestration as a technology is still maturing, and an orchestration builder needs the ability to adapt to this level of maturity – to be more of a generalist working in a “primitive” environment. Ingenuity and flexibility are highly valuable traits – each system and process has evolved uniquely and offers a distinct set of bends and branches to the builder for use in constructing a pathway. To orchestrate successfully, we must survey the environment, assess the tools we have available, and build valuable paths that are safe, flexible, and adaptable. Note that due to our “organic” environment, orchestrations are often utilitarian entities – don’t expend unwarranted effort to create highly polished elegant solutions because the environment will change, and then the beautiful efficient solution will be more suitable for some mythical orchestration museum than for performing a workflow. The value comes from having a suspension bridge made of planks and vines, not from a polished spiral staircase made of mahogany.
How to adapt to changing environments while still ensuring safety
What makes an orchestration safe, flexible, and adaptable? Increasing safety, what IT formally calls “utility,” often requires us to leverage the basic features of products or processes and to forego the more advanced features. Why? Because the basic features are more mature and are less likely to change, thus breaking our orchestration. Basic features are also more likely to be useful in more than one orchestrated workflow. If an advanced feature is a critical enabler, then many times we can recreate it using the orchestration tool. Or perhaps we build the workflow to use the advanced feature and with the understanding that we may have to change it sooner rather than later. Flexibility and adaptability are facilitated by not only considering the current state of the environment, but also analyzing the environment for likely future configurations. This projected future state is valuable knowledge when building resilient orchestrations – trees generally grow up toward the sun, and systems generally mature to support commonly-accepted IT principles or practices.
So, how do you get started with IT orchestration?
One of the most common questions we at Windward hear from prospective customers is, “Where do we start with orchestration?” In most instances the best answer is to start with the highest value paths. Begin with one basic orchestration that will either save time for workers, increase accuracy of some function, or will shorten fulfillment time for some common request. If we want to get fancy, we can also consider whether a potential orchestration can be used in multiple workflows, however we don’t have to think that deep the first time around. This approach requires us to understand how our systems are utilized to deliver services to our customers. Yes, analysis will be involved; we mustn’t assume that a utilitarian construct requires no forethought. Once we understand the problem we want to solve, then we move on to our familiar approach of establishing a baseline, organizing stakeholder inputs, formalizing requirements, designing the solution, etc. Build one path/orchestration at a time. Design our paths with re-use in mind. In general, construct re-usable paths earlier and special-purpose paths later.
The benefits to the organization of this approach? By beginning with low-hanging fruit, we enable the IT department to demonstrate value to its customers quickly while gaining time to grow internal competency with the orchestration tool. We also learn how orchestration projects differ in execution from other types of IT projects – and they are a little different. And we benefit by allowing the orchestration products to grow in maturity, so that we can build next week’s path using a table saw instead of a hand saw.
Once a few orchestrations are in place, it’s very rewarding to stop and just observe what we’ve built. See the elegance in the utilitarian solutions, watch the little lights flicker, and wonder what we might do next with our big magic boxes.
