One hundred and four. That's the number to beat.
I use the number 104 because that's the number of keys on a physical keyboard. You know the keyboards I'm talking about.
Not the little touch based ones on your smart phone — the keyboards you use if you write and support the software that runs the Internet and makes it a fun and interesting place to play.
But here's the interesting thing. If you're as old as me or if you just like classic cartoons, you'll remember George Jetson of "The Jetsons" fame only had to press one button.
The Challenge of Manual Deployments
Licking a Tootsie Pop is fun. Manual deployments are not. In fact, to be blunt, they just suck.
The real number of keys you need to push in the case of a manual deployment is probably closer to 5,000 or 10,000. That's a guess, of course, The world will never know the exact number of buttons that must be pressed in a manually processed software deployment.
Why would anyone bother to count? It's not like the Tootsie Pop problem: the licks required to reach the center are good things everyone likes.
The key presses and steps to be followed in a manually driven test and deployment cycle are nothing but pain that typically takes place in the dark of night or the wee hours of the morning. If someone were to count the steps, then someone might have to do something about it.
Some companies have evolved past the parasitic drain that manual deployments can effect upon a software development and operations team. Many more are still struggling to lift themselves out of the hole dug by years of living from hand to mouth and the catechism of "we don't have the time to automate our release and deployment processes."
Most lie in the middle, slowly evolving piece by piece and fighting back with the mantra "we don't have the time not to automate our release and deployment processes."
Map to the Future
So, if an enterprise wants to create its own revolution by evolution, what map can it use to chart it's course? What landmarks exist along the path to the new world? I don't know if there is a one size fits all plan, but here is the inspirational evolutionary model I have adopted:
Many Buttons → "GO" Button → "STOP" Button → No Button
- Many Buttons — This is the realm many shops live in. Some have automated builds, but don't go further than that. Some have builds and testing but go no further. Some go fully out through network appliances and firewalls and even into CDNs if they have an API to automate. You can't get to the next phase unless you treat configuration as code and then weave all of these together with a mix of BPM and automation.
- Go Button — This is the world that those in the many buttons world aspire to. All deployment and release processes including smoke testing are planned out and automated with scripts and deployment frameworks. This phase is complete when you have collapsed all deployment steps into one work station that can kick them off at the touch of one "go" button. The go button model has reached it's potential when you have gotten to 10 deployments a day without any sense of organizational fear.
- Stop Button — One step beyond the go button milestone is the stop button phase. Not only are deployments planned out and automated: they are scheduled, just like a batch job and require a person to stop rather than start them. Once adaptive expansion of compute power is mainstream in your organization, the stop button model of deployment is not far off because people have embraced the idea that build processes kicked off by a schedule, can be more reliable and error free than those that require human intervention. Enterprise content management system (CMS) platforms and any shop with large data movement requirements have had these sorts of things up and running for the last few decades with significant financial exposure involved and yet the manually biased enterprises want to hold on to their Frankenstein-esque view of stop button deployments.
- No Button — This seems far fetched until you look at the shops with large batch jobs running every day and night. Where are the stop buttons for those activities? It's not apparent because the batch jobs are run so predictably and without error that nobody ever thought about creating the stop button.
Learn to Love the Machine
Deployment happens. It can be real in your shop. The painful part won't be in the automating. It will be the amount of cajoling you have to do to get the villagers to put down their torches and their pitchforks.
It will be in the endless conversations you must have to persuade people that the economies of scale are real and the manufacturing sector proved this model out long ago (as detailed in the goal by Eliyahu M. Goldratt and the Phoenix Project's Gene Kim).
The automation machine isn't a Frankenstein creation to be feared, it's a Rosie the robot maid to love.
Images by Hanna-Barbera Productions.
About the Author
Stephen Fishman has been working with enterprises both as an employee and a consultant for more than 20 years. He has studied with and practiced alongside many industry leading technologists, business strategists and user experience professionals. Stephen is currently Director of Consumer Platforms for AutoTrader.com and is working with his editor to complete his first book.
- SharePoint is Back, Yammer... Not So Much
- 3 SharePoint Paths for the Next 10 Years
- Microsoft Beats Amazon in Cloud Storage [Infographic]
- Why Companies Can't Afford to Go Overboard with Analytics
- Groups for Office 365 Transforming Collaboration
- Everything Bill Baer Has Shared About SharePoint
- What We Learned at Microsoft's Ignite