As organizations set out to establish their own internal business architecture practices, some of the most frequently asked questions are about how to structure the business architecture team and role. These are indeed important considerations because the structure significantly contributes to both the effectiveness and success of a business architecture practice. How the team is structured and positioned, and how the business architect role is defined directly and indirectly speak volumes about strategic importance, scope of responsibility and key relationships. Certain choices made up front will make it easier to obtain organizational buy-in and perform the role at a strategic level.
Key Structural Decisions
While there are certainly other considerations, a few key decisions need to be made once an organization has decided to formalize a business architecture practice.
Business Architecture Team Structure
The business architecture team structure defines how the business architects will be assigned across one or more leaders. Some common options are having a fully centralized team, a fully decentralized team or a hybrid of both, as described in the table below. The Center of Excellence has emerged as a frequently used and effective structure, allowing business architecture teams to maintain a common source of vision, practices and knowledge about the business and business architecture. In this structure, business architects can still report in a centralized or decentralized manner (or both), and business subject matter experts and IT architects are treated as virtual participants. When defining the business architecture team structure, consideration should be given to how the IT architecture disciplines are structured and how integration will occur between business and IT architecture.
Business Architecture Team Positioning
The business architecture team positioning defines where the business architects will report within the organization. Some common options are reporting to a business leader(s), reporting to the Enterprise Architecture (EA) leader or reporting to an IT leader(s), as described in the table below. There has been a trend of business architects reporting to the business for a number of years now and with success. The business leader which the team reports to varies, but often includes a leader responsible for strategy, planning and/or transformation or even C-Level executives in some cases such as the CFO. Even when business architects report to the business, they always have a foot in both worlds, as part of the business and as part of Enterprise Architecture. As a result, no matter what the structure is, strong relationships and integration are always critical for success.
Business Architect Role Definition
The role definition should position business architects strategically and at an enterprise level. The defined responsibilities should go beyond just creating and maintaining the business architecture knowledgebase, but also applying it to deliver business and IT value. The number of levels within the business architect role also need to be defined. Mature business architecture teams frequently have three or four different levels which may vary by aspects such as scope of responsibility, focus (e.g. strategy translation and transformation, mergers and acquisitions integration, business architecture practice management, etc.), level of strategic/business advising and management/mentoring of other business architects. When defining the business architect role, consideration should be given to how the IT architect roles and levels are defined.
Recommendations
Here are a few practical recommendations, based on the experiences of other business architecture teams.
- Select the team structure and positioning that support your business architecture value proposition and fit best within your organization. Regardless of what works for other organizations or what you might want, in the end the best structure and positioning is what fits your organization best at this point in time. This is particularly true for a new practice that is being established. Sometimes you have to start where you can start and that is where you have advocacy, investment and the ability to build the practice in the right way. It is better to get started and then consider other options once the team has demonstrated success.
- Set expectations and be open to change. As business architecture teams mature, they frequently evolve their structure, positioning and even the role. A team may have been incubated while reporting to an IT leader and then it later shifts to report to a business leader. A team may have initially been centralized, but then domain business architects are later put into place and it shifts to a hybrid model. It is important to set expectations up front that change can and should occur as the organization adopts and expands its needs for business architecture.
- Stay true to the business architect role. As you establish the business architect role, hire the best people for it, formally name them in the role, assign them responsibilities at a strategic and enterprise level, and empower them to act. Particularly in the beginning, the people in the role and how they perform it will demonstrate to the organization what business architecture is and is not. Actions will speak louder than words.
In Summary
Defining an effective business architecture team is a function of best practices and what works for your organization now. You will continue to evolve and mature over time in ways that meet the needs of both the team and the organization. Regardless of the team structure, your success will also depend on how well you develop relationships and integrate business architecture into all other related business and IT functions, disciplines and processes.
