Worship at the altar of the BABOK

UPDATE: Tried to make this post less of a rant *LOL*

Eric Reiss made a great comment during his presentation on effective E-Service at IA Summit 2008. He suggested that while it’s a wonderful thing that we’re celebrating our profession by formalising post-graduate courses on Information Architecture, we should never forget that there are other people, and other professions, who know more about information architecture than we do. This was something echoed by Andrew Hinton in his most-excellent closing plenary for the conference.

According to Andrew, Information Architecture emerged as a community of practice from intersections between other disciplines like Library Science and Cognitive Psychology and for a long time, there was a lot of grey and a lot of uncertainty about what IA was and who IAs were.

The profession of Information Architecture has come a long way since those days and information architecture activities are now held as a vital piece of a system’s design. This doesn’t mean, though, that as far as designing great user-experiences, or in helping to make information understandable by classifying it and structuring it, that we know everything about IA — because we don’t. And I couldn’t agree more — there are bound to be other disciplines and practices that have other pieces of the holy grail of perfect design.

Business Analysis is also going through change and evolving into a discipline of its own. As such, Business Analysts from all sorts of different communities of practice and other disciplines are finding themselves in uncertain territory as it grows to accommodate the intersections between practices. We’re certainly not all from engineering or systems design, some of us come from scientific method and research analysis disciplines. Some may suggest that this evolution brings uncertainty to the market about what being a BA is really about, but its all part of the dynamics of an evolving and changing community of practice.

What we’re seeing, though, is that some BA associations are attempting to standardise and fix in time what what a BA is, what a BA does. Their efforts have generally culminated in an attempt to define these issues (maybe even prescribe it?) in their publications:

“Discover the Business Analysis Body of Knowledge® (BABOK®), the accepted standard for the BA profession … the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices … defined and enhanced by the Business Analysis professionals who apply it in their daily work role … [describing] the tasks and skills necessary to be effective”

It’s great that, for Business Analysts (the role), we’re developing material for BA the discipline. But this is only one view of the BA. To suggest that people will be tested on this view and then be called BAs in order to differentiate those who are not ‘certified’ is a little dangerous. It suggests that those with different ideas on BA activities are not true BAs. From my readings on the history of the Christian Church, there are many parallels between this idea and the Reformation in England centuries ago.

If communities of practice are emergent, self-organising, then the nature of business analysis (the role, the activity, the discipline, the community and even the title) will change over time as it learns from other disciplines and amalgamates new ideas into its own. People will naturally come to business analysis from other disciplines and backgrounds and help to shape it over time. To suggest that, like the French language, this natural process can be controlled and defined in order to bring ‘clarity to the market’ is rather naive.

So why not give the artefacts that help shape the discipline over to the BA Community? Why not put the BABOK into a Wiki and suggest that the BA Community contribute the wisdom of its crowd? It may be because of control and/or money, because, ultimately there is much to be had in certification programs and courses from a community hungry to see itself legitimised against others like Project Management.

M

This is who we are?

Maria Murphy has published an article in the Business Analyst Times on the role vs. discipline definition debate currently occurring in the BA-space. It’s a thought provoking piece motivated in part by my comments on Jesse James Garrett’s IA Recon essay.

As someone who has recently been walking in BA-shoes, I’ve had many discussions with Maria on the issue of certification, standardisation, role, discipline and community. Various groups like IIBA are now popping up and suggesting that they will bring clarity to the market if only you join them, get certified as a BA, and adhere to their view of what a business analyst is and does. I’m wondering whether steak knives comes with the package.

So long as the discussion continues as a healthy debate and not a means for arbitrarily defining business analysts by one organisation’s “body of knowledge” (because BAs are certainly more than just their BABOK) it will continue to challenge the way BAs think about what they do, who they are, and how they can communicate it to others. Maria puts the whole debate into perspective when she says, simply, don’t box me in:

“In short, as a business analyst I do lots of things. Don’t put me in a box or label me and don’t predefine what I do … it limits the possibilities for my involvement to add value within projects, between projects, across programs and across the enterprise.”

Perhaps, in the end, it’s not about resolving the grey, but communicating what we business analysts do know about ‘this is who we are’.

M

The “Just Do It” (with users) methodology!

Stephen Collins has written an interesting commentary on iterative IT project methodologies with an interesting and heated discussion following.

In my experience, the approach Stephen talks about has a lot of advantages over traditional methods of handing systems design and development. While traditional approaches can lack innovation and be slow to progress change, an iterative approach can reduce risk by being more responsive to change and result in quicker time to launch. Dominic Campbell even suggests that the eternal beta should be embraced, iterating and improving system design once released to users.

I was recently involved in a project where we used an iterative design and analysis phase. It certainly worked better than some of the slower-moving approaches I’ve been involved with before — it freed the team to try new things and new approaches to difficult problems see if they worked. If they worked, then they were handed over to the developers. If they didn’t work, they were discarded with minimal time lost.

Of importance throughout this process, though, was a user-centred design methodology. So as to not overwhelm users, we only exposed them to things that were improvements to what they had seen earlier, or things that would directly affect them and their work. We showed them storyboards and prototypes (both wireframes and high-fidelity HTML mockups) and involved them in helping to improve the concepts. This was great for change management as it helped to set expectations about what they were getting and how it would look and feel. It also meant, given they were involved in design, they had greater ownership of the final product. And once they were happy with what ever iteration we had collectively come up with (in this design phase and not in production), we then folded it into the development cycle.

Ultimately, this meant that we could really only move as fast as users could consume new information. The result, though, was a final product was tailored to their wants and needs and not the whims of developers who want to try out something new on an ignorant public.

M