Gary King, former CIO of T-Mobile, didn't call it BizDevOps when he started making operations, developers and business...
people sit together, create plans and track performance data in 2013. And three years later, he still wasn't calling it BizDevOps when he left T-Mobile. But with subscriber totals doubled during that period and product changes made in real time, he did call it success.
And no matter what you call it -- DevOps 2.0, BizDevOps or digital transformation -- another change in the way software is developed is right around the corner.
Getting to customer needs quicker
Already in use by some of the biggest names around -- Amazon, Google and Facebook -- BizDevOps promises to build on the collaboration Agile started, application performance monitoring and digital performance monitoring technologies that enable test-driven development, and the need for speed that came out of DevOps. And at its heart, it is exactly what was happening during T-Mobile's turnaround: all three groups working together from the beginning to rapidly create and fine-tune a product that customers actually want. Like DevOps, it breaks down the silos, but this time, that includes the business silo as well.
BizDevOps seems like a no-brainer. After all, isn't business already in charge of development? Yes, but not in the ways that are going to ensure software development and deployment are completely aligned with the business priorities.
"This is a way to shorten the distance between what a customer asks for and what a customer gets," said Chris Baynham-Hughes, head of DevOps at Atos SE, an IT service management company based in France.
That's exactly what Hannover Re, the world's third-largest reinsurance company based in Hannover, Germany, was trying to do with its first BizDevOps effort. The company needed to find a way to update customer-facing underwriter software tools quickly, but the sophisticated nature of the content made it difficult for developers to do on their own. The solution was to put an IT team of developers and operations people inside the underwriting group.
"The new approach worked very well and resulted in an improved communication with the colleagues from the market departments," said Felix Hemstedt, a senior consultant with Hannover Re's facultative division. "Hannover Re is now able to react much quicker by avoiding long administration processes and coordination with other departments."
A good, yet sticky, change
For developers -- used to being in demand and, to some degree, in control -- a BizDevOps effort is going to mean some big changes. Those adjustments start with what it means to do the job.
"They've got to stop assuming their job is to just sit there and write code," said Leon Fayer, vice president at OmniTI in Fulton, Md., which provides web scalability and application services. Instead, "my job here is how do I make the business better and how do I make the company better?"
Andreas Grabnerdeveloper advocate at Dynatrace
Thanks to increasingly comprehensive application or digital performance management and monitoring tools, more data and metrics are available than ever before. The tricky challenge of BizDevOps is to ensure that information is shared equally with everyone -- particularly developers -- so customer-first decisions are made.
This could spell the end of writing beautiful code for its own sake or buying a tool because of the wow factor. Developers in a BizDevOps world will have clearer priorities, greater chances to experiment and more help than they could imagine in prioritizing the backlog. They'll be responsible for the code all the way through delivery, which may mean learning new skills, like release automation.
But there are downsides: Low code/no code, automation and, eventually, artificial intelligence may chip away at some of the development role; innovation could be a bit squelched; and dev tech chops might be less important than strong soft skills or hybrid business and tech experience. The bottom line: A rock-star developer may not feel quite so at home.
"You can still focus on writing code, but put the customer first," said Stephen Elliot, vice president of research and DevOps at IT market research firm IDC. "You are a developer, so you need to know who you are writing the code for. How much information do you have about that customer? Do they like the existing end product? If you have a mature product and you're dealing with a feature backlog, what should be prioritized?"
For a lot of developers, this level of information and communication may be a welcome improvement, said Robert Stroud, principal analyst at Forrester Research. "I really think this is going to allow developers to be more productive, because they'll be focusing on the things that matter to the business," Stroud said. "On the plus side, they're going to have better requirements changes more often, and if routine things are taken away by automation, they'll be able to focus on more meaty and innovative things."
Developers 'to have more say'
For developers who want to experiment, BizDevOps could be a dream come true, said Andreas Grabner, developer advocate at Dynatrace LLC, an application performance monitoring company based in Waltham, Mass.
"They're not going to have to build software based on specs that are shoved down their throats," he explained. "They'll sit down with their peers, come up with a thesis of what they need to build and because they can push code fast through the pipeline, they can immediately test and figure out if their thesis is right. Developers as part of a big team, including biz, dev and ops, are going to have more to say and actually be able to prove if ideas are good or bad."
But, of course, there is that, "we're ceding even more control to business than ever before," Forrester's Stroud said. "And that's not going to be an easy thing to get past."
For Fayer, that attitude is completely self-defeating. To underscore his point, he told this story: While visiting a customer, he heard the director of finance was frustrated that he couldn't get needed reports and that the tech team was too busy fixing user-complaint issues to help. Complaining users, of course, have always been the most important problem to fix. But then, someone pointed out that if finance couldn't get its reports, no one was getting a paycheck, and the light bulb went on. "This is the big takeaway: My job description is to enable business to succeed."
Build a stable DevOps team
The best way to get a smoking fast CI/CD process
A primer on continuous development
Here is what's going on with BizDevOps