Reading the BABOK - Chapter One

Of all the geeky things I've done, being excited to read the BABOK has to rank pretty highly (And I used to wear my mobile, palm pilot, and leatherman all on my belt at the same time so that's saying something.)

My excitement has been justified though - this is a great effort from the IIBA and has been well worth the wait. It finally gives the BA profession a foundation for more involved discussion. It's early days though, and this comes out in it being a very self-conscious artefact, lots of references to why it was written, where it comes from, what it's not trying to do, etc.

Business Architecture is obviously out-of-scope though. I hope that will be the next stage of BA professional maturity.

The basics structure of the document goes like this

There are knowledge areas that deliver outcomes

Knowledge areas have tasks that are performed to help deliver these outcomes

Tasks can be undertaken using one or more techniques

The business analysts who do this would be advised to have some competencies before they attempt this

Concepts

But the real value lies in the definition of core-concepts, the definition of "Requirement", and the classification scheme is pretty similar to v1.6, e.g.

Business

Stakeholder

Solution (Functional)

Solution (Non-functional)

Transitional

I'm a bit disappointed that the term "Non-Functional" is back in. I preferred Quality-Of-Service, but considering how widespread Non-Functional is it's not a surprise.

Knowledge Areas

Maybe I'm a bit of a waterfall guy but the line between problem-definition and solution-definition in the knowledge areas was a little blurry for my liking. It's all a little blurry between Enterprise Analysis, Requirements Analysis, Elicitation, and Solution Validation. I think I'm in a minority here though.

There an explicity caveat earlier in the doc that the level of details is left undefined as it's so project dependant, but I would have like an acknowledgement of the difference between Requirements and Models, and between Prescriptive and Descriptive models. I've blogged about this before.

I had a view of 1.6 where Elicitation deals with a lot of Business and Stakeholder requirements, which are turned into Functional and Non-Functional requirements by Requirements Analysis, which are then QA'd and Refined through Solutions assessment and Validation. See the picture below for a gross simplification

Tasks

Only a BA could write this section. It's a whole sections defining now what we're going to talk about it, but the structure we will use. It's useful, and I like it (I'm a BA after all) it's just such a "BA thing" to do.

A task almost seems like the EBP (Elementary Business Process) of BABOK. The smallest thing you can possibly do by one person that adds value and leaves the deliverables in a consistent state. The whole EBP concept deserves it's own post some other time though.

It's important to note that tasks don't mean things done all at once, and done only once. They're very agnostic between waterfall, iterative, and agile. Tasks are things that are done, and it doesn't matter if it's part of a monolithic document drive process, or a light-weight agile process.

Tasks inputs and outputs

What they do include though is the inputs and outputs of the tasks, and each KA has an overview of the inputs, tasks, and outputs. This is more like a value-chain than anything.

It's all very useful stuff, but I'm having trouble getting past that fact that everything is documents in a quasi-BPMN notation that's not really communication to me the overall relationship between the tasks and KAs. That's the sort of things you expect from a methodology though.

I have an A4 diagram around somewhere of the relationship between BA tasks, their inputs/outputs, and the rest of the solution delivery function, but it's very specific to software development and very specific to an iterative lifecycle.

This whole section really just gets my appetite up for the techniques section. Having a series of pre-rolled summaries for descriptions of techniques will be very useful.

Underlying Competencies

This area is pretty wet. Behavioral Characteristics, Communication Skill, and Interaction skills have so much overlap I'm surprised they haven't been whittled down a little.

Overall Impressions

Great stuff. Even if chapter One was the whole BABOK it would still be useful. It sets out the structure well, defines it's terms, and gives me a structure to think about BA tasks in. I'm already thinking of how we can re-write our BA Performance Review and Interview Evaluation process to line up with the BABOK Knowledge Areas, Tasks, Techniques, and Competencies.