Comparing the BABOK and the SEBOK, Part 2

Business Analysis and Systems Engineering seem to share a substantial in their perceived areas of scope, so it might be informative to see what their respective BOK Guides say about the other discipline.

Do They Know Each Other?

It is interesting that neither the term “Systems Engineering” nor its variant “System Engineering” appear in the BABOK.  This is strange because the BABOK authors are evidently aware of the SE discipline, since the BABOK Bibliography includes these two SE-centric books:

Stevens, Richard, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. System Engineering, Coping with Complexity

Forsberg, Kevin, Hal Mooz, and Howard Cotter-man. 2005. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems

As for the SEBOK, it mentions “business analysis” three times, each time using it as a synonym for mission analysis, such as in this extract:

MA, in some domains called market analysis (glossary) or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise (p. 253).

Judging from this, the SEBOK considers business analysis as limited to mission analysis, which is only a part of the Concept Definition Phase

What is Business Analysis?

If Business Analysis is synonymous to Mission Analysis (according to SEBOK), it should be useful to compare and contrast BA as understood by the BABOK with MA as understood by the SEBOK. 

The table below lists the functions of BA as described by BABOK, and the functions of MA as described by SEBOK.  I tried to match them, with some degree of interpretive freedom on my part.

Business Analysis According to BABOK	Mission Analysis According to SEBOK
Liaison among stakeholders
Understand the structure, policies, and operations of an organisation
Recommend solutions that enable the organisation to achieve its goals	Analyse the solution space
Understanding how organisations functions to accomplish their purpose
Defining the capabilities an organisation requires to provide products and services
Definition of organisational goals
Define how goals connect to specific objectives
Determine courses of action that an organisation has to undertake to achieve those goals and objectives
Defining how the various organisational units and stakeholders within and outside the organisation interact.
	Establish a set of stakeholder requirements for a potential SoI (System-of-Interest)
	Focuses on the identification of the primary purpose(s) of the solution
	Part of the larger set of concept definition activities -
	Understand a mission / market problem or opportunity
	Initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity
	Define operational actions, not hardware / software functions; that is, it is focused on defining the problem space, not the solution space
	The primary products of MA are the revised ConOps of the enterprise, the operational concept, the operational scenarios for the mission, and the context in which the solution will exist.
	MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions).
	MA defines the problem space and analyses the solution space alternatives using quality attribute constraints driven by the enterprise objectives.

