Cornerstones of a Business Architecture Practice

Whether driven by top-down mandate or won through demonstrated bottom-up success, there is a point when business architecture achieves “enough” acceptance within an organization to formalize an internal practice. While there are many steps to take throughout the journey of establishing and maturing a business architecture practice, there are four cornerstones that when put into place, can accelerate the process and create significant clarity. 

The Need for Formalization 
As business architecture’s footprint expands within an organization and as the team grows, there is an increasing need for:

• Explicit purpose for business architecture and the value it provides to the organization 
• Clear structure for team interactions and decision-making
• Consistent methods for creating and applying business architecture in various scenarios
• Efficient processes for planning and managing the practice 
• Formal integration with other functions, disciplines and processes within the organization

Establishing a business architecture practice can and should be treated like setting up a new team or department, including all of the components necessary to mature, measure and sustain the business architecture, the business architecture practitioners and the practice itself. While creating and applying business architecture to deliver business value is the top priority, building a solid practice will provide the ability to scale to meet the need for business architecture across the organization – with quality and consistency.    

The Cornerstones of a Successful Business Architecture Practice 

Four cornerstones provide the foundation for a business architecture practice: charter, role and team structure, engagement model and roadmap. Ideally they should be created as a new practice is being established, but are always useful even if put into place later. Each cornerstone provides clarity on a different aspect of the practice. They are all intended for consumption by both the business architecture team and its stakeholders.

Of course business architecture often exists within the broader context of enterprise architecture, so these documents should be developed in partnership with other architecture disciplines if applicable.

A Closer Look at the Cornerstones

The Charter

The charter communicates the definition and intent of the business architecture team. The very process of creating it can be a valuable way for the team to fully think through and come to consensus on the value they deliver to the organization and how they do it. 

The charter is created through a series of conversations, the results of which are compiled into a document containing sections such as definition of business architecture, purpose and value of business architecture for the organization, scope of the team, measures of success, principles and the engagement model (refer to section below).  

Role and Team Structure

The role definition and team structure communicate the responsibilities and scope of business architecture practitioners, as well as provide clarity on reporting relationships, decision-making and team interactions. 

The role definition and team structure are both typically created in partnership with the business architecture team, its leader(s) and Human Resources. More than one level may be defined for the business architect role, reflecting different scopes and types of responsibilities, and providing a career path for advancement. The team structure results from decisions made related to where the team should report and how it should be structured. It is documented through an organizational diagram and is formalized through Human Resources, such as by changing the actual reporting relationships.

Engagement Model 

The Engagement Model communicates how the business architecture team will interact with other upstream and downstream teams. This could include teams such as strategy, innovation, customer experience, product management, planning, IT architecture (e.g. application architecture, data architecture), program management, business analysis, business process management, etc.

The engagement model is created collaboratively through conversations between the business architecture team and each partner team to confirm inputs and outputs, as well as any process or role adjustments needed to ensure integration. The results are documented in an interaction diagram with the business architecture team in the center and all relevant partners organized around it, with the inputs and outputs listed for each. This exercise not only creates clarity and efficiency for team interaction, but also helps to jump start relationships and can diffuse any concerns about the scope and role of business architecture.

Roadmap

The business architecture practice roadmap communicates plans for maturing the practice in an intentional way. It can also include a second track to show work being done to develop and apply business architecture to deliver business value. Progress is reported against the roadmap to the business architecture leader(s) on a regular basis. The roadmap can also be used to justify team resource needs and to align plans with others (e.g. IT architecture teams). Unlike the other three cornerstones which are defined upfront and maintained, a new business architecture practice roadmap is typically created annually.

The roadmap is defined primarily by the business architecture team. The practice activities are typically identified during an annual business architecture maturity assessment, which uncovers key gaps that need to be improved over the next year.

In Summary

Whether or not your business architecture practice is new or maturing, the four cornerstones provide a solid foundation. Along with an overall plan for maturing your practice, they will help you to scale business architecture across your organization – and most importantly provide business value with quality and consistency.