Earlier today we were in a very heated and amazing discussion around Vendor-Lock-In, Cloud, Kubernetes, Serverless, On-Premises and so much more! You can find the lead in for that thread here. But this discussion started forking down a number of paths, and one particular path is this point, which is often taken as a business and operating model; Adopting a Cloud First and DevOps Culture will fix Shadow IT and align the Business to IT Operations. At least, that is the dream. But the reality can be a little more stark than that.
The reality in many organizations is, there’s a limitation in the ability to gain access to corporate IT owned resources, so the Business Unit or Developers would often go out to other sources outside of IT’s direct control, ala Cloud or other services and use those directly, often sidestepping IT entirely.
Our IT OWNS the Cloud-lationship though, so problem solved!
That’s certainly the story a lot of organizations will want you to believe. They setup a master Amazon account and all requests and sub-accounts will be billed and handled through sub-accounts provisioned through IAM policies. That’s the vision. But quite often the reality is, many of those end-developers STILL have private or personal AWS accounts, protected and unprotected buckets, often just throwing this onto their corporate card and doing their development that way. Why? Because they often find the provisioning process or integration process with the legacy or monolithic IT to not be much better than it had been; now it’s just “Cloudy with a chance of Compliance”.
Developers don’t buy things
Then this very poignant point of the discussion around Open Source and OSS and Steve Wilson chimed in with, “Developers don’t buy things” and I’ll be honest, that has to be one of the most poignant quotes I’ve heard in a long time. Perhaps you’re one of the developers who DOES buy things, perhaps you’ve been a developer long enough to remember having to PURCHASE your own Compiler (BorlandC, C++ Derivatives and Visual Studio here!) but the most likely truth is, you’re a consumer of resources, of services, of APIs, and you got into development because you did not want to BE responsible for the Infrastructure you consume. This is what has made Platform as a Service, Kubernetes, Containers, Amazon Fargate, Amazon Lambda, and every other Serverless solution on the market so special to you; You can focus on what you do best, Develop.
The irony of this, to my original quote at the beginning of this article, is I have seen various Development teams and Business Units continue their Shadow IT message and acquire Agile Development and Issue tracking systems like Jira out of band of the traditional IT operations cycle. Some organizations, especially those that have stemmed from a monolithic or legacy methodology are still at odds with their Business Units and the Developers. An edict or mandate for “DevOps” comes from high, but Implementation and Practice are still a far cry from perfect.
How do we solve these issues and get DevOps-adoption!
It is essential that the Business Units, the Developers, the IT Operations and Architects (and preferably Legal and Compliance if regulated) get together on a regular basis and cadence. You make sure that each aspect of the business IS in fact operating from the same playbook and run-book. Today many parts of your organization and business may rely upon unapproved, untrustworthy or uncontrolled assets. Customer Data may not be strictly controlled and opening the door to risk or liability. Some folks will do what they need to do to accomplish what they want and are satisfied with the outcome, while others will take shortcuts to get there. But if there isn’t some kind of Leadership, from within groups, from within teams, there will still be unknown unknowns living in the walls of the organization. Take the increased Work from Home stance of the past 9 months and the possibility and further risk will have multiplied 100-fold. This article is not intended to be a panacea, but rather a wakeup call, that even if you’ve adopted a fully comprehensive Agile workplace with designated SCRUM Masters or a complex yet simplified Waterfall approach… you may not know what you do not know, and that can add to the potential inefficiencies, irrespective of whether you’re using On-Premises infrastructure, an Edge approach or living fully and entirely in the Cloud.
But wait, Spoilers?
There’s an extra piece I wanted to mention that I briefly referenced in my recent article, Cloud Case Studies: When Customer Stories don’t tell the entire Story! and the point I wanted to mention is, Business Units, Developers, various project teams equally may not be going about doing things the most efficient way, the cost effective or the most successful way. This is particularly re(Mid-way through this sentence a startled cat ended up running up my head and cut just next to my eye resulting in gushing blood everywhere, so here’s hoping I’ll be able to regain the train of thought I had!) [resuming on next line]
This is particularly noticeable in the choices of the technologies that teams will often choose to employ, either for a new product, project or otherwise. With a wealth of Cloud platforms and a very heavy number of Open Source, Commercial and proprietary solutions to choose from teams are often making not the most efficient decisions, or relying upon ‘what they know’ even if it isn’t the most effective. (You ever run across production PERL code in what should be a Python environment? Is it because it was most efficient… or it’s because it’s what they knew, or knew at the time)
The lessons learned here, or effectively the spoilers to consider is; Just because you’re doing something does not mean it is right. In the same breath, it also does not mean it is wrong. It’s important to revisit, or even to visit for the first time what is being used in your platform, for Development, for the Business, and for Operations. A lot of things are still being done very manually today that can easily be automated, but that’s a story for another day!
Hopefully you found this at all helpful in the modus of understanding the Shadow IT culture mindset and how even if you think it’s gone, it may not be gone and still quite present in your operational and business culture. Thanks to the conversational contributions and engagement of Tim Crawford, Holger Mueller, Sarbjeet Johal, Rodrigo Gazzaneo, Dion Hinchcliffe, Sam Newman, Rob Hirschfeld, Corey Quinn, Jo Peterson, Keith Townsend, Yves Mulkers, Mark Thiele, Stuart Miniman, Eric Kavanaugh, Dave Vellante, John Furrier, Lydia Leong, Mark Lynd, Crawford Del Prete, Kirk Borne, Neil Cattermull, Isaac Sacolick, Neeraj Mathur, Steve Wilson, Frederik Bijlsma, and Bill Schmarzo.