As a business architecture practitioner, I have had the opportunity to work alongside seasoned and strategic business analysts in many different engagements. This has helped me to better understand not only the similarities and differences of business architecture and business analysis, but also how we can leverage the synergy between these two disciplines in real-life scenarios.
Decoding Business Architecture
Business architecture transcends the traditional boundaries of process improvement by providing a holistic view of an organization. It focuses on creating a comprehensive framework that aligns business strategy with execution—defining how different components of the business, such as processes, capabilities, information, and technology are interrelated and ensuring that every element of the enterprise operates in harmony to achieve overarching goals and objectives.
Extending beyond individual projects to envisioning the organization as a cohesive entity, business architecture encompasses key components such as strategy, processes, capabilities, and organizational structure, offering a macro-level perspective that guides effective decision-making and transformational initiatives.
Understanding Business Analysis
At its core, business analysis is the art of comprehending an organization's needs, identifying opportunities for improvement, and devising solutions to enhance business processes and systems. Business analysis involves analyzing processes, gathering requirements, and facilitating communication between stakeholders to ensure that business objectives are met efficiently and effectively.
From a business architect's perspective, business analysis serves as the bedrock for creating a blueprint of the organization's operations. It involves a meticulous examination of processes, data, and systems, laying the groundwork for informed decision-making in the architecture work.
Synergy in Action
While business analysis and business architecture may seem distinct, the true power lies in their seamless integration. Business analysts provide critical data and insights during the analysis phase, acting as the eyes and ears of the organization. These insights then become the building blocks for business architects, who weave them into a comprehensive architectural framework.
The synergy between business analysis and business architecture becomes particularly evident when crafting transformative strategies. The insights derived from business analysis inform the development of strategic initiatives within the broader architectural context, ensuring that every change aligns with the organization's overarching goals and business objectives.
Below is a real-life case study of a large multi-year business transformation that I was involved in and worked closely with business analysts. This is a great example of how we can align and leverage the synergy between business architecture and business analysis in practice, supporting requirements management, process management, and case management works.
Frame of Reference for Requirements Management
One of the main challenges in large transformations is how to define, organize, and trace, in some cases 100's of, requirements across all the projects in the scope of the transformation journey. The diagram below is a typical path to "connect the dots" from the business strategy all the way to the solution:
The first step from business architecture perspective is to translate the strategy and business objectives (WHY) into WHAT needs to be transformed.
As the diagram above indicates, we typically start with identifying the value streams and stages based on the business objectives. Since one of the goals in this transformation was to streamline claims processing across all lines of business, we identified "Settle Claim" as one of the main value streams targeted in the transformation:
Once we identified this value stream, we then mapped the enabling business capabilities to each of the value stream stages. Below is a cross-mapping of just a few of these capabilities to the first value stream stage, "Intake Claim":
Once we identified and cross-mapped all the enabling capabilities to value stream stages, we then set up a series of review workshops with the subject matter experts (SME's) to assess the current state of these capabilities. At the same time, we also asked the SME's to identify the future vision of these capabilities based on the strategic objectives at the end of this transformation journey.
The result of these workshops was a fully heat-mapped set of capabilities, similar to the ones below, which then helped to identify the gaps, which in turn, helped to identify the required actions to address these gaps:
Ideally, business architecture goes through these assessments and identifies the gaps between the current state and future vision of the capabilities. We would then identify the actions required to address these gaps and shift the business from the current state to the future vision of the transformation.
Requirements are simply these set of actions to address the gaps in the business capabilities, as shown in the diagram below.
With this built-in traceability approach, we methodically build and ensure the alignment of requirements to the business strategy and objectives, ultimately ensuring better results of initiatives. We call this a proactive engagement, the far right approach in the diagram below:
In this specific case study (and in cases where business architecture is not fully developed or not leveraged upfront) we had to work in parallel with business analysts. That means that while we were working on these set of assessments, business analysts across the dozen projects in the scope of this transformation were working on requirements gathering (Active engagement in the above diagram).
To ensure the strategic alignment of the requirements work then, we set up a half-day workshop with the SME's and mapped the capabilities to the requirements under each project. This resulted in an artifact that we called Requirements Traceability Matrix. Below is a sample view of the matrix:
We then used this matrix to ensure that the requirements are fully aligned with the strategy and identify potential misalignments. Few items that were noted are highlighted below:
"Claim Data Verification" capability was identified in the scope of the transformation with "Suboptimal" as the current state and "Working Well" as the future vision, meaning that there needs to be requirements to address this gap. However, as the matrix indicates, there is no requirements that is mapped to this "orphan" capability. This helped the business analysis team to identify and add the missing requirement(s).
"Claim Limit Verification" capability is enabled by multiple requirements from different projects. This could be by design, however, it might indicate an opportunity to streamline the projects' scopes by descoping the capability from project 1 and scope it into project 2, where most of the requirements are defined. This would also prevent any overlaps in the investments made across these projects. Even if this is by design, it is important to capture these and be aware of the fact that there is a relationship or perhaps dependency across these two projects.
Finally, the third observation is Requirement 2.3 that does not map to any business capabilities. This indicates a need that was identified by the business, but there is no traceability back to the capabilities, and in turn, strategic objectives. Identifying these "orphan" requirements help to either remove them from the project, or perhaps find out if there is a capability that needs to be included in the scope of this project corresponding to the requirement.
Therefore, we can leverage business architecture as a frame of reference to:
provide a top-down systematic approach for requirements management, and
scope, organize, define, prioritize, and trace requirements.
Just a side note that there is still value in the reactive engagement. Although we are not actively aligning requirements with capability gaps or proactively deriving requirements definition, as we map the requirements back to the impacted capabilities in a reactive way, we would potentially identify misalignments. Depending on how the in-flight projects are governed, we could provide that insight back to the project team, which could initiate any course corrections needed through the execution journey.
Frame of Reference for Process Management
Since one of the goals of this transformation was to streamline claims processing across all lines of business, our team of business analysts were also documenting and reviewing relevant processes across different lines of business. This process work was also framed using the value streams. Below is the sample view of the processes mapped to the "Settle Claim" value stream and its stages:
When we leverage value streams (and specifically value stream stages) as a frame of reference for process management, we can easily identify where processes fit into the bigger picture of the operations. This, in turn, helps us to identify potential opportunities to address process redundancies or overlaps. At the minimum, we can identify how processes are interrelated or have dependencies across the process ecosystem.
As the above diagram illustrates, lines of business A and B use very different processes to manage claims. This could be by design due to the nature of the claims, but it could also highlight the silo views of the business and lack of alignment across these lines of business. Notice that there is only one value stream composed of 4 stages to settle claim across the whole organization. However, there could be many different processes that enable these stages depending on business units or lines of business (claim types).
Furthermore, when we look at the value streams/capabilities cross-mapping and identify a gap in a capability as a result of low performing processes, we can quickly identify which processes need to be considered for review, redesign, or possible reengineering. The other benefit of mapping value stream stages is that we can identify if a process needs to be eliminated altogether before spending time and resources improving the process.
Therefore, we can leverage business architecture as a frame of reference to:
provide a top-down systematic approach for process management, and
scope, organize, and improve business processes.
As a result of these assessments, we even identified an opportunity to merge multiple teams across different business units to further streamline our claims processing for our customers; ultimately, improving and enhancing our customer experience.
Frame of Reference for Case Management
Finally, another benefit of aligning business architecture and business analysis is to provide a high level view of case management flows and events as an input into detailed workflow design. Below is a sample view of how we leveraged "Settle Claim" value stream as a frame to illustrate stakeholder interactions for our claims processing operations.
Doing this type of interactions mapping based on different business events under each value stream stage using business architecture will provide a frame of reference for case management design, which is orchestrated by business analysis.
In summary
While business architecture and business analysis both contribute to improving organizational performance, business architecture focuses on the overall structure and design of the organization, while business analysis is more project-focused, dealing with specific business needs and solutions.
However, in the dynamic world of business, the collaboration between business analysis and business architecture emerges as a vital force driving organizational success. By recognizing the unique contributions of each and fostering a collaborative environment, organizations can navigate complexity, drive innovation, and chart a course towards sustained success in an ever-evolving business landscape.
Finally, check out our masterclass course that looks deeper into how business architecture aligns with business analysis across requirements management, process management, and case management scenarios.