Our modular products are continually challenged to change, which may jeopardize the achieved complexity reduction. We do not have a good way to implement new variants or qualify new market opportunities. The added cost incurred through more variants and less configurable products is hidden from us
Secure Long-Term Success
Achieving a Modular Product Architecture is a tremendous achievement of an organization. They are 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?
This can result from changes due to the incorporation of new requirements, continuous evolution of the product. Adoption of cutting-edge technology is not only inevitable but often desired. Over time, multiple and parallel changes, often ungoverned, can significantly erode modularity and scale down the impact and return on investment. This is where the governance of the architecture comes in.
The question that arises is, what is needed to govern a Product Architecture?
Single Source of Truth
Product Architecture is achieved from a series of contributions from several disciplines or departments across the Organization. These are to be organized into a 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 lead to Technical Specification, which leads to Module System definition, which contributes 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 maintain this complex network of data, or digital weave, through its lifecycle, two capabilities are required.
- Traceability to origin: One should 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, customer value to market segments, etc.
- 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 the 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 originate in a peculiar customer request, an updated product roadmap, or even disruptive technology. Additionally, indirect factors such as volume or cost may trigger a change 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 situations, the decision would be to change the external interface or the need for a new platform altogether.
It is common that parallel change projects operate on the same Product Architecture, often managed by different teams in daily operations. 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 in the Product Architecture are 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 foolproof.
Full propagation requires 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 do you implement a common information model and propagate an evolving Modular Architecture across the organization?