HarvardBiz and Use Cases?!? Yes, Seriously … And Seriously Misguided!
HarvardBiz The Case for Starting a Design Revolution http://s.hbr.org/nXsdOk
This article is fundamentally misguided. I’m surprised to find such an article associated with HBR. Use cases are about designing systems, not developing business solutions for business problems.
All change initiatives should start with a clear, structured view of business goals and business risks, and what business policies and business tactics will best solve the business business problem. I’m talking, of course, about business strategy. That’s the conversation that business leads want to have. Get them engaged in a discussion of system interaction and GUIs and you’ll inevitably miss the big picture.
What if your business *is* about eCommerce? No matter, you still need thought first given to business strategy — the goals, risks and policies needed for a winning business solution. Good requirements will flow naturally from that base. This have always been a notoriously weak area of IT requirements methodologies. Just don’t believe IT professionals who say use cases will solve your business problems. Design attractive systems, yes (done correctly). Guarantee business success? You’re counting on nothing more than good luck.
Tags: business strategy, HBR, IT methodologies, requirements, strategy, use cases
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
Putcha V. Narasimham
| #
Ron:
Your analyses and assessments are well reasoned and helpful but your impression of what a Use Case is or should be is off the mark, if I may say so. I know the importance you place on BIG Picture— business mission and strategy and the like but equally important are the contributing objectives, goals, sub-goals etc.
Though the UML definition of Use case is not sufficiently precise, it is quite clear that Use Case Diagram identifies all the Services System has to offer to its primary users. So each service, called Use Case, is associated with an Actor (user) and each Service has a Business Goal of value to the Actor. This is the Big Picture of the Business Served by the System showing the Business Goals of all its Actors individually (their interdependence and the means to serve them are NOT known at this stage). Clarity of Business Goals and the Dialogs Actors need to have with the System give shape & definition to the internal objects, their operations and interactions. All of them flow from the dialog data—Use Case Description. At this stage the UI is NOT taken up but all the Forms or Dialog Boxes, Fields within the forms, the nature of entries in those fields are all thought of and defined.
This is very systematic and elegant though all software developers do not appreciate and take advantage of this method. It is great someone NOT within IT has grasped the essence and glorified the concept and use of Use Case not only for IT but for non-IT applications. It is indeed very imaginative and profound.
Ronald G. Ross
| #
Putcha – You said “Though the UML definition of Use case is not sufficiently precise, it is quite clear that Use Case Diagram identifies all the Services System has to offer to its primary users”.
>>You’re exactly right — *system* services. But system services are not business solutions to business problems, and a user’s individual goals are not the business goals of the business. It’s a very big difference.
Milan Kratochvil
| #
I agree Ivar Jacobson’s approach gained its world-wide popularity mostly through system Use Cases, due to their benefits in specifying interactive products/appls. However, he also pushed business Use Cases, both during his years at IBM/Rational and earlier,
http://www.amazon.co.uk/Object-Advantage-Business-Re-engineering-Technology/dp/0201422891/ref=sr_1_3?ie=UTF8&qid=1315467663&sr=8-3
I’ve used the latter as a graphical index of BPs, instead of a traditional top-down process hierarchy diagram; it offered more expressive power in “interactive”, client-facing, parts of the business (front office, e-shops etc.).
That said, I doubt it will ever come near the popularity of system Use Cases; standards that approach the mix of text and diagrams from the rule angle (like OMG’s SBVR) are more likely to fit frames of reference of managers, and fit business automation tools like rule engines.
In my exp. it’s vital to be precise, ahead of every UC workshop, about the level of the UC agenda (Biz UCs – or System UCs). Businesses are increasingly good in distinguishing B(P)Models from system specs., except for (paradoxically) in Use Cases – those work as a two-way bridge between business and systems, which bring about both an efficient to-the-point communication, and a risk of blurring the roles and responsibilities involved.
John Russell
| #
“Use cases are about designing systems, not developing business solutions for business problems.”
I don’t understand this line of thought. The only reason a system is designed and built is to solve one or more business problems. Use Cases are currently the best way of describing the users experience (or point of view) in carrying out some meaningful (to them) piece of work – accomplishing some goal on the system.
If that goal does not contribute in some way to the mission of the business (organisation) then I would suggest that the issue is with the requirements themselves, not the method used to communicate them (use cases).
Ronald G. Ross
| #
@John – The question is not about use cases per se, or even requirements. The issue is how you create and model a busines solution to a business problem that can be used as a *starting point* for developing good requirements and well-aligned use cases. The business is in business to do business the best way possible, and then and only then to design systems. We’ve been looking at the problem the wrong way.