In conversations with vendors or with attendees at technology conferences, you often hear discussions about DevOps. Companies will tell you how they are embracing this cutting edge trend and making it possible for developers and operations staff at businesses to work together.
That’s all fine and good but, really, the sun has set on DevOps as a cutting edge trend. The businesses that I talk to on a regular basis are currently looking for collaboration and information that extends well beyond just the developers and the Ops team. They need everyone who has a stake in critical business applications and services to be able to work together and share information in order to ensure that apps run well and end-users are satisfied. In fact, let’s call this new trend DevNetBizOps!
Ok, I’m kidding. I never really liked DevOps as a term and DevNetBizOps is way worse. (Seriously, don’t start adopting this as a real term). But the idea behind it is valid.
Not that long ago, the common development and deployment cycle for an application went something like this. The business side would define specs for an application and have a few meetings and conversations with developers to set the project parameter. Then, the developers would go away and do their thing, building what they saw as a finished app that met what they thought the requirements were. They would then take this code and basically throw it over a wall to the Ops people. Operations would try to figure out what was needed from a server and resource perspective and build a platform that would, hopefully, run the application. The network team? Well, they were basically on their own to figure out if this new application would have any impact on network resources or if it needed special bandwidth considerations. And then the business team would have to take whatever it was they got in the end and be happy with it because, at that point, any real changes would be impossible.
As you can see, not really the best process for building a business critical application. Not only are the initial processes broken, but there is almost no conversation between stakeholders and very limited capabilities to understand application performance and usage after the fact.
The DevOps model addressed the first two barriers but still left the network team and, most importantly, the business side out in the cold. And the business side needs the most inclusion. In the end, it’s their app, they are the ones who requested it and they are the ones who will use it.
In the model that the most effective organizations use, all stakeholders are included, not just from day one but even after application deployment. Business users have access to monitoring and analytics tools that they can use and understand, and that provide the real-time and actionable information that they need to get their job done. And rather than simply throwing problems over walls, the developers, operations and network teams can work together and share information that each group understands, in order to ensure that applications are optimized and running well.
This not only makes sense from a business perspective, it actually fits with the way that IT happens in business today. There are few organizations out there that can afford to have large teams of specialists. In the leaner and more efficient IT operations of today, workers may have to wear many hats. Processes and products that make it possible to integrate and collaborate between all stakeholders also enable these workers to more easily move out of their comfort zones.
So goodbye DevOps. You had your time but the needs of business have grown. And the beauty of DevNetBizOps is that it can keep growing. Decide that marketing needs to have a seat at the table too? Hello DevNetBizMarOps! (No, seriously, don’t use any of these terms.)
This post originally published on Wired’s Innovation Insights blog.