Reimagine the Possible

Today I want to offer ideas you can use to shake out the IT cobwebs.  These use cases could be exactly your challenge, part of your challenge or just what you need to reimagine what is possible with the world of automation.

Before we begin, I wanted to throw out a few brief thoughts:

  1. With orchestration programming, nearly anything is possible.  However, no one has infinite time, budget or programmers.  While I am optimistic, I am realistic.  Do not get caught by the everything-is-possible trap.
  2. There is a difference between native support and extending support with customization.  The gulf can be a huge one to cross.  Therefore, cross it with proper expectations.

Use Case 1:  Self-Service Portal

A self-service portal can be a huge enabler to moving into a consumptive IT model.  In enabling your target audiences to have access, you make consuming IT easier and get your IT staff out of the provisioning game.  You also can stretch self-service in a lot of cases to include self-support or push support costs down to lower cost resources.  I will illustrate a few for you.

  • Developers:  Do you have developers who need ephemeral resources?  They need to jump into a project, do their work and deploy it out.  The less lag the developer sees, the faster they can get the line of businesses their expected digital goods. When they are done, you are automatically set up to reclaim resources when you are finished!  Money, time and resources saved by a portal!
  • VDI:  There are lots of ways to skin VDI but the self-service portal can enable users to request the desktop they need.  If some staff does not need their VDI today, it can be shut down.  By providing an interface to VMs, you get the benefits of power savings (VMs being off), elasticity, templates and a whole lot more.
  • Push work to those who cost you the least:  Lots of businesses have staff that can perform work but granting access means violating controls or making compliance a pain.  The self-service portal can let you push those workflows to your staff where it makes sense.  Do you need someone in your help desk to be able to do a particular function?  If you provide a workflow then they can perform that one workflow.  In one fell swoop, the coworker is both enabling your business and minimizing compliance costs by not exposing your business to unnecessary risks.  The right work safely and securely delegated to the right people. It’s a win-win.

Use Case 2:  Reclamation

I have a series of questions for you. You can decide if the answers help prove a point:

  1. True or False:  Most IT organizations tear down firewall openings when they are no longer used.
  2. True or False:  Most IT organizations shut down and recover unused VMs or physical hardware when it is no longer in use.
  3. True or False:  Adding VMs does not add workload to your staff.

Businesses waste tons of resources, time and hard earned dollars on hardware that is doing more than it should or nothing.  Manually auditing ACLs is a pain.  The process of finding legacy systems, pulling them and shutting them down takes a lot of time.  It’s easy to pile on more and more but soon you are back under water.  This is where reclamation begins to help you fight back against technical debts abounding in IT.

Reclamation is the promise that you can automatically get back some of the things you have in your environments today.  If you have a developer who needs a test environment, why not give it to them for 30-60 days?  If they keep their code in a repository, when you shut it down, they will have lost nothing.  If you make it easy to provision again, they could be off and running in the next 30-60 minutes by re-requesting it if they truly need it.  The other option is their boss could approve a renewed lease.  Operational swings, just in this one use case, should begin to show you the power of getting your resources back.

Use Case 3:  The Greenfield and Re-greening Your Brownfields

Greenfield installs will almost always be a safe way to start off automation or orchestration initiatives.  With little to no technical debt, workflows can be scoped around defined objectives of a greenfield.  Users can be trained and IT offerings can be put out with unrivaled efficiencies.  The real loss though is to assume it stops there.

Systems such as Cisco’s UCS Director can be positioned in companies to project an awesome toolset onto a greenfield install.  Need a portal?  Check.  Need chargeback?  Check.  Need a service catalog?  Check.  Need it to manage your greenfield?  Check.  Now you have enabled all of this automation, stop for just a moment and think about your legacy.  Can you have UCS Director import and manage your existing legacy footprint?

A tool such as UCS Director can be easily configured to add additional clouds or pods of resources to it.  Is it safe to assume all of your workflows and service catalog entries will work?  No, but with the expertise gained in onboarding greenfields, you should have a much sharper eye toward incremental extensions to your brownfield that provide relief and scale.

Maybe you start to keep copies of templates in both green and brownfields.  You could give users a choice or push them to a given data center based on their role.  You might even once again give your Network Operations Center tools or workflow developed for greenfield, for the brownfield saving your other resources off-hours workload.  The key enabler of this reach was the fact that a tool like UCS Director can reach into and control multiple clouds at your choosing.

Use Case 4:  Federations Making Things Happen

No one makes the perfect tool for everything.  Every tool has something it does better than any other tool on the planet.  Finding efficient operations will be about balancing multiple tools to build an answer to running your digital business.  Running a data center is not about one tool but the collection of tools and skills at your disposal.  Orchestration is no different and just because a tool you might be looking at is in the upper right of a quadrant does not mean you are escaping multiple tools.

At this stage in the automation and orchestration market, picking tools and managing their overlap will make a tremendous difference to your success.  If you have existing investments, it probably is not in your best interest to throw those away.  If you are taking an iterative development approach, you can chisel away at existing tools and migrate workloads to different tools.

You will have a choice when migrating functionality over: to pick either native capabilities or develop in-house customizations.  The risk-reward calculation for in-house development is not necessarily about using automation workflows that increases risk.  The risk is going out and putting in major investments into custom automation interfaces to replace existing tools.

Any good orchestration tool will have a REST interface, support making use of web services of other tools and support multiple ways to be programmed.  Extending an orchestration tool to interface with tools is very different than fully writing a replacement.  In some cases, orchestration tools will have the programming capability to do a lot, thus you need to have clear boundaries on where one automation implementation starts and another tool ends.

Frankly, there can be some very complete and very functional designs by merging multiple tools together.  Some of my most exciting customer stories have been helping them weave a solid case around monitoring, software provisioning and leveraging a tool like UCS Director.  These use cases are only going to get better as tools missing adaptability fall out of use and automation gets better. You can look to replace other tools you use as it makes sense having a strategy with clear bounds.

Other Ideas?

You may have other cases that are your differentiators going forward.  Whatever they are, if they are scoped correctly, they could be your key to success with IT 2.0.  I would love to hear from you about what your stories are, what’s working and what’s not.  In the end, what will separate out those who are successful and those who stumble and fail are those who can keep focus on their strategic use cases.