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.

Wiki Way - Documentation without Documents

The environment we work in is highly integrated and involves massive amounts of collaboration. We need networks of related information, but our tools encourage documents that are monolithic silos of obsolesce.

The requirement I gather may be reused by another project in a different system, my definition of a "Customer" is going to be reused by three different projects, my project will impact some functionality that will later be impacted by three different processes, and all of the information in "my" documentation is going to have to be re-read and re-written by a horde of others.

Integrated solutions, silos of documentation

So what we should have for documentation is a collection of discrete pieces of information, shared between projects, systems, departments, and people, referenced from a multitude of places depending on need. This is a Wiki.

What we actually have is a graveyard of monolithic documents that are an arbitrary collection of information based on whether they were written at the same time, that only one person writes, and (if you're lucky) one group will read once. This is documents on a share drive or even an ECM.

Our whole environment is so integrated that a single business process could have come out of dozens of projects, crossing many systems form disparate projects, why shouldn't it call come together in one cross-linked place?

Documentation is great, Documents are bad

Every time you cut and paste from an old document to a new one you are not only wasting time but you are implicitly throwing away everything in the old document for reasons I mentioned a while back.

We have to communicate the same information to many different stakeholders and we assume that we know best every time we pack things together in a "pack" - but it's just plain Hubris to think you know best what others need to know. Best to put everything down and let them pick.

Long Lived

More than %80 of the solution definitions put in documents are never used again because by the time they become the main focus so much of the context around them has changed that the whole document is out of date. You've got to make it easy to change little things about items you impact in the main place they are documented if your information is going to live past you. Wikis make this far easier.

Modern Wikis have so many easy to use funky tricks to re-use and summarize content in different places that you'll be amazed where information ends up getting re-used and read, and if it gets read the chances are that it will get updated.

Presentation not Layout

Most word processors are just plain bad at letting you focus on content. The fact that a Wiki takes you back to paragraphs, headings, bullet points, and table is a strength.

If you want something pretty there are ways to do it, and if you want structured content there are also ways - but my advice would be get back to basics and concentrate on what you want to say not font or bullet points you use to do it.

Separate Project from Prosperity

What absolutely kills any hope of information re-use in documents is that most SDLCS don't differentiate between information needs for the project and for prosperity. You project scope ends up including system scope as well, your test cases include a list of test run along with the long lived definition of test-conditions. This is just crazy but there's no way around it as long as you have to produce a pack for sign off using a document.

I think issue tracking systems are pretty nice here also - but that's a different conversation.

Collate to present

When you have all of your information out there modern Wikis make it trivial to bring it together into one page/place to present for sign off. You don't need to change your deliverables to use a Wiki, you can just generate the content the Wiki way and then collate as needed. Then every time you change the system description all of your deliverables are auto-magically up to date (As well as any other projects that may reference you)

This still one of Wikis weakest points for software development. It takes some trickery to store a point-in-time version of a page but it can be done. The pages you end up creating can also be pretty ugly but I'm hoping somebody (Are you listening Atlassian?) will produce output as good as the PDFs form Wikibooks.

Easy

Seriously easy. I'd say it's easier to switch to Wiki from Documents than to switch to a new set of templates; especially for a younger workforce.

Don't let it just be IT

Chances are if you have a decent sized development community there's already a guerrilla Wiki effort going and there's a real temptation to make this an IT tool, or have separate IT and business areas. That's a mistake.

Wikis have such a network effect going though that by playing nice with others you'll get amazing returns. Business users, process owners, HR people, canteen managers, all have parts to play. Having the deep context about the business linked in with the IT information is what will keep you aligned.

Not all Rosy

It's not all rosy though, we've used documents for documentation for a long time for some pretty compelling reasons. They're convenient, a trusted metaphor, have fantastic control, easily printed, and easily shared by email.

Step away from the requirements/design tool

Heart on my sleeve time, I don't believe in tools.

They over-structure everything, lock you down into their way of doing things, over-organize their own domain and neglect everything else, and make ivory-towers where the tool-user condescendingly "publishes" out information to the plebes who don't have it installed.

Tools get mis-used as a best-practice or process-improvement piece. I've never seen this work. BAs or Architects without the skills or processes needed are still just as ill-prepared with a tool. Spend the money on putting a copy of the BABOK Wieger, Cockburn, and Gottesdiener on everyone's desk instead.

The high-end Tools are also incredibly expensive to buy, maintain, install, support, and train; and once the vendor gives you the first taste you'll always need just-one-more-product.

Next Steps

I wish I could point to a sample of a Wiki showing a business' architecture and systems but I can't. Next big post will be give a rough structure of what you could start off with.