The End of the IT Contractor Model
In many organizations, IT is the slowest to respond to changing markets. That lack of speed is seen as unavoidable due to the complexity of the industry or the level of control required by certain regulations.
In some cases, the real obstacle is the IT Contractor Model that governed the corporate landscape throughout the last decade. In this post, I’ll explain how modern DevOps practices can end that model, and hand the power of IT back to the business decision makers.
The Urban Myth of the Marketing Coup
Urban myths — mysterious cautionary tales passed from person to person — have a timeless allure. While we aren’t gathered around a campfire here, I’d like to share an urban myth with you and what CMOs and IT organizations can learn from it.
Once upon a time, the marketing department of a large financial institution asked their IT department to develop a cool mobile app. The IT department engaged with a tech consulting giant to get the job done.
Things got complicated. Between delays, overrun budgets, and quality issues, the marketing team grew restless. As time went on, and the mobile app was still not developed, the marketing department led a coup. They took half of the budgeted money and spent it by engaging a small technology company. This smaller, nimbler company built the app without any IT involvement, and it worked!
You can probably guess what happened next — disagreements and internal strife. The IT team didn’t appreciate their colleagues’ overreach, and this turned into a panic after seeing their leadership being cut.
While I can’t 100% confirm the authenticity of this story, it is one I’ve heard time and time again, in different forms with different names. Like all famous urban myths, it does resonate with our reality!
Personally, I’ve been on both sides of experiences like this one. I’ve worked for an enterprise that got “disrupted,” and I’ve also been one of the disruptors. Through these experiences, I’ve learned how businesses like Rangle can deliver business value through software. What I have learned from this myth (and my own experiences) is that IT has changed from being a slow-moving, process-driven monolith, into a nimble, delivery-focused accelerator. IT evolved from being a differentiator to being the core of the business.
The IT Contractor Model
Let’s take a look at the legacy IT project approach that got us into trouble. Unlike the semi-fictional story above, this one is all too real. Trust me, I’ve been there, more times than I care to admit.
In the past, the IT process would follow these steps:
- Sit in a big boardroom, and ask business analysts to dream up numbers of users and projected workloads. The user profiles were often based on estimates, not research.
- Big IT experts (that would be me) give largely inaccurate H/W and Software estimates loosely based on similar situations.
- The organization begins procurement for the infrastructure based on the largely inaccurate estimates.
- The team starts developing with an estimate for delivery in Q3.
- By Q2 we realize we can’t make the deadline for the given requirements, so we extend to Q2 the following year.
- The CMO refuses that deadline, so features are cut out in order to meet Q1 the following year.
- Q1 approaches and users begin testing. Many features are missing and performance issues are reported. Sorry, we’re pushed back to Q2 again!
- The production team tries frantically to get the software into the users’ hands in a secured and reliable form, without much luck. It finally goes out batched up and not very ready, but it’s out.
- The team announces the successful end of the project!
Find it hard to believe? This was typical of the majority of IT projects — and we all knew it!
By the end of the project, the leadership team has very little faith in IT, and the project team is traumatized by the experience. Now imagine that you are the CMO and you want to make a change to this app in response to market changes. You have no confidence in your IT team and would rather not deal with them at all.
That was our reality during the “IT Contractor Model” phase, an era filled with change requests, delays, and frustrations, which we endured through the past decade and was increasingly painful from the mid-2000s on.
The Emergence of XP
As early as 1999 a few renegades (Kent Beck, Martin Fowler, and others) started talking about actually communicating with the end users throughout the process. The idea of “Extreme Programming” (XP) became a grassroots movement, and developers became excited about techniques like pair programming. It was a breath of fresh air, and we started asking, “Why aren’t we all doing this?”
These techniques started taking off in the early 2000s. Their biggest benefits are in making estimates more accurate, minimizing the number of changes required, and creating software that’s closer to user expectations.
Test Driven Development & XP
Subbu Allamaraju, Chief Engineer, Cloud & Platforms at eBay, once boasted on the CloudCast podcast that they followed state-of-the-art XP and deployed site changes every 3–4 weeks. It’s a step in the right direction, but it’s still not fast enough.
The Agile Revolution
Every revolution needs a manifesto. Almost like an urban myth, the Manifesto for Agile Software development was born at a ski resort in Utah in 2001.
The call for close customer interaction means deploying software to production more often, or at the very least, deploying more frequently to the User Acceptance Testing Environment.
In 2007, when Steve Jobs decided that we all need a glass rectangle in our pockets, software and digital products became everything and everywhere. Software changed from being the thing you use at work, to the thing that runs your life. Users expect their software to be reliable, but above all, responsive. They expect change to happen to their software while they are asleep, via updates. Agile Software Development took hold of the world, along with the concepts of Continuous Integration and Continuous Deployment.
Security testing also began happening more often and earlier in the process. “Shifting left” was all the rage (i.e. all the processes that happened to the right in the below diagram, like testing and security, are now happening earlier to the left).
Cloud Native Dev-Ops
Cloud computing was the last piece of that modern software development puzzle. Cloud computing provides organizations with the ability to “elastically” expand their infrastructure to match demand. You no longer need to purchase equipment and design software to handle one high demand week every year, only to sit idle for the 51 other weeks.
Cloud computing completed the full “shuffle,” as it allows the organization to procure as much as it needs and above all to do that in a flexible and dynamic way. It enabled us to change the architecture in response to changes in our understanding of the requirements. Now all those tasks that rigidly fell to the left of the first diagram have been “shifting right.”
Today’s DevOps Revolution
Modern software development, Agile, and Cloud Native computing allows us to create IT organizations that foster innovation and respond rapidly to changes with higher reliability and quality. This shift empowers business leaders in general (our Urban-Myth CMO in particular) and gives your organization a competitive advantage. As stated in the 2017 State of DevOps report and the book Accelerate (which discusses the methodology behind the report), high-performing organizations achieve speed only by improving quality first.
The practices of delivering quality software in a reliable and responsive manner, are what we collectively call DevOps. The technical details of those practices under this umbrella are vast, but overall, DevOps practices are what allow organizations to deliver software quickly and reliably, responding to changes and self-correcting in a manner that is truly worthy of the term “Agile.”