Designing an Effective Business Architecture Team

Comments: 2
Rate this:
Total votes: 1

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.


Keuhn Team1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

  1. 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. 
  2. 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.
  3. 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. 

Comments

Simona Lovin
,
posted 2 years 44 weeks ago

Hi Whynde, In my

Hi Whynde, In my experience, reporting into the CIO organization (either through the Enterprise Architecture function or as a parallel structure) lessens the effectiveness of the Business Architecture group, which is relegated to providing tactical support to IT initiatives. This said, I really like your point about starting wherever you can start and building momentum from there. Sometimes it takes time - as much as one or two years - until business architecture gains sufficient visibility and credibility to earn a seat at the table. It takes grit and patience to to hang in there during the initial maturation stage and doggedly pursue small wins while keeping the big-picture potential in mind. The other point you make which I fully agree with is that the Business Architect role is not monolithic. Many organizations post generic job descriptions for Business Architects which cover all the possible skills one could have - and then are surprised they can't find good candidates. It takes at least five skillsets to make up a good Business Architecture team:
- Strategists - folks who monitor the external business environment and can discern trends and impacts at the business level, and who can build the business cases for internal changes
- Strategic business architects - who take their input from Strategists and turn it into foundational business architecture artifacts (like capability heat maps and enterprise-level blueprints) to inform/support the business cases
- Tactical planners - who take the foundational artifacts and develop initiative/product roadmaps based on them
- Tactical business architects - who support business areas/initiatives and are responsible for baseline and target business architectures serving those initiatives, and
- Repository administrators - tool-oriented folks whose primary responsibility is to administer and maintain the central repository of business architecture information Thanks for an interesting article!
Simona
Ankit Tara
,
posted 3 years 9 weeks ago

Whynde, great article --

Whynde,
great article -- succinct and to the point.
One scenario that is of special interest to me is the one where "team may have been incubated while reporting to an IT leader and then it later shifts to report to a business leader".
what are the key success factors for this transition? Thank you in advance, Semyon Axelrod

Join the Discussion