Mike Steineke

Why was automation important?

MSteineke

 

A few weeks ago, a colleague of mine Steven Murawski reached out and asked to meet at discuss why automation was important for me back when I hired him to work for me at a previous job.  At that time he was a PowerShell MVP working at one of the local municipalities and I was the Vice President of IT for a Software as a Service firm with fortune 500 customers.

We met for lunch and he gave me more context on his question.  He went on to explain that in his new role as a Cloud Developer Advocate he meets and talks with a lot of companies.  He like myself prior to working at Microsoft has attended and spoke at a myriad of technical conferences.  We have both heard and follow technology trends, he was trying to understand why my perspective was so much different than that of the CIOs, IT VPs and Directors he was meeting with.  I had always joked with him that I knew I needed to learn PowerShell, but it was just easier to hire him.

When I hired him to help with PowerShell automation it was 2010, we were running Windows Server 2008 R2, and managing multiple environments with over 150 machines was a big job for a small IT department.  We were always trying to do more with less, and automation is key to that.  It removes a lot of human error on configurations, it allows processes to be easily repeatable by any of the staff and delivers consistency.  Hiring someone who already was an expert in PowerShell gave us a huge advantage, rather than having all the other engineers ramp on the technology blindly, we had someone to guide and train us.

As we discussed the topic a few things came to light;

1.    Know your Company’s Business, support it, help drive it, make informed choices.

My company was a triple-launch partner with Microsoft in Los Angeles for the Heroes Happen {Here} Launch in 2008 for Visual Studio, Windows Server, and SQL Server.  I attended that event as a VIP, and during Steve Ballmer’s keynote he emphasized a vision called ‘Dynamic IT’.

Ballmer talked up Microsoft's "Dynamic IT" vision, which fits into four main topics that customers have been discussing with Microsoft: achieving agility and managing complexity; protecting information and controlling access; delivering business value; and making sure that IT professionals are "not the cobbler's children without shoes."  (Source: https://www.cio.com/article/2437047/servers/ballmer-launches-windows-server-2008--lauds-user-base.html)

This was just one incarnation of the notion that Information Technology is not just a division of a company (usually one considered a cost center), but that IT serves the business and should be a partner to it.  One sign of a successful company is one whose IT department is a valued partner in the success of the company.  IT departments need to understand their company’s business and be optimized to help drive the company’s competitive edge.  This is still true today with the adoption of SaaS and PaaS, use the commodity hosted solutions and invest your IT resources into the things that differentiate your company from its competitors.  How many companies have email as their critical differentiator? Source that out to a service!  The companies that don’t evolve are often the ones that don’t survive.  Today we would call this a company’s Digital Transformation.

2.    Stay current with versions of technology, Operating systems, Software packages.

We were different from most companies on how we used software.  We evaluated software that was core to our business, Operating Systems, Database Management Systems, Development Platforms, etc.  We made sure we stayed current on those systems, because the ‘secret sauce’ of our company.  Our software was built directly on top of those.  Often there were advancements in the platform that we used to leverage a technical advantage for the company.  If we could use some new feature in Microsoft SQL Server that made our system run faster with less coding on our part, we did that.  We built strong relationships with our software vendors and participated in pre-release programs continually.  Third party tools were picked very carefully, when you are using the bleeding edge software platform you need to make sure that the other tools you pick can keep up.

You don’t want to be held hostage by a software vendor that won’t upgrade or doesn’t upgrade at the pace you need them to.  This is especially critical for systems that are Core to your businesses survival and differentiation.  Through a lot of the Windows Server releases System Center was always lagged behind, so it made it un-useable for my environment.  We instead looked to PowerShell and automation to give us the ability to easily manage a lot of servers.  Being on this leading edge also afforded us the ability to help fix problems or bugs that we uncovered while the development team is focused on getting the product released.  We had fully tested our applications on the new platform and were able to confidently release our new software on or before the public release of the platform. 

Does this mean that we ran everything in the place on pre-release software, heck no.  We evaluated systems and picked the ones that made sense to the business to operate that way.  For example, our core Financial system that our accounting department used, we kept it on the current version, but did so on a timeline that made sense for the business.  We didn’t go and upgrade at a month or year end, but we stayed current.  Technical debt for unmaintained systems is a huge problem.  Software is generally not tested in a skip-a-version mentality, and if you think you can just go upgrade from version 4, to 5 then 6 without testing version 5 you also could be in for trouble. 

3.    Having solid tested and documented processes and as much automation as possible for whatever you are doing.

Because we did agile software development the idea of releasing to different environments was not foreign to us.  We had Development, Test, User Acceptance Testing, and Production environments.  If you release software on any frequent cadence you need to have documented well tested processes.  Automation plays a key part of that, in our case we had a lot of Data, and most CI/CD pipelines don’t deal with stateful data well.  i.e. updates to databases, moving database changes between environments.  We had a checklist with steps that included automated and manual processes for every part of a deployment.  If you are reading this, you may be thinking that this sounds a lot like DevOps.  If you are also thinking that the infrastructure management is also incorporated into that process, you would be correct.  When you approach IT from the point of Digital Transformation (IT with customer goals in mind), DevOps is how that happens.

 

Steven told me about companies that he has talked to and how many of them are just now finishing their server OS upgrade of 2008 to 2012/R2 to remain in mainstream support, and how for many of them it was a four-plus year project.  The problem is Windows 2012/R2 is only under mainstream support until October 2018, and another project to go to 2016 for them will take another four years and has not been started.  Having this monolithic approach will provide never-ending projects that don’t help your company transform.  The pace of IT innovation is much faster; you need to have ways to help you keep up with that innovation.  Automation is the key to removing bottlenecks and being able to respond to changes in an agile manner.

 

If you are an IT leader (or aspire to be one), keeping these three things in mind are critical to success.  Without a true focus on your company goals, traditional IT metrics and behaviors can jeopardize business objectives.  When we start to look at IT as a key component of the companies’ services or offerings; slow, fragile, and manual process starts to become even more unacceptable.  IT needs to enable the business and be able to evolve with the needs of business, and that includes all the services it supports.  IT needs to be part of the business not an anchor of technology.

 

So, you want to know a bit more about where to go?  Here's a bit of light reading to get you started –

  • Phoenix Project – The fictional story of a DevOps transformation

  • The Goal – Lays out the basics of the Theory of Constraints and how to focus on the real goal

  • Critical Chain – Applies the Theory of Constraints to project management

  • The Art of Business Value – A critical discussion of how to identify business value from an IT org

  • A Seat at the Table - How senior IT leadership can become relevant in leading the company direction

 

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading