Why DevOps is an essential ingredient of an MCoE
DevOps has become a buzz word in recent years — for good reason. In today’s world of software, being “code complete” is a temporary state. Good software is a “living” thing — and is never really done. The technology ecosystem is constantly evolving, and DevOps is the recognition that software needs continuous iterations and improvements over the course of its lifecycle.
This is especially true today in mobile — and even more so in the enterprise, where forward thinking companies are building collections of apps to help mobilize their workforce.
We write about this in our new ebook, “5 ingredients for a successful mobile center of excellence.” To be successful in mobile, the enterprise needs to build apps at scale. A key ingredient to do this: DevOps.
The old way of building apps for employees
Technology and IT teams have been overwhelmed with requests to build applications and create mobile solutions for the workforce. The old way of responding to this demand was a sequential series of steps that could take place over the course of days, weeks or months — depending upon the complexity of the project:
- Request comes in to IT.
- IT responds with project proposal and estimated cost and schedule.
- Project proposal/budget is reviewed by executive team and approved (or not).
- Team is assembled.
- Project begins, and is eventually completed.
- Ticket marked complete.
- Team is disbanded.
But what happens when users get their hands on the apps? Or when a mobile operating system gets updated, or any third-party library becomes out of date?
Budget may not exist for any updates or new feature requests. Members of the original team may have moved on to new projects. And so, a new project request is put in — which needs review. And if approved, a new team is assembled that doesn’t have the history or experience with the app. These inefficiencies cost the organization a lot of time — and potentially a lot of additional budget. And these inefficiencies have an even great cost: fewer resources to build other solutions.
The result: Projects are neglected, users get frustrated, and employee productivity and job satisfaction declines.
Mobile DevOps in practice
When I joined oil and energy pioneer Schlumberger in 2014, my job was to establish a mobile center of excellence (MCoE). That meant building the internal capability — including the team and processes — to build a suite of applications that could help mobilize Schlumberger’s 100,000+ employees. A key piece of this was instilling a DevOps approach to development — not just for the new MCoE, but for the company as a whole.
The company’s legacy business systems software was in more of a sustaining mode — meaning just keep it running and secure. There were some, but limited active development or new features being implemented. It seemed that once applications were put into production, the development team was disbanded and the application became static. It was a traditional waterfall approach.
In DevOps, software releases are regularly deployed and work to regularly optimize and test past releases continues over the lifetime of an application. SOURCE: analyze.co.ca
Through a lot of early internal evangelism and an IT sponsored R&D budget, we built a team of 75 mobile designers, engineers, and testers. At any given time, we would have 12–15 applications that were actively being used, and would create up to 12 new apps over the course of a year all while still actively engaged with all prior app projects through our DevOps practices.
The most crucial piece of our DevOps approach was an agile process that was applied across projects, and the cross-functional squads responsible for building and managing the applications. Each squad would become the experts for a given app, understanding the problem it was solving and how it would be used — and ultimately owning the user experience and code base over the lifecycle of the application.
Owning the whole lifecycle meant much more than simply sustaining the app. We often found that a first version of app would get into the hands of users and almost immediately spur new feature ideas.
We were getting incredible engagement and feedback from our users — and because we had a DevOps process in place, we were able to efficiently take new feature ideas and put them on a roadmap. Without DevOps, apps are effectively dead once they get published. They don’t get those updates users want and ultimately they don’t get used.
DevOps modernized our internal software development approach and allowed us to build confidence with the business owners and users. They trusted our process and knew the app was a living, breathing entity that we cared for with enhancements, fixes and user support.
DevOps FTW
A recent study by Puppet revealed that high performing organizations that apply DevOps principles achieve 46x more frequent software deployments than their competitors, and higher levels of customer satisfaction and operational efficiency.
And if your organization is going to be successful in mobile, there’s little doubt you’ll need a DevOps approach to development.
If you’re interested in learning more about how to build apps at scale, please download our free new ebook — and let us know what you think. If you’d like help with your mobile challenges, we’re always happy to offer up some advice. Contact us to set up a time to talk — no strings attached.
Written by ArcTouch EVP of Enterprise Mobility, Chris Reichard. Originally published at arctouch.com.
