It looks like most decent-sized enterprise IT organizations have either begun their transformation to an IT-as-a-service model, or are well along their path. Maybe it’s sampling bias on my part, but it’s rare these days to meet an IT team who isn’t doing at least something with the concepts.
At some point along the way, the quintessential subject of automation emerges as a Really Important Topic. And — sad to say — there is no “automation pill”.
A few weeks ago, I was asked to share my perspective on the different “cloud automation” packages that are out there. As a VMware employee, I would have been quite justified in singing the praises of vCAC, and dissing all alternatives.
But I didn’t take the easy bait.
Instead, we got into a great discussion around the desirability of having an “automation philosophy” that could help IT leaders guide their choices and approach.
I see the move to an ITaaS model as I do adolescence: sooner or later, it happens to everyone.
Yes, it’s awkward at the beginning, but things do get better as you mature :)
With ITaaS, IT refashions itself as the IT service provider of choice, a builder/broker of services the business wants to consume. Measurement systems change, core processes change, roles and responsibilities change — it’s a dramatic refactoring of familiar IT.
Automation is the secret sauce that makes ITaaS work. It is not an afterthought. The more you automate (and re-automate, and re-re-automate), the faster/cheaper/better IT service delivery becomes. New process insight drives new automation, which delivers better results.
If you’re in the manufacturing business, for example, continual process engineering and its attendant automation is a way of life. The same appears to be true for enterprise IT these days.
So, at some point, the IT team starts investigating different “cloud automation” products. That’s where the fun starts. It’s not hard to come up with a list of 30+ vendors, each with their own marketing pitch, terminology, positioning, etc.
Things can get pretty confusing very fast, unless you’ve got some guiding principles in hand. And that’s what I mean by a “automation philosophy”.
Towards An Automation Philosophy
Here are the questions I’ve been using when discussing this topic with IT organizations. Feel free to think of these as a starting point — extend, modify and edit to your heart’s content:
1. Do you see yourself as a heavy automator?
Do you see continually improving automation as a really big deal in your environment? Or do you see yourself covering the basics, and then moving on to more pressing challenges?
Consider the familiar trope of provisioning a server. The difference between five days, five hours, five minutes and five seconds might not be relevant in your world. Or extremely relevant, depending.
There’s a strategic choice to be made between creating processes that are “good enough” that they get the job done — and continually investing in process improvement and the required automation.
For some, the answer will be “good enough is good enough”. Fair enough. For many others, that won’t be an option. You don’t have to be Google to appreciate the payoffs that can come from increasingly sophisticated levels of automation.
2. Do you see automation as extension of your existing model (improving existing processes and workflows), or working towards creating new models (as well as new processes and workflows)?
With this approach, everybody does what they’ve always done, but simply use better tools to get their job done.
But shouldn’t expect order-of-magnitude improvements without order-of-magnitude model changes — and everything that entails.
My personal perspective is that the best automation packages do both: they support existing models and workflows, but also create the opportunity for entirely new converged operational models when desired.
If you’re enamored with the breathtaking potential of software-defined IT, you probably realize that significant model changes are demanded to reach its full potential.
And that aspect — if relevant — should be part of your automation philosophy.
3. Are you willing to change your organizational model to get better automation?
Look at any traditional IT org chart, and you’ll see the silos (or cylinders of excellence if you prefer) around classical IT disciplines. Without changing the organizational model, the best you can hope for is automating the silos, and not how they interact to create services.
Technology in IT is becoming the easy part; re-engineering IT organizations to function more effectively is where the real heavy lifting occurs. And you should decide at the outset — are you and the team up for this?
Show me any IT organizational org chart, and I can quickly assess (a) where they are in their transformational journey, (b) what level of automation they already have in place, and (c) exactly what kinds of pains they are experiencing when it comes to improving the situation.
4. Do you know enough to make intelligent long-term choices?
So I scraped together a basic, inexpensive rig knowing full well that — as I did it more — I’d better understand (and invest in) what I really needed to do the job. Everything I bought initially I thought of as “disposable” — an investment in me getting smart about what I really needed.
When I did finally pull the trigger on an expensive keyboard rig, I knew exactly what I was doing, no regrets.
As I worked with IT organizations starting to move towards ITaaS, I found more than a few who had adopted a similar “disposable tool” philosophy at the outset.
The thinking was simple: invest in learning at the beginning, which will in turn lead to better (and longer-term) choices. Most often, this was done by a centralized automation team that spanned traditional technology silos. Maybe they didn't stick with particular products over time, but their knowledge and learning was certainly recyclable.
No major investments, no long-term commitments — until you feel you’re smart enough to make a wise decision.
No surprisingly, every software vendor would prefer you to bet, and bet big. And, in many situations, that can be advantageous. But if you’re just starting out on this whole ITaaS automation thing, you may not know enough to make an informed decision.
So invest in getting smart :)
5. Will you eventually see automation as software development?
If you’re going to be serious about automation, you’re going to be writing code in some form. If you’re really serious, you’ll be writing a lot of code. And, depending on your automation philosophy, that’s a good thing.
That’s the whole #devops thing in a nutshell: infrastructure automation as code.
Viewing automation as a software development activity makes you consider things like code re-usability, testing environments, release management, documentation, and all the other disciplines that are part and parcel of a software development model.
This view also implies that you’re hiring infrastructure process engineers with a software development background. And that’s not exactly a garden-variety skill set.
6. Does this whole open source thing really matter to you?
Nothing brings out the passion in industry types like a good debate on the pros and cons of open source models. Open source automation tools are no exception — people get pretty worked up.
I tend to be pragmatic in my views.
When it comes to automation, what you’re essentially doing is encoding process know-how so that it’s reusable and extensible. If you’re taking this whole automation thing seriously, you’re talking about a repository for a continuing investment of many person-years (previously known as man-years).
A close analogy might be ERP, or SAP in particular. An environment like SAP can be viewed as a repository of business process know-how: lots of standard templates extended with unique secret sauce. SAP is clearly proprietary software (and wildly successful), but it’s extensible, portable, integrate-able, etc.
I tend to focus on how well the tool does the job, rather than how the tool is licensed.
I do meet very specific IT shops that are fully committed to using as much open software as possible. The ones who are successful bring two important things to the table: a long-term perspective, and lots of software engineering types to make things work.
However, large amounts of time and people aren’t always an option …
7. Is there a place where you can get started?
It’s often the case that we think about automating everything. And, since all the legacy pieces have to move together, it’s a painfully long journey. Not to mention intellectually challenging.
I’m quite enthused when I meet more than a few groups that are on their second (or third!) iteration of their vSphere-based “cloud”. That’s progressive.
If you have such a portion of your environment, consider yourself fortunate — that’s where you can learn and move quickly on ramping your automation muscles.
But if you have no such environment, your approach to automation will be dictated by legacy concerns, meaning slow and incremental progress vs. substantial breakthroughs.
And -- it has to be said -- it's devilishly hard to automate environments that weren't designed to be automated :)
Putting All The Pieces Together
When it comes to automation, I believe IT leaders need to arm themselves with strong opinions.
Building an IT delivery environment that is continually improving (based on continually improving automation) is a central strategy issue, and deserves careful and deliberative thought.
Having a well-thought philosophy on the topic can help in quickly navigating the inevitable decisions and distractions.
So, what’s your automation philosophy?
Like this post? Why not subscribe via email?