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

Delivering faster with better use of micro-frontends in financial services

Date icon September 22, 2021

What works well is multiple SPAs owned by specific DevOps teams that can decide what happens...

agile

No one likes waiting. With Continuous Delivery, now you don’t have to!

Venky Chennapragada
Date icon March 22, 2021

Automated and on demand – here’s how, why, and when you should adopt Continuous Delivery...

devops

Arriving at the new destination

Yvette Zzauer
Date icon March 2, 2021

Each role in the organization encounters a unique set of learning needs in the DevOps...