Product Management

Just like products across different industries are not the same, similarly software products are not the same either. While I used to understand that difference, but perhaps did not appreciate how different they can be and how they should be classified and treated differently.

Recently I came across Gartner’s PACE layered application strategy giving a new perspective which can be very helpful for managing multiple products or programs.

Premise of the strategy

It was realised that certain applications don’t change a lot and need to be more cost effective and stable than efficient, while others had to be delivered very quickly and change frequently. Both require different processes and should focus on different goals. A mobile app compared to a mainframe application are not the same. Clearly both serve very different markets and have unique requirements, hence no single strategy can be used for both.

In 2010 Gartner introduced a concept where different applications in an organization can be delivered at a different ‘pace’, meaning some would have shorter release cycles and are more flexible, while other applications would be slower and more robust in delivery.

Understanding which applications need rapid delivery and change and where this is not a requirement is important. Also applications under these categories should not be organized around each other since the required results are different.

Pace Layers

From rapid deployment and flexibility to slow releases and stabile products, there are three layers defined with unique characteristics providing the needed support to one another.

Systems of Records

Established applications which might be legacy or core systems supporting or managing critical master data would come under this heading. Changes are less frequent and slow, can be due to well-established processes or regulatory requirements. These applications would have the longest time span, around 10 years.

For these large and very formally designed applications the processes might tend to be more water-fall or incremental development like. Funding would come from capital investments with annual budgeting, since the changes are important, few and less frequent.

System of Differentiation

Applications that support the organization’s unique processes or capabilities which differentiate it from rest of the market. While these applications have a medium life cycle, the change required is frequent to calibrate according to changing business environment.

These applications might embody more modern design practices like SOA or cloud based, perhaps composite with old custom applications. Processes here might again fall more under Incremental development and somewhat waterfall with some agile and lean principles incorporated. Budgets might be a mix of capital and operational expenses since iterations are relatively faster and more frequent.

System of Innovation

Developing new ideas and quickly validating those proof of concepts requires very different processes. These applications, revolving around ‘new innovations’ come under system of innovations, characterized by very short life spans and flexible / ad hoc processes.

Agile and lean practices would be more applicable here with latest technology stacks and architecture trends for these lightweight applications mostly serving end consumers. Budgets would come from innovation funds or departmental budgets, since these are supposed to be very frequent releases and in some cases throw away features.

After we have established the products falling under all three categories are different in the required culture, development methods and skills between them; the question is how do we organize these systems and build some coherence and synergies to manage them in a holistic fashion?

Pace layers are focused on business processes, not any particular business organizational model. So there can be many ways in which the organization can be setup, Gartner suggests to use the Hub and Spoke’ model

Hub and Spoke model

Hub-and-spoke model is common in a lot of other industries like transportation. Essentially the ‘hub’ holds a central position serving ‘spokes’ originating from a hub.

Let’s take an airline’s example wanting to support 10 destinations, with a hub and spoke model you need only n-1 = 9 routes to serve all 10 destinations. In contrast, a point-to-point system would need 10 * 9 = 90 routes!

What would this mean for managing software teams? The central team (hub) would focus on common applications that might be shared among different business groups. Applications having common governance, planning and management functions would be ideal. From the pace layered architecture, the ‘system of records’ would comprise of the hub.

The idea is to preserve coherence between layers, at the same time provide enough distance for the different record structures to work in their own cultures and operate independently.

The Hub

Applications typically having a predictable pace of change, where cost optimization or efficiency is more focused on instead of quicker and costlier solutions. Therefore the changes are predictable and long-term.

The hub does not govern any of the spokes in any way, rather it acts as a supporting function, a common platform which the spokes can use. The layers since should operate with very different goals, cannot report into one another rather would have separate reporting lines.

Systems of Innovation and Differentiation

The applications would be fundamentally different focusing more on flexibility and speed instead of predictability and control.

Differentiation layer applications, in many cases, might be a part of a larger system of records and therefore would require integrity between these two layers to work correctly as a whole.

Innovations are more around future concepts and developing POCs, therefore they can be an entirely separate group within the organization or even with a team outside the IT setup. The key here would be to deliver at pace and closeness to business for catching on changing / new ideas.

Conclusion

A common mistake large organizations have is to use a single silver bullet process institutionalized across all products. Understanding not all software applications have the same business objectives, in turn meaning one process cannot be the best fit for all. Speed and predictability are two main differentials which fundamentally change how processes should be designed for these products and achieve the varying goals for these products.

Products across the Pace layered applications architecture will have very different cultures and operating models and should therefore have independent reporting lines to the business. However, some synergies will exist, by the hub exposing some common platforms which can be consumed by differentiation and innovation products.

While Pace does not deal with what ‘kind’ of development process to follow, it provides a very good framework for program management looking after multiple product groups. This in turn allows development process diversity across products to use what is the best fit process for achieving the product’s business goals instead of imposing a single ‘best practice’ on all.

References

https://www.gartner.com/doc/3872164/governance-change-management-pacelayered-application

https://www.gartner.com/doc/1635516/gartners-pacelayered-application-strategy-governance

https://cio-wiki.org/?page=gartners-pace-layered-application-strategy