Organizational Benefits of Aligning Business Analysis with Business Architecture
Haldun Cor, Business Architect/Analyst for Financial Industry
Srinivas Sundaragopal, Business Analyst, Requirements Inc.
As Information Technology is maturing within Enterprises and IT costs are soaring, a demand to produce an Enterprise Business Architecture to drive smart decisions about Technology Roadmaps is apparent.
Business Architecture is simply the formulation of business vision and strategy into an artifact that captures key capabilities and requirements at a high level. It is a forward looking, social and living artifact. However, once business architecture is laid out, there is a common and growing challenge in the industry about how to realize the full benefits out of business architecture. Business analysts can tremendously contribute execution of business architecture. We find the dynamics of business architecture and business analysis very interesting and take a closer look at the effective collaboration between Business Architecture and Business Analysis teams to positively affect the outcomes.
We investigate the dynamics of Business Architecture and Business Analysis in order to align Requirements Elicitation and Requirements Analysis areas with Enterprise Vision.
Where do we miss the big picture?
Organizations are tasked with addressing imminent business needs and the energy is focused on aggressively resolving the problem at hand. Delivery constraints force business analysts to dive into the solution space without much opportunity for enterprise planning with a focus on future reusability and extension. Organizations end up with redundant solutions without harvesting the benefits of extending an existing solution.
What can be done?
Business Architecture may provide a couple of benefits at this juncture. First, a quick validation against Business Architecture whether the same or similar capability has not been already addressed or offered elsewhere within the organization—this may eliminate any duplication of efforts. Business Architecture usually encompasses multiple domains at times (by ignoring any organizational view and sticking to a functional view) and covers the whole enterprise. Therefore, Business Architecture artifacts could support business analysis in exploring any functional duplicity.
Second, even if a similar existing solution did not exist elsewhere, there would be opportunity to leverage any overlapping functional areas with other business areas. These overlapping functional areas may be pertinent to enterprise-wide requirements (i.e. regulatory and control related requirements) or it may even be common functional requirements. For example, Regulatory and Control related requirements usually apply enterprise-wide and can be common to all business analysis. Business Architecture captures these common requirements into a reusable modular format and makes these available for use across the enterprise. Therefore, these patterns will be ready for business analysts to implement them into the detailed requirements.
Enterprise analysis, as an entry point to Business Analysis serves as the input business case, but does not strongly clarify organization-wide requirements such as audit, compliance, controls and metrics, nor does it embrace best practices that can be leveraged. The missing piece in the business architecture seems to be recognition of “extensible patterns” that comingle process and rules that are critical from an operational standpoint. The involvement of analysts in this quest for “patterns” instills the importance at an early stage and provides for traceability and opportunities for reuse in the detailed requirements. Analysts’ involvement in architecture “patterns” will allow organizations to proliferate and install the architectural rules across the varied systems. Architects can reap the benefit from the analysts’ insights from the eye to details while building enterprise systems.
Now or Never?
The question is “When do we invest the resources towards a future vision—now or later?” Usually organizations take the easy route and go with “Later”. This is perhaps due to the nature of the process. Future-proofing projects needs to be engrained in the formulation of strategy—we believe that an organizational change towards a stronger intersection between Architecture and Analysis disciplines can achieve this.
Nice post. Cheers for making this.