Distinguishing Business Analysis, Business Relationship Management, and Business Architecture

It looks like I'll be able to attend the Common Solutions Group meeting in January, and one of the topics there will be "BRM, BizArch, Biz Analysis - How are you connecting, documenting, and planning with campus partners."

To help get this conversation started, I'd like to offer some background for comparing the fields of Business Analysis (BA), Business Relationship Management (BRM), and Business Architecture (BizArch). I don't propose to resolve the active definitional debates between these fields, and I'm not here to offer "right" answers. I do want to help you compare these fields for yourself, so you can facilitate conversations in your organization that help you set up practitioners and teams for success.

As always this post is framed for higher education, and especially for IT organizations in higher ed.

Why is this even a topic?

IT organizations in higher ed (as in other industries) are challenged to align IT investments with business needs. The challenge is growing as the rate of change in the business of higher education increases, which also increases the opportunity for strategic IT. IT organizations view Business Analysis, Business Relationship Management, and Business Architecture as potential means to meet these challenges and opportunities.

Are we talking about the same thing?

The first common confusion I see is that the terms we're using can be used variously to refer to:

• A discipline: "We need to train more IT staff in Business Analysis skills so they can better understand and meet business needs."

• A role: "Our Business Relationship Manager met with the Dean's leadership team."

• A process: "This idea for an IT service came in through our Business Relationship Management process."

• A deliverable: "Sue will present the future state Business Architecture to the Executive Committee."

These are all distinct aspects for an organization to discuss and work on. To take Business Analysis as an example (you could apply the same thinking to the others):

• You may want a wide range of staff to acquire competencies from this discipline.

• You may want to hire or train staff as Business Analysts to build experience and specialize in this work.

• You may want to promote a shared process that helps teams consistently do a minimum of analysis that makes projects more likely to succeed.

• You may want to define standard deliverables to reduce Business Analysis planning in each project and more easily re-use past analysis.

Each aspect represents different goals for management. I'll suggest work to do on each aspect in the sections below.

The next level of confusion I see is that each field can be variously defined, and not all the fields are equally firmly defined. Let's take them one by one.

Business Analysis

The International Institute of Business Analysis (IIBA) defines Business Analysis as "The practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders." Wikipedia reinforces that this covers a wide range: "A research discipline of identifying business needs and determining solutions to business problems … includ[ing] … software-systems … process improvement, organizational change or strategic planning and policy development."

I consider this the longest-standing and most defined of the fields discussed here. A well-established professional organization defines the field and supports it with resources, certification [1], conferences, and local chapters around the world. The field is firmly rooted in the culture of IT; few IT managers would say they want to run a service or project without doing some analysis.

Nevertheless, some confusion can still arise:

• Because the field is well-established, it encompasses a wide range of jobs and career levels. Practitioners at different levels do significantly different work, sometimes difficult to discuss under one heading.

• In higher ed, the term Business Analysis is most used in IT and skews toward analysis for IT solutions; business units in the institution may feel that this version of Business Analysis doesn't describe the work they need done.

• Business Analysis work is done as part of many roles. IIBA acknowledges a wide variety of job titles that do some aspect of Business Analysis. Especially common in small teams, for example, are PM/BA and Programmer/Analyst type roles.

• Teams adopting contemporary frameworks such as Agile tend to think of Business Analysis as a shared responsibility and iterative work, rather than specialist roles and standard deliverables. Different views on the timing and content of Business Analysis may be unresolved in your organization.

To bring clarity in your organization I suggest:

• Review Business Analysis competencies, for example the competency model offered by IIBA for certification purposes, and identify those you care about.

• Propose which competencies you think should be held by which current and future roles in your organization (ideally as part of a larger workforce development strategy).

• For professional Business Analyst roles, define current and future career levels and paths -- it's not just one job, and position descriptions and compensation need to reflect that in order to retain and get the most from these sought-after professionals.

• For service and project teams, especially for Agile teams, build agreement in the organization on what Business Analysis work most contributes to success and reduces risk.

Business Relationship Management

ITIL Service Strategy defines Business Relationship Management as "The process that enables BRMs to provide links between the service provider and customers at the strategic and tactical levels." The Business Relationship Management Institute (BRMI) states that BRM "embodies a set of competencies ... to foster an effective, business value-producing relationship between business functions and their business partners."

I think of this field as more recent, but fairly defined. The well-respected ITIL ITSM [2] framework identifies BRM as a process area, and the BRMI defines the field for practitioners and offers certification.

But there is room for confusion:

• As a distinct, defined discipline, role, or process, BRM is probably new-ish to your organization and only as well understood as ITSM itself. Organizations adopting ITIL ITSM tend to start from operational processes and wait to formally define strategy processes later (including BRM).

• The work that BRM represents was historically done by IT managers (and others), with varying success. People in your organization may wonder why this topic needs distinct attention, and the discussion may raise insecurity or territorial conflicts.

