...building hybrid clouds that can support any device from anywhere
Hey Readers, welcome back to another post in the series on Orchestrator Best Practices. In my previous post Automation–System Center 2012 – Orchestrator Best Practice Series–Naming Conventions, I talked about Runbook and folder naming best practices as well as lightly touching on a concept called “DRY” or Don’t Repeat Yourself. This post was an important one to get you started with creating a structure that can assist in following the logic through the flow of your IT process automation Runbooks in Orchestrator. Again – there is always a better mouse trap (see this post in our “Just for Fun” track if you are curious ) but seeing examples on how other IT Pros use and construct their Orchestrator Runbooks seems to help solidify things for me sometimes – so give it a look and adapt your own “Best Practice”. The concepts covered in the previous post are worthy of a review as you move through your project of orchestrating orchestrator. You’ll likely rename, move, update, and tweak the structure up till the very end to ensure that it fits process flow and is organized in a matter that makes sense to you.
Well, now that we covered how to get started naming and organizing your Runbooks, I thought this post could cover some details around how to avoid burying logic. What is buried logic? Buried logic is represented by anything that isn’t easily surfaced within your Runbooks and individual activities that may get impacted by updates or modifications to your Runbook(s).
It is important to reduce any buried logic (when possible) to avoid adverse impact during future Runbook modifications. The next sections will cover a few areas to give you an idea on how to avoid falling into the buried logic trap and make your Runbooks more dynamic and easier to update as they change over time.
Types of buried logic we’ll focus on include the following:
Data manipulation or field parsing is sometimes necessary to obtain data values embedded within strings for further processing in subsequent activities. In many cases these data manipulation processes are embedded as part of an activity that may not necessarily be apparent without deeper analysis. Ideally, these types of operations should be limited and optimized to avoid hidden logic and potential for broken Runbook execution due to updates. To illustrate what I mean by a data manipulation within an activity, take a look at the example below of a field parsing operation. In some situations, this type of parsing is absolutely required to get data to be represented properly for subsequent activities in your Runbook. Though the capability is there and is very powerful, it can many times get buried and be difficult to isolate as updates are made. As you can see below, the full field parsing details can be hidden from view unless a right click / expand is done on the field to show the operation. Again, this type of operation is great when used in moderation – just be aware and use wisely.
Another way to avoid buried logic is to take into consideration the use of Exit and Do Not Exit logic within loop operations. There are two ways to continue or exit a loop within an activity. The use of Do Not Exit logic can create unnecessary complexities in logic processing for the Runbook when combined with Exit criteria. In order to ensure simplicity for logic processing, Do Not Exit logic criteria while also using Exit logic should be avoided. This standard should be leveraged for every logic loop where possible to indicate the clear decision on looping or exiting. Ideally, create a standard and stick to it if you can. Consistency is key!
The following criteria on links should ideally be leveraged consistently throughout a Runbook hierarchy to help alleviate buried logic issues.
So in summary, what are we really saying here?
Thanks for your attention on this second blog post in the series. That’s it for now.
Till next time, Happy Automating!
Go Social with Building Clouds! Building Clouds blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Building Clouds Twitter account Private Cloud Architecture LinkedIn Group Building Clouds Google+ Community Cloud TechNet forums TechNet Cloud and Datacenter Solutions Site Cloud and Datacenter Solutions on the TechNet Wiki