Windward Insights

IT Orchestration - A Real World Tree House? (Part 2)

Written by windward


… continued …

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.

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.