Business Context for Architecture – Using the Right Term? 

In 2004 we published an article in IEEE IT Professional titled ‘Defining Business Requirements Quickly and Accurately’. In hindsight we probably should have called it ‘Defining the Business Context for Architecture’.

Eleven years have passed since this article, but we believe that the key tenets of the article are still valid. But have the terms of the IT industry changed? In particular, I am interested in views on use-cases vs. user stories.

In 2004 we used the concept of use-cases to define how we can provide a dynamic view of the business. However, these days though the term use-case is quite widely used, we believe that it has lost its core meaning. Similar to Kleenex and Xerox – the brand is so successful that it is used to represent something more general than originally intended.

Do we really find many software development teams that create use-case models and write use-case descriptions – probably not. Instead everyone is focused on user-stories and agile development, or at least pretends to be. According to Wikipedia a user story is defined as:

“In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.”

The challenge with this is the scope of a user story. A few sentences are a great way of documenting requirements on an index card; but are they sufficient to operate at a larger scope? We address this by  grouping user stories into themes, or what we call user story themes.

So, should we still use the term use-cases or switch to user story themes? Let us now present our key idea about providing business context to an architecture to illustrate our point.

The first step in the developing an architecture is to understand the functional scope of the product or project we are building. We use value chains to better understand and describe this functional scope. The objectives of developing a value chain are to:

  • Understand the “why” and “what” of the business. Why are we in business? What are the core activities that provide value to our clients and us?
  • Understand the “how” of the business. How do we actually execute within the core activities of our business?
  • Understand the “whom” of the business. Who are the internal and external users of our technology?

The role of the “Value Chain” is to depict activities (“chevrons”) of the Enterprise that are involved in generating value, as well as the supporting areas. The following example depicts a sample value chain for a loan servicing organization.

Value Chain

A value chain provides an overview of the business by depicting major processes that collectively generate value for the organization and its clients. A value chain is a long lasting view of the business. As long as the core business does not change, the same value chain can be used by the organization for years. One of the first authors to introduce the Value Chain concept was Michael Porter in 1985.

The value chain is great at setting the high level context, but to drive architectural definitions we want to animate the value chain. For this in 2004 we proposed using use-cases, which was first introduced by Ivar Jacobson in 1992. For the rest of this blog we will put “use-cases / user story themes”, in place of where we had use-cases.

Let’s use the loan servicing organization from our previous example to further expand. We know from the value chain that the first two chevrons are Loan Application and Funds Disbursement. But what actually happens and who is involved in these activities? We can get this information by looking at the “use-cases / user story themes” for each chevron.

Value Chain and Use Case

As can be seen from the above diagram, we now know more about how our business operates. We have determined three main events (Apply for Loan, Disburse Loan and Pay Fees), which we will call “use-cases / user story themes”, and eight roles (Applicant, Guarantor, Lender, Credit Bureau, Core Processing, Loan Origination, Servicing and Designated Recipient), which we will call actors. The “use-cases / user story themes” tell us the “how” and the actors the “who” of the business.

Going back to our Loan Servicing Organization, we find that we have five external actors, the Applicant, Lender, Guarantor, Credit Bureau and Designated Recipient. From this we can understand the core business revolves around connecting three of these actors, the Applicant, Lender and Guarantor. We can also infer that the organization in question is not a lender itself, but acts as a broker between the lender, the applicant and the guarantor of the loan.

We can go further and create a high-level sequence diagram outlining the major components that will be involved in the ‘“use-case / user story theme”:

Sequence diagram

This sequence diagram highlights the need for one major system for Originations and two supporting components; an Imaging Service and a Formatting Service. You can see that we have started making architectural decisions already in the process of drawing a sequence diagram. When we make decisions on such matters it is not usually in confines of one sequence diagram, but across the breadth of the overall architecture. Other sequence diagrams we would have developed would have pointed out a need for common services such as the Imaging and Format services.

Now that we have provided a brief overview of how we want to animate the value chain, we can come back to our question.

Should we stick with the concept of use-cases? I believe that use-cases provide an excellent approach to identifying scope and keeping the focus on the end user. However, will the term be misunderstood?

Or, should we acknowledge the relevance of user stories and group them into user story themes?

Finally, does it really matter? You might say one challenge with the software industry is that we keep on re-inventing the wheel and leave behind key lessons at each ‘iteration’ of fashionable terms.