Product-oriented delivery, enabled by POD models

The next stage of evolution from agile and DevOps

Publish date:

Why POD models are the future

Traditional businesses are starting to look a lot like technology companies, with the boundaries between business and IT increasingly blurring. But many companies are still operating in the traditional model where there is a large separation between the business and IT. In today’s environment, the only way to be successful is to react with speed and agility to marketplace changes, and that’s only possible when the business and technology teams work hand in hand.

Traditionally, business and IT have been siloed, and IT teams themselves have been divided between application-development and application-maintenance teams. Enter product-oriented development, or POD. In POD-as-a-Service models, a cross-functional team of business and technology professionals work together as a single unit to handle all aspects of development and maintenance. In a POD-as-a-Service model, siloes are broken down and the team works in a “we build it, we own it” mindset. No longer is there a time-consuming handoff between individual teams, and organizations can be more agile than ever.

While product-oriented, POD-enabled development is the future, few organizations operate in this model today. Rather, they may leverage agile processes or take a DevOps approach to development. To understand the differences and why POD models are the future of application delivery, let’s explore the three key modes of application development that preceded it.

Mode 1: Pool-based development. Pools represent a legacy, app-centric approach where the business and IT are completely separate. IT operates as a pure support function, or a “pool” that supports the business team that is managing and overseeing projects. The pool leverages a waterfall or, at best, an iterative, model when delivering on business requirements, which means when one function completes a task, the next function picks it up, and so on. It’s a siloed, sequential, and slow manner of operating.

Mode 2: Factory models. The key shift in the factory model is the incorporation of agile development, where architecture, design, development, and testing are organized into coordinated sprints oriented toward a specific goal or outcome. While, in the pool model, the business drives projects forward, in the factory model the IT teams take the lead, though they still do not own the end-to-end lifecycle. Additionally, as in the pool model, there is a separation between business and IT, so teams are not necessarily business oriented and operations is still sequential and separate from other phases.

Mode 3: DevOps factory models. In the DevOps factory approach, operations teams are pulled into the development fold and work closely with the development team in an agile manner. Where operations are an afterthought in earlier models, the DevOps factory model make it a key aspect of development, with issue resolution and defect scenarios top of mind for teams at all stages. However, the business and IT teams are still separate and development teams still take an app-centric, versus a product-centric, approach.

This brings us to product-centric development enabled by POD models. In a product-centric approach, teams no longer think of themselves as developing an app but developing a product. It’s the difference between having a team focused on the SAP finance application and a team focused on the entire billing function.

A key enabler is the strong alignment between business and IT in a single team. POD teams align to a specific domain and capabilities, own the end-to-end lifecycle of a product or function thanks to cross-functional capabilities, and translate business language to powerful products that they improve rigorously.

It’s a game-changer from an agility standpoint, particularly given the current disruption. In a traditional model, development can take three months; in a POD model, it can be done in as little as three weeks.

Embracing pod-oriented development takes time, as companies create strategies to encompass operating models, roadmaps, governance structures, and business-oriented KPIs, as well as a phased approach to roll-out.

For more information on the POD-as-a-Service model, please reach out or read our point of view.

Related Posts

devops

Innovation, revolution, and your future as a leader in Business and IT

Randy Potter
Date icon March 18, 2020

How the democratization of IT is disrupting the way Business and IT work together, and why...

devops

DevOps for legacy services – it’ll never happen!

Jonathan Vince
Date icon September 26, 2019

It is not possible to run your legacy services with DevOps teams, but with a bit of care you...

devops

EvoQE (Evolution of Quality Engineering) – Next-generation quality engineering services

Vivek Jaykrishnan
Date icon September 11, 2019

With new digital era, the need for quality and agility is a top priority across all...