Recently I attended the Business Analysis Conference in London that I spoke about in my previous post.
My reason for being there was I accepted an invite to be a speaker on a panel discussing “The Role Of The BA: What Is Expected And What Is Delivered”
Part of the Business Analysts role is to capture, distil and communicate business requirement to Technical staff so it was of great relevance that I played my part as the technical representative on the panel. If technical staff are to understand business requirement completely then there is more of fighting chance that a technical solution will meet business need. This ultimately is the mutual goal that all on a project team are working towards.
So my role on the panel was to give the technical perspective. What I learnt was a greater understanding of the Business Analysts perspective and what technical staff can do to help them, which inturn will help ourselves.
So the lessons are,
> No such thing as Users - There is no concept of a ‘side’ any more, no ‘us' and ‘them’, no ‘users’, just equals with different roles and specialism's making up the collective that is your organisation. The key is understanding your part in making your organisation successful. Remembering that is better that roles overlap slightly, just like cogs, because this means closer relationships and better understanding. Friction can come when one role over overlaps the other to much.
> Everyone has an important part to play - No role is actually more important than another. The confusion comes because the output of a BA’s role isn’t as tangible as a piece of software or hardware so there is a squeeze as a BA’s can be seen as the ‘middle-men’, and who needs them right?
“Just get the Business to talk to the Developers!?” is all too often heard in barbed jest. In reality if that did happen both the Business person and the Developer would have to step out of their roles into another, the Business Analysts!
The Developer and Business person would have to look at business process holistically and objectively, never of which may have the requisite skill to be able to do that. For instance, see all the influences both internal and external to the process, group, organisation etc, see how it fits in with the other roles that depend upon it, workout where the role has to go in the future inline with the organisations roadmap and then figure out the steps of change that is going to happen to that role and those dependent on it. When put like that it is a big ask and this is why some businesses are able to adapt to change with ease and others that do not.
You could argue that the person best placed to make change to business process if the process owners and managers of that process? But I would argue that they are first and foremost experts in operating the process, they aren’t going to be objective are they? Can you see them reducing scope, or even putting themselves our of a role?
> High time for technology to join the pace of business change and not set it - Technology is at the forefront of business, it really is how business does business. In recent years business has changed dramatically because of the pace of technology. However Technology does run the risk, from time to time, of running away with itself and introducing change to technology with little to no real priority business benefit. In these cash strapped time, it is important to spend money on what is really needed to keep the organisation running.
Yes it is important to protect business and have supported versions of software fully patched, service packed and well maintained. But the criticism is that some new versions of software seemingly add little new real beneficial innovation to benefit business that will warrant the upgrade from the previous version, or even a few versions before. So then, it is understandable that organisations look to staying on a version of software for as long as they can. Microsoft Word and Excel are great examples of this, how many feature do you use everyday that weren’t in the 97 version?
> Who codifies business logic may not be a developer – I met a few BA at the show that admitted to codifying business logic using tools such as BPM software, workflow or even bespoke. In some organisation there are now groups that just codify business logic. The groups are made up of ex-developers, people from business and business analysts. To add to this I did meet a few BA’s that instead of documenting a process diagrammatically, killed two birds with one stone by using a piece of software that not only displays business logic diagrammatically but executes it as well.
Standards such as BPEL and BPMN tools are firmly taking business logic codifying away from developers and into the hands of peoples who roles are closer to business processes. It is becoming a specialised function taking on a life, or rather role(s) of its own.
Logically you can imagine developers not being to happy about this but on reflection the role of the developer is itself fracturing into specialisms and has done so for many years. For example web-developers and database developers are look at as being poles apart so it is not too far to imagine business logic development being at an extreme itself.
> Technical Architecture isn’t the only IT born role that struggles for professional recognition, Business Analysis does as well. Perhaps but surprisingly Business Analysis are asking the same questions as Architects, should there be some sort of certification from a professional body? If so, which one?
These are logical questions for a maturing role but in my opinion Technical Architecture certainly isn’t mature enough and I suspect that Business Analysis may be the same. But without recognition then both roles will struggle? I’m not sure of that either, I think as time goes on more organisations will discover the value of Business Analysis and Technical Architecture but only as long as we produce good works and add value and bodies supply what BAs and TAs need, represent them and co-operate with each other.
I also believe that BA and TA roles will continue to evolve, I suspect that the roles that are eventually mature enough for certification will be very different from the roles we have now. That will happen when we have enough tools and good practice to be able to handle any change, enough to be able to measure, quantify, qualify and guarantee in a fashion that you will take responsibility for any failures. Yes we are along way off.
But the synergies between BA and TA are too numerous to ignore, so it would be to mutual advantage to realise and take advantage.
I believe the future is very bright for Business Analysis as long as there is people that are will to give their time and effort in looking after it and promoting it but is that enough? I don’t have an answer to that but as David Taylor the author of the best selling book The Naked Leader, said at the conference, the formula for success is easy! …
1) Decide on your goal
2) Work out where you are now
3) Work out the steps you will have to take to reach your goal
4) Do it!
… and this is exactly what the IIBA & BCS are doing!