IT Automation is Strategic
What if I told you that “mainframes host more transactions daily than Google (1.3 million/second on CICS vs.68,542/second on Google), including 55 percent of all enterprise transactions.” (Forbes)
Would you be shocked? You shouldn’t. While hyperscale companies like Facebook, Netflix, and Google usually take the main stage when we talk about digital transformation and the app economy, the reality is that the app economy relies just as much (perhaps more) on the thousands upon thousands of applications no one ever sees or hears about. It isn’t just mainframes that are left unnoticed. It’s also the application services, the infrastructure, the middleware, and data sources cleverly hidden beneath the shiny interface of the latest app or device.
You see, digital transformation is more about how we interface with technology than some sparkling transformation of the technology itself. There is nothing new about APIs, or sensors and devices. There’s nothing particularly amazing about touch screens and voice control. All this technology has been around in one form or another for quite some time. And in some cases, it really is just lipstick on a pig.
You can’t scale without a load balancing service. You can’t protect apps without security application services. You can’t connect apps without middleware and APIs. And none of them are very interesting without the data they manage.
The app economy relies more on what we don’t see than what we do. And that makes it imperative that IT has a seat – and a voice – at the digital table. That seat is important whether apps are being deployed in a public cloud or on-premises in a private cloud. That seat is important whether apps are still monolithic or containerized microservices. That seat is important. Period.
That seat is representative of the collaboration and cultural changes necessary to transform IT from a supporting role to that of a strategic one.
The Strategic Nature of IT Automation
One of the more strategic decisions a CIO can make today centers on automation. With 55% of organizations employing automation as a result of digital transformation, its strategic impact cannot be overlooked. Just as the choice of programming languages and platforms for app development is strategic, so too are the toolsets, languages, and platforms being selected to underpin automation efforts.
It would be folly to dismiss these decisions as unimportant. Technical and architectural debt mount quickly, and are as stubborn to shed from the budget as the pounds we put on at Thanksgiving. Architectural debt is based on the principle of “technical debt” in software development. It is a metaphor: Complexity and architectural choices prevent you from getting new work done because you are spending all your time dealing with existing systems (break/fix, maintenance, etc…) If you have a lot of debt, it prevents you from using your money on other things, because you spend it all on interest. This debt is what drives up the costs of new services and drags down the service velocity necessary to take advantage of opportunities to improve the bottom line, whether measured in productivity or profit.
That’s what makes IT automation a strategic investment. In the enterprise, the choices you make now regarding implementation of automation will resound as loudly as those made in app dev years ago.
For example, in our survey last year self-service enablement was cited by 65% of DevOps as influencing their decision to ‘go around’ IT and seek out cloud or open source solutions. Avoiding IT means circumventing security, which puts the business and other systems at risk.
Choosing the wrong language can create its own debt because over time you’re unable to sustain systems without the right talent. Not choosing a language can cause chaos and turns automation scripts and systems into pets that need constant care and attention. That shifts budget back toward break/fix and maintenance rather than on innovation.
IT automation is a strategic effort that should be approached with careful consideration to factors similar to that of enterprise application architectures:
- Support across the entire toolchain
Just about every IT vendor today supports automation and integration with other players in the production pipeline. Support – traditional or community based – is a must given the complexity of today’s networks and the variety of vendors who make up the pipeline. Documentation, code samples, and an active community go a long way. - Talent and/or training availability
If you can’t train your staff or hire talent to work with the platforms, systems, and languages you want to move forward with, go back to step one and start the selection process again. Without the ability to sustain the systems you’re going to be building, you’re better off staying manual until you can. - Multi-cloud readiness
Support for multi-cloud businesses is a relative new requirement, but it is a requirement. Automation is not going to be confined to an on-premises datacenter. Automation efforts will need to include at least a public cloud and almost certainly more than one public cloud. That means careful consideration of platform compatibility and policy portability across environments as part of your automation initiative. - Imperative or declarative
I know you’re probably sick of hearing about this one, but the choice is pretty darned important. Imperative (pure API-based) methods are faster to develop and require less adaption by IT but incur a significant technical debt by tying automation to specific devices and vendors. Declarative (artifact-based) methods may take more time – and architecture - up front but alleviate tight-coupling of process with products and reduce technical debt.
IT automation is one of the most strategic technology decisions a CIO can make. And given that most of the app economy relies on systems under the purview of IT, it’s also one of the most strategic business decisions a CIO can make today.
Choose wisely.