Defining a Business Architect Job Description

Last year I had the opportunity to rewrite the job description for my Business Architect role. Since these roles are relatively new in higher education, here's an overview of the thought process.

The descriptions of Business Architect roles that I saw commonly mentioned:

• Contributing to enterprise strategy
• Establishing management and governance structures for execution
• Defining and assessing business capabilities
• Developing business transformation plans to grow business capabilities
• Providing guidance to programs or projects

To me, these activities represent a vision for business architecture in an enterprise with mature, well understood architecture practices. To be successful in these activities, the Business Architect would need clear expectations already in place on the part of management at all levels regarding the business architecture function.

What about a business architecture practice that is just starting out? I was the first person (in a 22,000 employee enterprise) to hold a Business Architect title. Therefore my job description needed to be "localized" from a general vision of business architecture to meet the needs of my organization. I found I needed to define:

• The organization scope of the role
• The levels the role works at
• The mode the role mostly works in
• Its relationship to business analysis

Organization scope

The organization scope of a Business Architect role can vary, ranging from the whole enterprise to an organization within it. This scope describes the expected "reach" of the role and bounds the relationships and sponsorship required for the role to succeed.

In my case the role is located in the Enterprise Architecture program in central IT (a 500 employee organization). The role is focused on business architecture for central IT -- its strategy, portfolio, pipeline, projects, and services. I'll certainly pursue opportunities to contribute in other parts of the university -- especially to strengthen IT-business relationships -- but there aren't formal structures in place for that.

Levels

It's generally acknowledged that a Business Architect's focus may vary across several levels, such as:

• Organization: Works with senior leadership to establish management and governance structures, processes, and principles
• Strategy: Works with senior leadership to translate vision into strategy and target capabilities
• Portfolio: Based on strategy, identifies portfolio gaps and defines needed initiatives or projects
• Program or project: Works to align program or project objectives with strategies and target capabilities; supports program or project execution

Based on working with my leadership, I see opportunities for my role at all of these levels; I would not exclude any level from my job description. This is largely because my organization scope is already relatively narrow. A Business Architect working on the scope of the whole university, for example, would need to focus on fewer levels.

Mode

From what I've seen, a Business Architect's mode of working can range from more "descriptive" to more "transformative" (or some mix). I see both of these modes represented in the Business Architecture Guild's Business Architecture Body of Knowledge. The following illustrations are from Part I of the BoK, available here in PDF.

Regarding what I call the descriptive mode, the BoK says business architecture provides “an abstract representation of an enterprise and the business ecosystem in which it operates.” Figure 1.1 illustrates what business architecture describes:

Regarding the transformative mode, the BoK says business architecture establishes “a recurring value stream” that provides the “ability to move from a strategic plan through solution deployment.” Figure 1.5 illustrates how business architecture transforms:

For a business architecture practice that is just getting started, both modes are important, but I believe the transformative is dominant. This is because the "channels" by which business architecture analysis could lead to changes don't exist yet; simply describing a current and future state won't create an impetus for change. It's often up to the Business Architect to rally stakeholders, co-lead or lead the change, and sustain it.

Of course, at the same time, the Business Architect has to do descriptive or definitional work. Figure 1.5 in the BoK shows many kinds of descriptive analysis that may be required to support the transformation. It's just that for my leadership, these aren't the deliverables they have in mind; what they have in mind are successful changes. The descriptive work is there to enable the transformative work.

To communicate this with my management, I used this view to show what my role does:

This view relates the Business Architect to a "pipeline" for change. Notice that the role is cast as "support".  There are already people working in this pipeline, doing work that overlaps with my proposed responsibilities. For a business architecture practice that is just getting started, I think it's important to emphasize how the Business Architect will help existing decision-makers and teams work better.

Business analysis

A natural question for a new business architecture practice is, "how is your work different from business analysis?" This is a source of much dispute online. The discussions suggest differences such as:

• Business architects primarily enable or carry out senior leadership decision-making across portfolios of programs and projects, while business analysts primarily support decision-making within a program or project
• Business architects consider all stakeholders and work toward enterprise-wide alignment, while business analysts focus on specific stakeholders and alignment within a program or project scope
• Business architects commonly propose and work to bring about new initiatives or programs, while business analysts mainly work within established program or project goals
• Business architects are leaders in preparing their organizations to make use of business architecture methods, while business analysts typically work in situations where a business analyst role is already defined

To me, these statements also need to be "localized" to the particular organization. Does your organization have a strong business analysis practice? If so, you probably have senior business analysts whose work overlaps with business architecture (the Business Analysis Body of Knowledge calls it "enterprise analysis"). For example, senior business analysts are probably supporting decision-making at the project or service portfolio level, not just on individual projects. You'll need to negotiate the handoffs between these practitioners and the Business Architect role.

Conversely, if your organization has less established business analysis (fewer practitioners or less scope), then there is an "air gap" that needs to be closed for business architecture to have effective handoffs to business analysis for detailed analysis and execution. This is the situation in my organization (and what I'd expect in most of US higher education).

Therefore, part of my job description is to do business analysis where it's needed to help changes succeed, and another part is to build up the practice of business analysis in the organization. Some ways in which I do the latter include hosting a business analysis community of practice; advising projects on business analysis methods they should apply; offering workshops on business analysis methods; and participating in hiring of business analysts.

Job description

In summary, here's where I landed in applying the above considerations for my organization. The job description states that in general:

Business architects work toward an enterprise in which business capabilities are well-defined and well-aligned with each other and with mission and strategy. Toward this goal, business architects help people work together and make effective decisions on strategies, portfolios, programs, and projects. To do this, business architects apply a wide range of approaches and skills including information-gathering, facilitation of groups, analysis and planning methods, architectural frameworks and models, and leadership methods appropriate to each situation.

The primary job responsibilities that resulted from the above considerations are:

• Provide business architecture in support of the IT strategy and portfolio management pipeline
• Support and grow IT strategy, portfolio management, and governance practices through analysis, facilitation, and business architecture methods
• Propose or facilitate definition of initiatives, programs, portfolios, or organization changes in support of roadmaps
• Provide business architecture in support of high priority projects
• Prepare business architecture deliverables (such as functional analysis, process mapping, or capability mapping) to hand off to project teams for detailed business analysis
• Prepare architectural assessments of systems and information (such as systems landscaping or conceptual data modeling) to hand off to project teams for detailed systems or data analysis
• Enable other architects and analysts
• Support and guide project business analysts or architects in the application of enterprise architecture principles and methodologies to improve requirements analysis, project execution, solution development, continuous improvement, or change management
• Develop training and promote professional development

I hope you found this review of considerations useful, and I welcome your comments!