Elementary Business Processes

I go a little crazy whenever I see most "process" artefacts. There's something about the wooliness of most models that drives me nut. This then gets justified with "Well, this only a level 3 process diagram, not a level 4" and then follows a long useless discussion about what Levels 1 through to N really mean.

At which point someone produces some consultancy's slide pack that include a formal defintion of levels 1-4 and everyone walks away thinking we all aggree; that is until you try and reconcile process artefacts from two seperate projects and you find you can drive a a truck through the ambiguities in most of these defintions.

So what's the solution? I don't claim to have anything definitive but I do think that by building models based on at least one well defined and understood idea, and defining further concepts based on that we can come up with something more useful.

In summary: Don't start with defining "Level 0" process is. Define the bottom level and let the concepts flow from there.

Elementary Business Processes

The only really firm defintional ground I can find in this domain are "Elementary Business Processes", these are defined as:

An elementary business process (EBP) is defined as a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state (C. Larman, Applying UML and Patterns)

This is happily a defintion that can be used for:

A task in a BPMN diagra

A single use case

A step in a "Business Use Case" (Using the term in it's proper sense, not just as a vague use case)

The atomic piece of your functional business architecture.

This is a well understood and generally aggreed piece of functionallity that can then be used as a building block for everything else. They provide the central tracing point between all your different views of the world. You can link them to:

Organisational Functions

Orinisation Units

Stakeholder Requirements

Systems

Events (I'll talk more about events and EBPs later)

Services they Produce/Consume (e.g Service Orientated Analysis)

Logical Entities (Through a CRUD Matrix)

Applications

Disaster Recovery Requirements

Support documentation and responsibility

And just about everything

EBPs provide yout the atmoic unit of functionallity while doing functional modelling in the same logical entities and screens do for data and unser interaction modelling.

This unit can then be used to integrate your functional requriements to the steakholder requirements, information arch, and application arch.

Data Models

I'm a big fan of the Conceptual or Logical data model as a way of driving communication about the problem domain. Without one it's almost guaranteed that you will miss requirements and make some bad assumptions about the way users think of the world.

At a fundamental level a Logical Data Model is simply a glossary.

• When I say Customer what do I mean?
  
• When I say Location how do I describe it?
  
• When I say Measurement what information does that entail?
  
• When I say a Charge has a Recipient what sort of thing is the recipient?
  

Unless you can answer this sort of question you just can't reasonably communicate about much else.

One of the problems is that fully-laden ER diagrams are the most "correct" way to capture this information and also incredibly intimidating for end users as they're just so busy and technical looking.

To counter this I tend to strip my ER diagrams down to basics and then pretty them up. This isn't always appropriate, I've taken an example below from Bridging The Gap where the detailed mapping from an old to new system was important so the fully-blown ER was required.

This take a very busy & technical looking document like this:


To a quite simple, focused almost cartoon like output like this:


This trades off some accuracy and level of detail for possibly much higher user engagement, and you can do it without losing any fidelity about the things you actually are trying to communicate, e.g. composition of each entity and their relationships.

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.

Blog the BABOK Part 1

I'm going to start trying to go through the BABOK 2.0 chapter by chapter and blog my impressions as I go.

My first impression is that half of the names in the reviewers and contributors list don't have a the IIBA Accreditation (CBAP). This isn't a great sign - but it's defintely improving.

It's also nice that it has a cleaner, simpler, and better edited feel. All the blanks sections and pieces that felt cut and pasted from a google search are gone now.

I'll start with the first few pages tomorrow.

Subjective Quality - Negative Quality Requirements?

Doing Pesach reminded me what subjective feature "quality" is. For those who don't know observant Jews basically use pretty much an entirely new set of kitchen equipment for 8 days every year during Passover. Just google it if you really want to know.

For the past few Pesach's we have used a dirt-cheap K-Mart special kitchen starter set for all our cooking needs, and a bunch of the most basic electric fry pans and blenders you can buy. And every year I love them. They do exactly what I need to do, do it with no fuss, and then I put them away for a year.

But if I were to use the same set all year I guarantee I would hate it, they have no fancy features, they feel cheap in my hand, the knives lose their edge every second tomato, and a host of other things.

But because my expectation were well managed, and they do the basic minimum well-enough for the price-point I am actually very satisfied.

The manufacturers compromised on some non-functional requirements to deliver the ones I care about.

So why don't we do this for NFR in our own docs? We spend so long talking about the ones that we want to be good - why don't we list the ones we really don't care about?

For example my kitchen set could have:
* Can fall apart after 6 months of normal use (That's 23 years of Pesach after all!)
* Can be ugly (8 days, who cares? We use disposable plates and cutlery for the table anyway)
* Does not need to be dishwasher safe (We don't use our dishwasher either, hence the plastic plates and cutlery)

These negative quality requirements are actually useful in designing a solution. The undifferentiated mass of positive quality requirements in most design docs are really only used to hold the delivery side to account (e.g. blame the vendor or IT) later on.

In a way it's a lot like "Scope" documents. Don't bother reading what's in-scope, whats out-of-scope is the important bit.

Break for Two Weeks

Will be away from the 8th of April until the 20th.

A meaningful and kosher Pesach, and a big Chag Sameach to all of those for whom it is applicable.

0 Bug UAT

This post has no informational value it's just to brag.

I have just exited the UAT phase of my current project with 0 defects. Not 0 Critical/Major defects. 0 defects of any sort whatsoever. The testing was quite comprehensive and thorough too.

How?

Mainly developers who did fantastic Unit and Integration testing at they went to ensure high quality deliverables, but ongoing regular user engagement with lots of demos and user access to the system during development helped to. Of course all this was only possible due to the savvy and engaged user base.

It's not about having a project-team where everybody is in the 5th percentile of awesome-ness (Though a few of our team are), it's having a team where no-one is in the bottom 20th.

And by "Project-Team" I of course include the business stakeholders, UAT authors/testers, docs reviewers, and SMEs.

It's just SDLC nirvana at the moment. No surprises. No fire-fighting. Just predictable well-planned, well-paced delivery of value to the business.

P.S. I'm getting a lot more people reading this blog than I thought I would (Not saying much). I really only intended it for my team in the consultancy I work for. If you're reading and I'd know who you are drop me a comment or email - I'd love to know who's interested.