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.
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.
There are no products in your shopping cart.
0 Items |
Hi Whynde, In my
- 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
Whynde, great article --
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