What Does Business Analysis Really Mean
Listen to this article
Many years ago now I read the first edition of About Face by Alan Cooper. At the time, Dave and I were working on an HR application which was subsequently sold to a another company and is still being sold and (I presume) used, today.
Not to ding my own chain (much!) but it still rates as one of the best apps I've ever built. I'm sure if I looked at the source code these days I would whince but I still think we made some pretty good technical achievements. However technical merit aside the one thing that really made an impression on me and continues to make an impression was the usability of the application. Not only in terms of business functionality but also the way it simplified the way users performed their day to day tasks.
Alan Coopers most excellent insights were enlightening to me at the time and certainly influenced a lot of the design. But I can't take credit for the usability nor functionality of the application. No for that we have Dave to thank. Besides having a brain the size of a planet, he is an exceptional business analyst. "Oh we have really good business analysts" I hear you cry. I'm sure you do in which case you'll appreciate my definition of a business analyst.
Picking on Dave once again, he has an amazing ability to actually analyse a business. By this I mean try to really understand what the customer does; Why they do it; Determine if their current business practices even make sense; How their shiny new software might actually make their life easier; and; most importanty to convey to (AKA convince) the customer why his ideas will work. I've heard of CEOs walking away from meetings asking their staff how this guy knows so much about their business. And I know for a fact that he had very little prior knowledge. He just knows how to ask the right questions to get to the heart of their business.
Traditionally (though I have little data to suggest this isn't still the norm) business analysts will sit with the customers and essentially document what the customer does. Workflow, day to day tasks, etc. From this they then write story cards or use cases (whatever is flavour dejour) that form the basis of the application design. These then go to the developers who consult with the customers on what exactly needs to be done, screen designs, etc. and then off they go to build the software. Unfortunately, the net result is usually a computerised version of some ancient manual system that is barely better than what they had and in many cases worse!
Maybe it's because the skills of which I write are rare but I'm not sure where the notion that customers should design the software comes from . The idea that customers know what they need (or even want) is just plain ludicrous. In most cases, business people understand what drives their business. They understand what their competitive advantage is and where they could gain new business if only they could do X or had Y. Surely it is the BAs job, nay duty, to come up to speed with the business and from that explain to the customers what would make their life easier. Surely that is where BAs add value. They understand software AND the business.
Even as a developer, I see it as my responsibility to go and talk to the BAs and customers if I see inconsistencies or if I think the application flow or business rules can be improved. I'm sure their are those who wished Id shut up sometimes but I still think it's worth it. Which brings us right back to where we started. It's very rare that the end users can design a piece of software that actually does what they need but it's equally as likely that developers will, on their own, design totally unusable software. So go read the book :-).
Oh, and this paper if you have the time.
Comments
Re: "[Story cards or use cases] then go to the developers who consult with the customers on what exactly needs to be done, screen designs, etc. and then off they go to build the software. Unfortunately, the net result is usually a computerised version of some ancient manual system that is barely better than what they had and in many cases worse!"
From the book "Streamlined Object Modeling", on analyzing an existing process (p.6):
"The worst thing to do with these people is to talk about users and user scenarios, because that tends to bring focus on how the old system worked, not what the real underlying business process should be. To get them out of the trees and seeing the forest requires modeling the process and its goals. Only by concentrating on the objects involved and the goals of a process can clients see the flaws in the process and possible solutions."
And in a footnote to that paragraph:
"Building use cases before object modeling focuses attention on how things are done now instead of what needs to be accomplished. The result is often a continuation of poor processes..."
From page 5:
"Object modeling addresses the "what" of the business; its concern is only with what is to be built, never why or how. Prior to the object modeling session, a good object architect inquires about the "why" questions, and raises a red flag if no one at the client site knows the answers. Clients not clear on their strategy are not ready to discuss what they want to build."
The problem (as I see it) is that people don't recognize the difference between Business Analysis (or Domain Analysis) and Application Analysis. They jump right to App Analysis.
Recently, Eric Evans' book "Domain Driven Design" has been doing some consciousness-raising on the topic of domain modeling, which is good. Too bad that book has some serious flaws running throughout it.
Posted by: Doug | August 12, 2004 02:43 AM
Great point. I think software processes and organizations should spend more time empowering their developers to develop extensive domain knowledge. Sending them to the same training classes or having them shadow a business user for a day or two is typically how this is done when it is done.
I think a much more effective way to do it is ask the business "who'se your person most familiar with X" (where X is loan processing, the store inventory, the benefit's process, whatever the business domain is). Find the person who'se the "whiz" on the business side and put them in a room with the developer for an hour or two. The useful knowledge imparted in that session will likely far exceed what could be given to the developer in an all day corporate training session on X.
Find the outspoken business people with a strong opinion about the current system/process and talk to them. It's an invaluable perspective.
Posted by: Rob Meyer | August 12, 2004 04:01 AM
I could absolutely not agree more. Great points! I find it saddening to see how some companies employ large body shops of programmers, and keep them locked in a vacume, instead of employing a smaller number of application developers who understand both business and technology.
Posted by: Keith Donald | August 22, 2004 01:00 AM
Good article, come across these issues all the time!
You might be interested in our white paper, "What is a Business Analyst?", available from http://www.irmtraining.com.au/papers.htm
Posted by: Phil | September 11, 2006 02:22 PM
Thanks for the article.
I would ask what’s wrong with looking at the processes as they are pre build. There could be significant reasons for many sub tasks that senior management is not aware of due to their distance from the coal face. I think I am agreeing with you when I say you should analyse the processes and the rest of the relevant attributes (like performance indicators, reports, job roles, etc) when preparing to design a new system.
I may be disagreeing with you when I suggest that automating existing business processes is not necessarily a refection of bad design. Often it is done because the complexity of the environment is too hard and dynamic to lock down. Businesses take the easier and potentially less risky path of automating what they are doing today. Process improvement can be captured in the next round of software development. It’s done this way because the right people, money and time is not available for delivering the perfect solution.
That’s where the BA comes into her own; she should be working with the business, the project manager and the designer/architect to help identify when and where compromises such as these should be handled.
Cheers
Craig
http://www.betterprojects.blogspot.com/
Posted by: craig brown | March 12, 2007 09:22 AM
To most people reading this page, this will just be 'common sense'. Why is it that companies, and well I guess management, (at least as far as my experience in Australia is concerned) don't recognise this?
Posted by: Jacob | February 5, 2008 10:39 PM