So far, we have discussed
- the difference between change and transformation, and how to approach a build vs. buy paradigm
- how a maturity model can guide and visualize an organization’s transformation journey
- how business architecture is the first step to declutter the messy middle.
In this post, we will dive deeper into business architecture and emphasize its connectivity with enterprise architecture. Our goal is to provide you with the tactical information required to execute business architecture for delivering your digital experiences.
Business architecture is often thought of as a progression of traditional business analysis and requirement gathering – but it is not. Significant changes are required in the mindset, tools, framework, and execution. This transformational activity is similar to leapfrogging to the next S curve in growth hacking.
The traditional approach to business analysis and the role that business analysts played were never effective in waterfall and spiral methodologies. Architects invariably discarded the tedious and protracted documentation created through this process and started performing their requirement studies with each implementation. In the age of agility with complex business solutions, requirements looked for an alternate approach to eliminate this waste, leading to the birth of business architecture.
Characteristics of a Business Architect
The role of a business architect was, therefore, created to perform these new activities. Many organizations have a defined role definition for a business architect today, and we want to underscore four primary characteristics that a business architect must possess:
- In-depth knowledge about the business domain
- Understanding the technology involved
- Ability to represent how value flows within the organization through value streams
- Ability to define the business architecture using domain-driven design principles and business modeling techniques
You can read more about the business architect role from https://www.capstera.com/business-architect/
” Developers are from Mars. Analysts are from Venus “
Business analysts have traditionally operated outside enterprise architecture, resulting in considerable friction between the developers and analysts, which we refer to through the adage, “Developers are from Mars, Analysts are from Venus.” Substantial waste in the form of lengthy, tedious documentation was painstakingly created by business analysts only to be summarily discarded by technical architects and developers as they did not find it valuable or even helpful in some cases. We cannot afford this experience in a highly dynamic, digital-first business. Our solution is a twofold approach – redefine the role and realign the business. Transform the traditional semi-technical business analyst into the enhanced role of a Business Architect, and make business architecture a function of enterprise architecture. (if you are keen on learning more about this enterprise architecture model, please refer to https://thenewstack.io/the-role-of-eipaas-in-enterprise-architecture-part-1/).
Connecting Business and Technology
In the previous articles, we have emphasized the importance of connecting business and technology, and business architecture is the framework to achieve that purpose.
Business architects must actively shift their mindsets while discovering business requirements and seamlessly link them to technical architecture and implementation. In addition, other business and technology stakeholders must contribute to defining the business architecture.
Business architects are like stockbrokers, and the business architecture function is a negotiation system between technology and business. A good business architecture discovery session identifies the business value generated by the product, service, or initiative, clearly highlighting its return of investment (ROI). Value matrices and heat maps (VHM) are standard forms of prioritizing the Go-To-Market (GTM) strategy for business stakeholder groups such as sales and marketing.
You might be wondering how a business architect knows the ins and outs of the business to figure all these details. That is where the domain owner or the business sponsor of the project plays a vital role. Domain owner(s) work closely with the business architect to define the blueprint of business architecture. In addition to strategic input, business architecture covers tactical details such as test scenarios, test data models, and test data.
A business architecture specification (BAS) is the outcome of this process. The structure of BAS is based on the overall architecture framework used by the organization and must be visual to show connectivity between technical features and business value. The information outlined in the BAS becomes a crucial input to the next level of the enterprise architecture process – information architecture.
Organizations, unfortunately, tend to execute the BAS as a singular event and include it as a sequential process to the overall delivery plan. This anti-pattern converts product development into a traditional waterfall method, diminishing the power of a BAS.
Let us look at making BAS agile-friendly.
Agilifying Business Architecture
The fundamental differentiator between traditional business analysis and business architecture comes from the focus and outcome. Business analysis focuses on documenting the requirement. In contrast, business architecture looks at the value each business initiative can generate for the organization. Business value can be quantitative or qualitative. Simultaneously, consumers of the value can vary among different organization stakeholders such as customers, partners, employees, or shareholders.
A business architect looks at the business strategies prioritized through identified value metrics, business models, and market outlook as the first step. Next, they will look at outcomes from each business strategy and the impact each result will make on the system. Once outcomes are identified, a business modeling activity is conducted to determine the initiatives required to deliver the desired results.
Initiatives are products (or services), not projects; moving from a project mindset to a product mindset is critical. Projects have a defined timeline and have an end, but products are evolving and continuously improving.
Initiatives can be new products and services or improvements to the existing products and services.
The outcomes of each initiative are classified into two categories – gains or pains. Gains describe the advantages the target audience is gaining, and pains describe the solutions providing the key stakeholders’ pain points.
The business architect attaches the objectives and key results (OKRs) and success criteria to each initiative to measure each initiative’s success. These will become an input to a growth board that tracks the progress of each initiative and introduces data-driven decision-making.
After that, each initiative is promoted to the execution phase and gets assigned to a lean-agile delivery train’s backlog. Lean experimentation, fast feedback loops, embracing failure, and continuous improvement are critical to minimize risk and promote an iterative approach. Design thinking, prototyping, and productizing outcomes are other essential approaches, considering the rapid business model and market outlook changes that organizations have to deal with today.
Developing the business architecture must be iterative and not a one-time big-bang effort upfront. Failing to do so will force the development process to embrace a waterfall methodology. To ensure an iterative business architecture approach, we must:
- Focus on stakeholders and their interactions instead of cumbersome processes and tools
- Develop working solutions from day one, focusing on value rather than documentation and project plans
- Establish collaboration between business and technical team and avoid establishing a contract of business cases
- Be flexible and respond to changes quickly
- Define feedback loops, iterate, and embrace failure
Increasing the Value of Enterprise Architecture
A leading issue that organizations face is that enterprise architecture becomes a big ball of mud (BBoM). The primary reasons for this BBoM to emerge are lack of business and technology alignment and not mapping software products and services to value streams. Business architecture is the solution to overcome the BBoM anti-pattern. Other enterprise architecture components (information, application, and technology) heavily depend on business architecture to extricate themselves from this BBoM.
A successful business architect delivers a business architecture that creates a synergy between business and technology by creating a bilingual business and technical language. They heavily utilize domain-driven models and define core domains and subdomains when defining the business architecture. In addition to that, they liaise with domain experts and business stakeholders during this exercise.
Enterprises on their digital transformation journey must pay attention to their business architecture and hire business architects with the right mindset and skills to embrace this critical role and drive business value to the organization’s transformation journey.