I could not match the two sets of functions and find very little, almost no direct intersection between what Business Analysis is according to BABOK, and what Mission Analysis is according to the SEBOK (which treats business analysis as a synonym for Mission Analysis.

And yet, my instinct tells me there is a strong intersection, it’s just that the two BOKs use very different terminology and very different ways of explaining.  (I find the BABOK a bit more refined in its explanations, while the SEBOK tend to ramble a bit).

Number of Pages

This is an easy comparison.  Version 2.0 of the BABOK has 253 pages.  The SEBOK is primarily laid to for reading online using a Wiki platform, but a PDF version is available for download.  This PDF runs to 850 pages.  Better have a full ream of office paper ready if you decide to print this.

Authors

The SEBOK lists 70 authors, some of whom I recognise as respected leaders in the SE discipline.  The ones I know by reputation include: Barry Boehm (but I know him from the software engineering field, not the SE field), Erik Aslaksen, Edmund Conrow, Dov Dori, Kevin Forsberg, and James Martin.

The BABOK also credits as Content Contributors about 19 names, of whom the only one I recognise (but recognise only the name, not what she’s about): Ellen Gottesdiener.  They do have an Expert Advisory and Review Group, from which I recognise the following names: Scott Ambler, Dean Leffingwell, Meilir Page-Jones, James Robertson, Suzanne Robertson, Steve Tockey.

Operational Risks

Operational risks are those risks related to failures in day to day operations. They are different from other kinds of risks such as credit risk, or market risk.

Operational risks are about things going wrong resulting in losses.  For example, a small grocery might encounter the following problems:

• Shoplifters
• Giving too much change to a customer
• A car crashing through the shop
• A customer slipping and hurting themself.
• Goods not the right one
• Counterfeit money
• Robbers
• Fire
• Employee theft

Other kinds of risks are not considered operational risks:

• Another shop opening nearby, drawing some of the customers
• A bank calling on the loan
• Interest rates going up
• Prices of goods going up

Operational risks are about failures of people, systems, and processes, and about external events.

The risk brought about by operational risk, like any risk,  depends on the likelihood of occurrence, and the consequences it brings.  These costs need to be balanced by costs related to mitigating the risk.  For example, the risk of being robbed may be mitigated by hiring guards to secure the store, but will the cost of hiring them be higher than the cost of being robbed, once or twice a year?

The cost of being passed counterfeit bills may be mitigated by installing a counterfeit checking device, but will that cost more?

Comparing the BABOK and the SEBOK, Part 1

I find it interesting that the disciplines of Business Analysis and Systems Engineering share an apparently substantial overlap in their areas of declared responsibilities and specialties.

In the domain of system related projects, both specialise in requirements development, in cost / benefit analysis, in solution assessment and selection, and in verification and validation of the solution.  Could it be they are one and the same thing?

The SE community recently completed its SEBOK Version 1.0 (Systems Engineering Body of Knowledge), available at http://www.sebokwiki.org.  The BA community, through the auspices of the IIBA, has its BABOK (Business Analysis Body of Knowledge), currently at version 2.0 (available at the IIBA website). 

I think it will be interesting to compare the two documents and see what each has to say in areas they have in common, but also in areas which the other is silent.  Where exactly are they similar?  How do they differ?

Since both documents are lengthy, I’ll do the comparisons in several parts. 

To start, let’s look at what each BOK has to say about their particular discipline. 

What is Systems Engineering?

What is Systems Engineering? SEBOK offers this brief definition:

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems

This is a very thin definition, almost to the point of meaningless.  One can probably can use it to describe project management, or even portfolio management, both of which can be argued as enabling the realisation of successful systems. The SEBOK also provides a longer description:

“an interdisciplinary approach and means to enable the realization of successful systems” (INCOSE 2012). It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.

In the glossary, it provides two other definitions, taken from unrelated official documents. The first is from ISO/IEC/IEEE 2010 which says that Systems Engineering is an:

Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life.

The SEBOK also quotes the INCOSE Systems Engineering Handbook (v 3.2.2). The first sentence is exactly the same as SEBOK’s definition:

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost & Schedule
• Training & Support
• Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

The focus therefore, of SE is defining what the customer needs, and delivering the solution that fills the need.

What is Business Analysis?

The BABOK provides the following:

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

So, where SE is an ‘approach’ that ‘governs’ and ‘integrates’, BA is a ‘set of tasks and techniques’ and is meant as ‘liaison’. 

The BABOK continues:

Business analysis involves understanding how organizations function to accomplish their purposes, and defining the capabilities an organization requires to provide products and services to external stakeholders. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the courses of action that an organization has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact.

Here we get some clarity about the focus of BA work: the organisation.

Business analysis may be performed to understand the current state of an organization or to serve as a basis for the later identification of business needs. In most cases, however, business analysis is performed to define and validate solutions that meet business needs, goals, or objectives.

Business analysts must analyse and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the business analyst will also work to facilitate communication between organizational units. In particular, business analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

While BA work is clearly meant to identify the customer requirements, it is clear that BA work sits in the non-technical area of the organisation, specialising in what the organisation does and needs.  In contrast, the SE definition does not make it clear whether the SE is more focused on the technical aspects of the solution (we can assume so from the word ‘Engineering, but that is not the same as having it asserted directly).

A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.

When you do work that is in the BA domain, you are doing Business Analysis, regardless of title.  So if you are an SE, you might also be a BA.

I’ll continue the comparison in another post.