The software development lifecycle reminds me of the proverb of the three blind people confronting an elephant. One grabs the trunk and says it’s a snake, another touches a tusk and says it’s a spear, while the third feels its side and calls it a wall. The moral of the proverb is that perception has a lot to do with perspective.
For a long time, the perspective on software was that it was a cost. It was a necessary cost for sure, but other considerations — like how users experience it and how employees work with it, as determined by its quality — were secondary. That perception was handed down pretty much intact from the mainframe days, and as long as cloud computing and subscription services didn’t exist, it was good enough.
When cloud computing and subscriptions became mainstream, the definitions of “profit” and “return on investment” also changed. Profit shrank on a per-transaction basis, though vendors knew they had to excel at small interactions to keep customers coming back.
ROI was once a one-and-done phenomenon in which a new system paid for itself through cost savings that eliminated some labor from business processes through automation that let customers self-serve. Today ROI has changed, because the return on a software investment is much less about automating to save money and much more about using software-driven business processes to capture opportunities that pop up in the business world.
Calculating the return is much more about time to market or time to value than ever. With that change, business not only needs to speed delivery of software but also, importantly, deliver software that works, is error-free, and gets a vendor there first to capture those ephemeral opportunities.
It’s the old better-faster-cheaper conundrum, but it’s no longer acceptable to get two out of three. We’re playing for all of the marbles here.
Into this milieu we’ve launched numerous intellectual tools and a few of the software variety. The brain tools go by names like “Agile,” “Scrum,” “Lean” and more. The software tools are code generators, clicks instead of code development, and embedded functions like analytics, workflow, security, and integration services that the code generators weave together into a working application. Significantly, all of this lives on the modern software platform.
In my humble opinion, I don’t see how you can operate a modern application development shop without a platform. Many vendors, if not most, offer a platform or platform-like environment and a new approach to development, called “DevOps,” has been percolating in the information technology space.
Executives who want to understand more about yet another thing that has landed on their plates can get a thorough grounding in DevOps from a recent report published by Harvard Business Review by Melody Meckfessel, VP of engineering at Google Cloud.
A successful DevOps rollout in your organization will require some executive involvement, because at its heart it is a culture change moving from silos to collaboration, transparency and sharing. Check out Meckfessel’s article for more.
Key Values of DevOps
Unlike the values of earlier programming paradigms, like lowering costs, a DevOps strategy orients toward time to value. I’ve been researching the topic over the summer and will have a detailed report soon, but for now let it suffice to say that a well-articulated DevOps strategy can lower costs significantly while empowering employees to take reasonable chances when conceiving and delivering their work products.
Most importantly for the business, DevOps, along with a software development platform that generates running code, is essential to any attempt at digital disruption. Gathering customer data and analyzing it will generate useful information, but a major part of the information needs to be incorporated into the software that supports new or enhanced business processes.
So, I like to suggest an equivalence that says: Software flexibility drives business agility, which drives profits in the modern enterprise.
What drives software flexibility? The close-in answer is the platform, but the less obvious companion is DevOps. Eighty-six percent of those surveyed for the Harvard Business Review Analytic Services report mentioned above, said that it was important for their company to develop and put new software into production quickly. It goes without saying that the code has to work and be error free, and that’s where platform is needed.
It’s Not Too Late
If you’re feeling left out because your business is struggling with building and delivering software quickly, don’t. Only 10 percent of the HBR survey respondents said their company was very successful at rapid development and deployment. There’s a vast middle of respondents — 61 percent — who reported being neutral or somewhat successful at rapid deployment and implementation.
There’s more to this, though. How do we determine what’s fast and what’s just average practice? Leaders just getting into modern platform-based CRM think that rapid change is something that’s done as many as four times per year, earlier data from my research suggests. However, people who are in the middle of the transformation are shooting for being able to change their applications’ behavior nearly continuously, deploying weekly or faster.
My Two Bits
Clearly, such rapid iteration needs both tools and approaches, and that’s why DevOps is becoming such a big deal. Your approach to DevOps will be significantly different if you’re using a platform.
For instance, issues surrounding operating systems and databases can evaporate if your platform deals with those issues, thus enabling you to encounter DevOps at a higher level from the outset.
From there on, DevOps is largely about supporting people, encouraging sharing and transparency, and involving users. It’s an important part of your future, especially if you’re trying to figure out if the rest of your business is successful — more so if you’re looking for ways to improve.