...
"Organizations that manage IT delivery as projects instead of products use managerial principles from two ages ago and cannot expect those approaches to be adequate for succeeding in this one. Visionary organizations are creating and managing their Value Stream Networks and product portfolios to leapfrog their competition in the Age of Software."
― Mik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework
The long tale of legacy
Naturally, large organizations that produce complex products Organizations producing long-lived consumer products, typically cars, have the most significant challenges. Under the hood of these organizations, there are many systems to a vast number of systems support the operational value streams. All tighs together in a product structure which is the backbone for making it all work in the operations. The designs have been built around working culture and the main idea of the consumer offering. After a few years in business, most organizations have a long tale of legacy systems that generally will be around for decades.
The backbone of the supporting systems is a product structure that carries information through the supply chain, production, development, finance, sales, distribution, and aftermarket. Especially companies with long-lived consumer products have a substantial legacy of supporting systems.
The most prevalent supporting system is the ERP system needed in all organizations. On top of the built-in functionality, an ERP system can have numerous system integrations and adaptions associated with internal working procedures. Maintaining, developing, and sometimes replacing an ERP system can consume a lot of effort with internal and external resources. How long time does it to adapt the ERP to a new business model in your organization?
Besides the ERP, many more systems consume resources to purchase, install, develop and maintain. The image below shows the generic Value Creation Structure of any product-developing organization. The model is a summary of Value Streams and Systems. The latter in yellow is divided in
The Product; usually is a wide range of systems facing the customer. New products are continuously presented in the competing market simultaneously as existing products must be maintained.
The internal Product Development platform is closely connected to the Product and is sometimes maintained by the same people as in the Product Development Value Stream.
Other supporting systems for development and operations construct the long tail of legacy that occasionally gets disconnected from the Product.
...
All levels of the Value Creation Structure must be considered when governing an organization that develops end-user products. The crucial connection between Product Development Value Streams and Supporting Development Value Streams is challenging to manage and often not understood.
To counter the market competition, the long tail of support systems needs to be in shape, which requires continuous upgrades. The technical perspective, such as Life Cycle Management, security, and system integration, produces specific reasons for maintaining existing systems. To change a system because of changing product offerings is much more complex and involves structures and the tacit knowledge any organization has built up.
Companies generally understand the urgency to have a structure including support systems up to speed. The big question is: "How can we know how the future support systems should work when the future product is unknown?" And they start to investigate what future infrastructure they need. Meanwhile, the market is adapting faster and faster.
Many companies do invest in transforming how their infrastructure is maintained and developed. Many success stories show how Lean, Agile, and DevOps have reduced lead time, increased quality, and other business benefits. Regardless of how well you improve system development, the tale of legacy is, in most cases, far too long to manage a Value Stream Network and achieve Business Agility.
Cadence and Sync are key to alignment
If you have been involved in an Agile transformation, you have likely seen the struggle to deliver working Features within a short period. It can be hard enough for an Agile Release Train to finalize Features within a Program Increment. But, in a sizeable Lean-Agile organization, the ability to quickly deliver working Features across several domains in multiple Release Trains is needed to accomplish Cadence and Sync.
There is always an end-to-end flow when developing a Feature. The flow starts at a trigger and ends when a value is utilized. There may be islands in the flow where mature Agile teams do an excellent job. But when teams cannot observe and influence the entire end-to-end flow, they will lose the context for their delivery and cannot learn from the market. With just local optimization, any company-wide transformation will fail.
Cadence and Sync is the way to create alignment through short feedback loops that provide the necessary learning. Without fast and frequent feedback, the dream of Business Agility flies out the window.
The following image demonstrates a mature scenario where the development of the Product, including the development platform, has reached Cadence and Sync. The Supporting Systems are still scattered in different development models and are far from reaching any Cadance and Sync.
...
You may think that the Supporting Systems is a platform with a well-defined interface that does not need to be in Sync with Product Development. Then imagine a consumer product that has:
...
retail and service shops worldwide,
...
100 variants,
...
30,000 physical parts,
...
One thousand suppliers and five factories.
...
one million lines of code in distributed in 30 embedded computers,
...
emerging digital services,
...
100 critical integrated supporting systems,
...
To exemplify, imagine a consumer business that has:
Retail and service shops worldwide
100 product variants
30,000 physical parts
One thousand suppliers and five factories worldwide
A consumer base of two million people and 300,000 organizations
100 critical integrated supporting systems, some behind the times
a Product that contains one million lines of program code distributed in 30 embedded computers
a market that expects product support for at least ten years
emerging digital services which are forecasted to be the future cash cow
a hurried need for a new subscription-based service and pricing structure
All these and much more need to be addressed when developing and maintaining the supporting systems.
The most prevalent supporting system is the ERP system needed in all organizations. On top of the built-in functionality, an ERP system can have numerous system integrations and adaptions associated with internal working procedures. Maintaining, developing, and sometimes replacing an ERP system can consume a lot of effort with internal and external resources. How long time does it to adapt the ERP to a new business model in your organization?
Besides the ERP, many more systems consume resources to purchase, install, develop and maintain. The image below shows the generic Value Creation Structure of any product-developing organization. The model is a summary of Value Streams and Systems. The latter in yellow is divided in
The Product; usually is a wide range of systems facing the customer. New products are continuously presented in the competing market simultaneously as existing products must be maintained.
The internal Product Development platform is closely connected to the Product and is sometimes maintained by the same people as in the Product Development Value Stream.
Other supporting systems for development and operations construct the long tail of legacy that occasionally gets disconnected from the Product.
...
All levels of the Value Creation Structure must be considered when governing an organization that develops end-user products. The crucial connection between Product Development Value Streams and Supporting Development Value Streams is challenging to manage and often not understood.
To counter the market competition, the long tail of support systems needs to be in shape, which requires continuous upgrades. The technical perspective, such as Life Cycle Management, security, and system integration, produces specific reasons for maintaining existing systems. To change a system because of changing product offerings is much more complex and involves structures and the tacit knowledge any organization has built up.
Companies generally understand the urgency to have a structure including support systems up to speed. The big question is: "How can we know how the future support systems should work when the future product is unknown?" And they start to investigate what future infrastructure they need. Meanwhile, the market is adapting faster and faster.
Many companies do invest in transforming how their infrastructure is maintained and developed. Many success stories show how Lean, Agile, and DevOps have reduced lead time, increased quality, and other business benefits. Regardless of how well you improve system development, the tale of legacy is, in most cases, far too long to manage a Value Stream Network and achieve Business Agility.
Cadence and Sync are key to alignment
If you have been involved in an Agile transformation, you have likely seen the struggle to deliver working Features within a short period. It can be hard enough for an Agile Release Train to finalize Features within a Program Increment. But, in a sizeable Lean-Agile organization, the ability to quickly deliver working Features across several domains in multiple Release Trains is needed to accomplish Cadence and Sync.
There is always an end-to-end flow when developing a Feature. The flow starts at a trigger and ends when a value is utilized. There may be islands in the flow where mature Agile teams do an excellent job. But when teams cannot observe and influence the entire end-to-end flow, they will lose the context for their delivery and cannot learn from the market. With just local optimization, any company-wide transformation will fail.
Cadence and Sync is the way to create alignment through short feedback loops that provide the necessary learning. Without fast and frequent feedback, the dream of Business Agility flies out the window.
The following image demonstrates a mature scenario where the development of the Product, including the development platform, has reached Cadence and Sync. Each bar represents an end-to-end development cycle that provides a feedback loop. The Supporting Systems are still scattered in different development models and are far from reaching any Cadance and Sync.
...
You may think that the Supporting Systems is a platform with a well-defined interface that does not need to be in Sync with Product Development.
Does your organization have an overview of what systems need to be developed in Cadence and Sync to benefit from full feedback in your Value Stream Network?
...
Product Modularity Theory has been around for ages, and if it's it’s done right, it is a mirror of the organizational architecture.
...
Regardless of Agile team performance, the Development Value Streams are too long and too far away from where the customer actions are.
The uncertainty of features of a system that can support the development and execution of a business with complex products is high, and no one knows how to specify the systems.
By taking a high-level view of value streams in a typical automotive business we can explore the challenges in business architecture.
...
business, we can explore the challenges in business architecture.
The human side of Modularity
The obvious fracture plane is to split the business monolith into the consumer-facing service business and the legacy component.
...
Managers want to be a part of an organization that faces a new market. Where the money is
The role is to serve, not to rule the customer-facing
...
The development of the car and the supporting systems are two separate value streams with different characteristics. Nevertheless, the Value streams are very interdependent and steered towards the same objectives.
...
In one monolith enterprise, the lead time for creating the required new structures is far too long compared to what speed of the market.
...
Modularized business models
...
The classic architectural principle of low coupling and high cohesion can be used for driving organizational design.
Conway's Conway’s law is another applicable guide for understanding how the organization and products should be set up.
...
Everyone is working closer to the end business case
Smaller "tribes" “tribes” with collaboration on the right level
...
Unfortunately, board members seldom engage in business architecture, nor do they have the expertise to model and explore alternatives. Their alternative is to expand the C-level's level’s strategic authority and reshape business structures.
...
Unfortunately, board members seldom engage in business architecture, nor do they have the expertise to model and explore alternatives. Their alternative is to expand the C-level's level’s strategic authority and reshape business structures.
...
Coaches are running around helping to coach individuals and teams and facilitate training.
Not saying it's it’s going bad. Many nice things emerge, people are happier, and organizations can measure their progress. But compared to the reachable outcomes, what we celebrate is far from….
...
We can see that when delivery gets too complex when management kids a lot of singles that things are not happening with speed in their organization. The solution is often to appoint point new managers for a certain area.
You don't don’t have to be a rocket scientist to understand that these new areas new responsibility's responsibility’s is not part of the actual flow it doesn't doesn’t delegate power nor knowledge to wear to work gets done it's it’s creating new silos.
It takes time to establish often the map of these areas he just started up time where stuff is store is but not hired but gathered <something>
...
Enterprise and business architecture frameworks offer little support for the high-level models needed. The frameworks seldom cover strategic relations and interfaces between entities within a corporate group.
An Enterprise's Enterprise’s foundational structure, Macro Structure, is the strategic prerequisite that controls the workings of an organization. Form Business Models, Value Streams, and other fundamentals needed to develop and operate a business.
...