A less known but highly essential artifact of business architecture is the business use case model.
A business use case (hereafter referred to as BUC) model is the higher abstraction of the system use case model (or simply, the UC model). In a BUC, business actors with specific business goals interact with other business actors. The BUC is primarily an external view of the business model or area of interest. A system use case diagram, on the other hand, illustrates the domain from an internal point of view.
A BUC diagram is a type of behavior diagram according to the Unified Modeling Language (UML).1 Other examples of behavior diagrams are the interaction diagram, activity diagram, and state machine diagram. The other type of diagram is the static diagram which includes the class diagram, object diagram, component diagram, and deployment diagram.
How can a BUC model help a business architect? The BUC model is a useful starting point and helps facilitate conversations related to a scope of an idea or a project among business and technical stakeholders. It is an excellent tool, for example, in gathering and eliciting business requirements that meet a particular business need or pain point without specifying how to meet that need. Business requirements are not necessarily system related. System requirements are mostly functional, which include data and system inputs or outputs. Other types of system requirements are non-functional, which include quality, security, and availability.
What, therefore, differentiates the BUC from system related requirements specification is that it is tied directly to the business. The easiest way to tie a requirement to the business and not to system or IT concepts is to align requirements with common business architecture concept such as a business capability or a value stream. Using these common business architecture concepts as a point of reference reinforces the business-centric nature of the BUC requirement. One example may be a specific requirement to add a Customer Portfolio Management capability that has a BUC specified set of requirements and attributes.
Where can a BUC model best contribute value? A BUC model is the business architect’s technique-of-choice when gathering and validating high-level business requirements. Tech-savvy business managers oftentimes have already a solution in mind when defining ideas for new product launches or process improvements. The danger with this approach is that it is too easy to miss business needs from other business stakeholders due to constraints inherent in a possible solution, whether technology-related or not. A more appropriate approach during a concept definition phase of a project is to provide an external view of the customer/client/citizen task goals within an area of interest without necessarily locking in to a particular implementation option. As mentioned, a possible solution may not even be technology-related.
Why is a BUC model important? It helps to identify the business requirements of a business stakeholder to achieve its goals as well as the requirements the stakeholder imposes on other stakeholders. A BUC model is helpful in identifying value streams and related business processes, business capabilities, and related pain points and problems that need to be addressed, as well as opportunities to be more effective and efficient.
What’s a good example of a BUC? Which elements make a BUC a successful one? You can view a sample BUC from the Cloud Council2 by clicking the link below. It illustrates the necessary elements and includes attributes such as UC name, version history, background, definitions, concept of operations (current & desired), primary actor/s, business goal, necessary conditions, priorities and risks, normal flow, and frequency of use. You can view additional examples of business use cases at the UML Diagrams website.3
Who creates and maintains the BUC model in a typical systems development life cycle (SDLC)? Business analysts create use case diagrams and use case specifications during the design or elaboration phase of a systems development project but mostly from the systems or internal point of view. They hand over their work to developers and quality assurance analysts during the development or execution phase of the SDLC. Typically, a business analyst refers to a business use case as input to the use case development process. From my experience, enterprise architects or business architects create a business use case model during the early stages of project initiation or conceptualization to document business needs and requirements. But this is more of a matter of convenience. In our organization, business architects are base resources and therefore can be engaged by a product or idea manager during the discovery phase and even before a project receives formal funding.
In summary, a business use case model is the business architect’s best friend in discovering quality high level business requirements.
Footnotes
- Ivar Jacobson invented use cases in 1986 to visually model functional (or system) requirements and it became a significant part of the Rational Unified Process (RUP) and UML.
- Cloud Council, Business Use Case, accessed on August 25, 2011
- Kirill Fakhroutdinov, UML Diagrams, accessed on August 25, 2011
