Our modular products are always challenged to change which may jeopardize the achieved complexity reduction. We do not have a good way to make decisions on implementing new variants or qualify new market opportunities. The added cost incurred through more variants and less configurable products are hidden from us.
Secure Long Term Success
Achieving a Modular Product Architecture is a tremendous achievement of an organization. Often attained with a significant investment of time, effort, and resources. A well-defined Architecture reduces the complexity cost and boosts innovation by providing the foundation for execution and future development. However even this prized achievement, like all things is subject to entropy over a period.
So, what can cause such erosion?
Changes due to incorporation of new requirements, continuous evolution of the product. Adoption of cutting-edge technology is not only inevitable but often desired. Multiple and parallel changes, often ungoverned, over time can significantly erode the modularity, and by that scale down the impact and thus the return on investment. This is where the governance of the architecture comes in.
The question that arises, what is needed to govern a Product Architecture?
Single Source of Truth
Product Architecture is achieved from a series of contribution from several disciplines or departments across the Organization. These are to be organized into common model, product Architecture. Through the Architecture's lifecycle various data is processed, interpreted and assimilated.
When completed it is used to derive more useful implementation models. Example: Market Inputs leads to Technical Specification, which leads to Module System definition. Which are all contributing to defining the configuration logic, cost, profitability and planning.
Such a Product Architecture consists of a vast amount of discrete data elements with interconnecting relations. To be able to maintain this complex network of data, or digital weave, through its lifecycle, two capabilities are required.
- Traceability to origin: One should be able to trace back every data element to its reason for being to an external agent. i.e. We can trace modules back to module strategy and customer value, and customer value to market segments and so on.
- Sensitivity to Changes: Change to any aspect or data element in Architecture, should be reflected across the digital weave. i.e. The effects of changes in the development roadmap should be reflected in the sales roadmap.
How do you form and maintain this continuously evolving network of information where every element of the Product Architecture must be traceable, and impact of every change is managed?
Keep up with the Market
Not all changes of a Product Architecture are equal in origin and scope. The change could be originating in a peculiar customer request, or because of an updated product roadmap or even due to disruptive technology. Additionally, indirect factors such as volume or cost that may trigger a reconsideration in the Product Architecture.
The scope of the change could be from altering a product configuration, to introducing a new module variant or a need for a new module or interface. In extreme situation the decision would even be a change in the external interface or need for a new platform altogether.
In daily operations it is common that parallel change projects operate on the same Product Architecture, often managed by different teams. That stresses the need for…
Changes are isolated and interference from other teams is securely managed, and
Ensuring that changes do not create conflicts.
Completing the Digital Thread
A modern digitalized organization is likely to use multiple IT systems that manage various aspects of the Product Architecture from Design to Production to Sales. Most often connected through a series of point-to-point integrations.
Architecture governance should make sure that…
Implementation in downstream systems does not erode the Architecture, and
Changes on the Product Architecture is propagated to the downstream systems.
To secure the integrity of the Product Architecture across the organization over time, the propagation of changes across the IT landscape must be fool-proof.
Full propagation require three criteria to maintain this integrity…
An Information Model common to all IT data systems maintaining the architecture
A common element in the Information Model whose definition remains unchanged across IT systems enabling an unbroken digital thread
Unbroken flow of digital data across systems, enabling an enterprise change workflow
In a world of data flowing across multiple IT systems and many stakeholders. How to you implement a common information model and propagate an evolving Modular Architecture across the organization?