Monday, October 21, 2013

Enterprise Architecture: A Specialization of Business Analysis

A Green Paper for IIBA Research and Innovation has taken over my life for the last month (Improving Business Analysis Performance: A Model for Empirical Testing) so blogging has fallen to second place in my writing. (You'll be hearing more about the paper soon.) Still, there are occasions where I find myself writing a lot on LinkedIn and other people's blogs - and some of those comments should be posts here.

Here's one. A thread I started in the IIBA LinkedIn Group (Systems Thinking Techniques) has inspired a lot of discussion - which has inspired a lot of discussion. Duane Banks (Holistic Analysis and Solutioning) has been adding a lot to the discussion, but his opinion of what is and is not business analysis is limited. For example, Duane says,
"No, the BA is not organization oriented, assuming organization pertains to initiatives at the business unit or line of business level."
"But it's too much to ask for that BA to also have responsibility "to know how the one small function they are working on fits in with the big, *the really big*, picture."
He also quoted Nick Malik, who said:

"Enterprise Architecture is a keeper of executive integrity.
Enterprise Architecture is the only profession (that I know of) that is focused on making sure that the strategy announced by an executive actually comes to pass. Enterprise Architects exist to make sure that the needed programs are created, and executed well, keeping in mind the end goals all along the way. EA’s go where angels fear to tread: to execute strategies and produce the desired results if they can be produced."
I had the pleasure of meeting Nick at a FEAPO summit a few months before he published that post. (It really was a pleasure - he's a great guy to hang out with, argue with, and laugh with.) At that meeting we (the FEAPO Member Organizations) talked a out the role of the BA as defined by the Tasks in the BABOK Guide. Several FMOs acknowledged that Business Analysis Tasks and Enterprise Architecture Tasks are the same Tasks, but performed in a different context. In this sense, Nick's argument from ignorance is unconvincing; IIBA makes the claim that Business Analysis is the profession that holds decision makers to account - and here's why: you can substitute 'EA', 'executive' and 'programs' for other terms and the statement is still true.

Profession / Professional
Decision Maker
Resulting Quote
Enterprise Architecture / Enterprise Architects
Enterprise Architecture is the only profession that is focused on making sure that the strategy announced by a[n] Executive actually comes to pass. Enterprise Architecture exists to make sure that the needed Programs are created, and executed well, keeping in mind the end goals all along the way. Enterprise Architects go where angels fear to tread: to execute strategies and produce the desired results if they can be produced.
Business Analysis / Business Analyst
Business Analysis is the only profession that is focused on making sure that the strategy announced by a[n] Sponsor actually comes to pass. Business Analysis exists to make sure that the needed Projects are created, and executed well, keeping in mind the end goals all along the way. Business Analysts go where angels fear to tread: to execute strategies and produce the desired results if they can be produced.

This hints that systems thinking must be as applicable to Business Analysis as it is to Enterprise Architecture - because they seem to be the same thing, at some level. But what level?

The idea that systems thinking is not BA work appears to be based on a false assumption (A) and a false statement (B), both noted below.
A) The systems that projects deal are less complex (have a smaller number of interacting components than) the systems that programs deal with. 
B) Business Analysis Tasks are performed only in IT, in Projects, or in IT Projects.

Disproving Assumption (A) - System Complexity

Imagine a system S with N components. Some of these components are subsystems (N'). Some are just things (N" = N - N').

Now imagine a system T with M components. As with S, some of these components are subsystems and some are just things. In this case lets choose T such that it has the same number of subsystems and 'just things' as S. This means N = M, N' = M', and N" = M" (the counts, not the actual components). We can go further, and choose T such that the relationships and interactions among M' and M" of similar complexity to the relationships and interactions among N' and N".

Now, imagine that T is in the set of N': T is a subsystem of S. We have a system and a subsystem with the same number of components. The same logic applies to the relationships between components and other factors that drive complexity.

Conclusion: Assumption (A) is false. The complexity of a subsystem is independent of the complexity of the system it is a component of.

Assumption (B) - False by Definition

If it is true that IT, Projects, or IT Projects are the full span of the domain of Business Analysis then BABOK Guide v2 misrepresented the profession and v3 will be worse. IIBA has made it clear time and again that the scope of business analysis is not limited to this range. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) v2, section 1.2 states that "...Business analysis practitioners include not only people with the job title of business analyst, but ... any other person who performs the tasks described in the BABOK® Guide." It says a lot more - including calling out Enterprise Analysts and Business Architects as examples - but the fundamental point is simple: either EA is a specialization of Business Analysis, or there are Tasks that are performed in Enterprise Architecture that are not found in the BABOK Guide.

If these EA-only Tasks exist, no one has yet found them. Certainly, v2 has an IT and Project bias in the writing - but the point remains.

By the way, that bias in v2 of the BABOK® Guide is based on evidence, not just the opinion of an expert in one domain. The content was guided by a dozen volunteers, who lead many dozens of writers. That community developed content was reviewed by practitioners, experts, and (after rewriting) it was reviewed by the public - and then rewritten again before publication. Every bit of formal feedback got a formal response, too, following the ISO standard for Standards. (The development of v3 followed the same process: it represents the combined insight of hundreds of professionals so far, and will have inputs from thousands before it is published.)

In addition to this the Role Delineation Study for v2 indicated that the content was very much a reflection of what BAs really do. Extensive surveys of commonly used Techniques were also used to drive the selection of content.

So, if you accept the evidence that the contents of the BABOK® Guide v2 as a reasonable reflection of the business analysis profession, then you must either accept the claim that Enterprise Architecture is a specialization of the profession, or find a Task that is unique to EA.

Many have looked. No one has identified one. That's not to say no such EA Task exists - but there is a lot of absence of evidence.

End Note

Is a surgeon a medical doctor? Is a heart specialist a surgeon? Specializations are powerful, useful, and everywhere. Business Analysis has specializations that are powerful and useful. Enterprise Architecture is one of them. At least, that's what the evidence we have so far shows us.

Sunday, October 20, 2013

Another Astonishing Automation

From, 2009/07
So... How will Star Trek: The Next Generation tech affect your job a a BA?

Summary Article: Automatic speaker tracking in audio recordings (Science Daily, retrieved 2013-10-23)

Years ago it was clear that human speech would be completely comprehendible to computers. Now, a team of researchers has made a big advance in the field. It is one thing to interpret one person in a quiet room. Several people in conversation is a different task entirely.

Part of my joy in reading this on a sleepy Sunday comes from the realization that there is an entirely different kind of geometry that I had never heard of.


Journal Reference:
  1. Stephen H. Shum, Najim Dehak, Reda Dehak, James R. Glass. Unsupervised Methods for Speaker Diarization: An Integrated and Iterative ApproachIEEE Transactions on Audio, Speech, and Language Processing, 2013; 21 (10): 2015 DOI: 10.1109/TASL.2013.2264673