In a prior post I offered the recommendation of surveying your staff before you jump into orchestration.  Did you find any nuggets?  Was your staff excited to hear about the initiatives or were they hesitant?  Were there any organizational changes you could make to better set yourself up for success?

When you got answers, you probably found the good along with the bad.  As I brought up before, this is to be expected and should be that of as your base IT footprint.  You are always better for knowing what your strengths and weaknesses are.  Not facing them for what they are means you would only be stacking the deck against yourself.

Where to Begin?

Now that you have feedback and themes, you can start planning for the transformations that lie ahead.  As your company evolves, you will be required to pick a starting place.  Do you have greenfield opportunities, brownfield environments, outages or other legacy systems that need to be streamlined?  More than likely, one or more of these apply.

Most businesses will attempt to deploy a proof of concept (POC) automation package within a lab environment to see how well tools fit the bill.  You can get a win-win situation if your staff can evaluate the software and performance in a lab.  While other areas of your business will be important, you are potentially forming a very long relationship with a larger piece of software.  A lab or a proof of concept is a must to help drive out realizations before there is some kind of production mix-up.

When in a lab, you can see first-hand orchestration tools’ requirements, performance and a window into how your staff will interact with a new toolset.  Not all tools are equal; requirements in terms of additional software, hardware, licensing and potential bloat can scare away companies.  You should use this time to qualify software looking for sizing constraints:

  • How many supporting VMs/systems does it require just to stand up an instance?
  • Is the software geared toward VMs, physical blades or both?
  • Does the software support secure multitenancy?
  • Can you run any of the components you would be taking on past people within your organization?
  • Does the software have significant overlaps with other software you already have today?

The performance will be affected by all of the above questions.  You should also keep in mind that you need capacity to run the orchestration software.  The weight of a solution could also greatly swing the cost if you are then required to purchase a lot more components to just get off the ground.  This question should be easier to answer for companies running converged infrastructures, but if you are looking for a geographically distributed setup, this may be an area of extensive focus.

You will need your employees to embrace automation.  We have all heard stories of companies that made huge software/hardware purchases only to go unused by employees because they were not brought into the fold.  The largest area of change from automation will be around how your customers and coworkers interact with IT, thus a lab might bring you internal evangelists.

Employees who are jazzed about software and automation will have a whole host of ideas.  Those employees cannot be excited if they do not have a chance to imagine the possibilities.  I have been to many demonstrations where after the demo, employees were way more excited than the managers trying to explore automation.  Sometimes, improved morale is only one lab demo away.

I don’t know about you, but as a technology person, performing the same IT tasks year over year does not produce fulfilling work.  If we want to matter, we need to evolve, and as engineers we can only afford to do this when the mundane tasks are off our collective plates.  I can see all kinds of positive things I can do for a company once I have powerful tools at my fingertips.  Your employees will feel empowered too.

Your Organization’s Use Cases?

Use cases should be guiding principles of your adoption.  It is easy to imagine all of the solutions you can deploy once you have gotten excited.  The trick is aligning feasibility, need, ROI, downstream dependencies and organizational objectives to your use cases.  Otherwise, it can quickly become overwhelming if you are not taking the proper perspective.

You will need perspective as you move down a long-term trend of automation.  You will need to be evaluating the above characteristics on a recurring schedule.  Your company does not stand still and sometimes might even change direction.  Your scheduled development workload should follow your needs.

Sample questions you might ask to drive out use cases:

  1. Where do your consumers of IT interact with IT?
  2. Do your consumers have a lot of friction when using IT resources?
  3. Do you have provisioning processes that take a week or more just to configure basic services for users?
  4. Are your consumers savvy enough that if presented some interfaces to adjust their consumption,  might they be more efficient?
  5. Are people within your own IT organization siloed?  Is there friction because of inter-team differences in terms of turnaround time?
  6. Are you struggling more with IaaS, PaaS or SaaS?

Once again, some of the answers to the questions above should align to the feedback from your employee interviews.  Try to prioritize the list of use cases and let us talk briefly about requirements. 

Align Use Cases to Requirements

Use cases are meant to drive to a set of defined feasible goals with achievable ROI.  The order of what you work on will be a combination of both business unit and IT prioritized use cases.  Just giving your users more IT services does you no good if your own people are just more easily swamped at the end of it.

Now ask yourself these questions:

  • How well does the product you are running, through a proof of concept in your lab, actually work?
  • How well does it align with your use cases?
  • If you try to picture your company two years from now, does it look like the POC lab software has the runway your company needs or would you have to replace it with something else?  This could be a hidden cost if the software you’re testing does not have the feature set to get you to a longer term finish line.

Do you see how the use cases help provide clarity to meaningful requirements?You can be better positioned to ask the right questions to identify what software to buy and where to invest your time.  Maybe the lab you set up is exactly what you needed, maybe it just needs to be augmented or possibly replaced.  My hope is by now, you see the value and it is not a scary process. Translating use cases into actions will drive your business, and if done correctly, do it very efficiently.