Co-authored by : Kaushik Mishra
The world is evolving rapidly, and businesses must adapt and align with the ever-changing customer demands and market trends.
Today, product and software companies are increasingly leaning toward the startup culture of avoiding heavy and time-intensive practices and instead following agile practices with an enhanced focus on the concept of a minimum viable product (MVP). However, even in the age of rapid product development, we cannot underestimate the importance of business architecture.
A business architecture (BA) helps an organization to define how the structure of the organization, technology, processes, metrics, roles and competencies, and infrastructure should be configured, structured, and integrated to bolster new business strategies with five high-level services:
- Strategy Definition
- Business Capability Definition
- Function Landscape Definition
- Process Architecture
- Organization Design and Roles Definition
It is the synergy between these five dimensions of the BA that brings the extended enterprise environment within the corporate leadership’s sphere of economic influence.
This approach is becoming more important with the move toward service-oriented architecture at the business level, often termed as the service-oriented enterprise.
A whole new approach toward BA needs to be undertaken in order to avoid the time intensiveness of the process. We must get away from the concept of all or nothing as in most of the cases, by the time the BA is fully matured the business had moved on and most of the artifacts become obsolete. It is high time that Business Architecture adopts, transforms, and aligns to the agile ways of working toward building an MVP – build a small part, release, analyze and learn, pivot if required, and repeat.
We must follow the same MVP concepts while defining Business Architecture – build only what is necessary to reduce risk, i.e., the smallest possible version of the architecture and keep developing the Business Architecture in an iterative way.
The idea is to start with a minimum viable architecture with a clear vision:
- Identify the minimum viable meta model
- Define minimum landscape for strategies
- Define the goals and KPIs for strategies in focus
- Define minimum capabilities and functions landscape
- Identify the impacted processes and organization roles
- Adapt to changing requirements and landscapes
- Make the business architecture elements measurable
- Focus on early wins
- Keep building iteratively
In our current way of defining the business architecture, defining the meta model for the organization ends up taking at least a couple of months. Organizations always take the big bang approach and create the meta model, strategize the landscape for the organization along with set goals and KPIs, and identify capabilities up to L3 or L4. This takes somewhere between six months to a year just to define the capability landscape. Once the strategy and capabilities for analysis are ready to be used, the architects face the most common problem: ‘the landscape has changed.’
If we take the minimum-viable product approach to business architecture, we can always measure and redefine the architecture elements in a sublime way. As a starting point, agile enterprises define goals and KPIs only for the strategies that need to be delivered in the next two to three process increments. Identify and define only the L1 capability landscape. The lower-level capabilities can be defined only for the impacted L1s and mapped to the focused strategies and their goals.
Similarly, the function and process landscape can be created only for the impacted capabilities and should not be done for the entire organization upfront, which would be a waste of time and effort in the long run, with the majority of the processes not being used for any analysis. In this case, the impacted roles and business units are identified only for the impacted processes.
The minimum-viable product approach will enable architects and other stakeholders to have a bird’s eye view of the strategy and goals while keeping the approach focused on lesser architecture elements. Also, any requirement that creeps into this approach can be handled easily and efficiently by identifying more impacted processes.
Moreover, this approach could be extended to the application and technology layers as well, where the elements for the minimum-viable product can be defined and analyzed.