• According to authors for BRMI, in many organizations BRM initially grows out of Customer Relationship Management or Demand Management. ITIL also acknowledges overlap with these areas. This can result in an organizational understanding of BRM that is less strategic than BRM has the potential to be.

• Similar to Business Analysis, your Agile teams may have their own views on how the work that BRM represents gets done.

To bring clarity in your organization I suggest:

• Propose whether your "flavor" of BRM is more tactical -- as in, "let's make sure we're being responsive to requests from the business and tracking changes they need to know about" -- or more strategic -- as in, "let's engage with business leadership at all levels to understand business strategies and revise our IT strategies and portfolio accordingly."

• Since you'll probably want some of both, propose who does what, and what their relationships are to other roles that also work with the business and guide IT work. For example, how do the people doing BRM relate to: senior IT managers with existing business relationships; business analysts defining outcomes with business stakeholders; and service owners scoping services based on perceived business needs.

• For service and project teams, build agreement in the organization on what your BRM practitioners will contribute and how they relate to team roles -- what are the accountabilities between, for example, a Business Relationship Manager and a Service Owner or Project Manager?

Business Architecture

The Open Management Group describes Business Architecture as "A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands." In the TOGAF framework [3], Business Architecture defines a "Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals." The Business Architecture Guild [4] calls for "An abstract representation of an enterprise and the business ecosystem in which it operates", used to establish "a recurring value stream" that provides the "ability to move from a strategic plan through solution deployment." I consider this field to be the least firmly defined of the three, especially in higher education. However, there is a professional organization with resources and certification. Business architecture is a frequent area of confusion because:

• As with BRM, the work that Business Architecture represents was historically done by others, mainly senior managers and some senior Business Analysts. Managers in particular may wonder why this field needs additional definition and work, may not be ready to collaborate with non-managers in this work, or feel that it challenges their own role. (I've seen otherwise fine Business Architecture work wasted because of this.)

• IT and business perspectives on Business Architecture tend to be quite different. IT tends to think of it as a means to better understand business needs so IT can respond appropriately. Business-centric practitioners tend to think of it as a means to plan and execute changes in the business (which may depend in part on IT services).

• Definitions of Business Architecture (as a field and even as a role) are often surprisingly vague about whether the intent is descriptive (to show the business "blueprint"), or transformative (to effect change in the design of the business), or both.

In my opinion, even spreading the term Business Architecture in your organization has little value until you work through these topics.
To bring clarity to your organization I suggest:

• Describe why you are housing Business Architecture in IT (or not).

• If it is housed in IT, Business Architecture could be variously intended to help the IT organization understand business strategies and needs; effect change in the business architecture of the IT organization (as a business unit); or be offered to other business units as a service to work on their business architectures. For you, is it some or all of that?

• If not, IT can still benefit from fostering Business Architecture work in the business -- for example, so that business units are better prepared to work with IT. Is that something your IT leadership wants to promote?

• Consider what "flavor" of Business Architecture work will be accepted and actively supported by your existing management (both IT and business managers). This is especially important for "transformative" Business Architecture to succeed. (See my related post, Business Architecture is Management Support.)

• Based on these decisions, if formalizing a Business Architect role, make sure job descriptions are clear about whether the role is descriptive, transformative, or both, and realistically describe its scope and how the work will be utilized. (See my related post, Defining a Business Architect Job Description.)

What are you ready for?

I can't say there is a direct maturity progression from Business Analysis to Business Relationship Management and Business Architecture, but I do think they build on each other in some ways, and you don't have to do grow them all at once. As a rough sketch I suggest:

• As quickly as possible, develop Business Analysis to the point where the IT organization (all of it, from portfolio management to service and project teams) can effectively gather, analyze, and drive work from well-defined business needs.

• Recognize that as they gain experience, your senior BAs can take you a long way, building stronger business relationships (as a partial substitute for BRM) and partnering with business stakeholders to work on strategies, goals, and changes to business capabilities and processes (as a partial substitute for Business Architecture).

• Ramping up more gradually, identify where BRM work is currently happening, what its challenges are, and where formalized BRM roles, practices, and process would be helpful and well received (or not). Make sure BRM work can hand off to effective Business Analysis practices (and other roles).

• Carefully consider whether and when you are ready to distinguish Business Architecture, perhaps first just as an analytical framework ("descriptive" mode), and more gradually as a practice that effects change ("transformative" mode). Business Architecture has the most ambitious potential scope out of these three fields, and is most likely to falter if scoped too broadly too early.

• As always, share what you find! I look forward to discussing these concepts and writing about them some more.

Endnotes

1. I mention certification because where certification is well-established, it means professionals have spent time defining their field, which provides a useful reference for you. I think the value of actually doing certification is situational -- many practitioners do just fine learning by doing, others benefit more from training and certification.
2. The IT Infrastructure Library IT Service Management framework -- see Wikipedia.
3. The Open Group Architecture Framework -- see Wikipedia.
4. In its Business Architecture Body of Knowledge Guide.