Monday, April 30, 2012

The changing nature of use cases

It might be just me but I have detected a subtle, but significant, change in the meaning of the term use case of late. Something I have found I've been going along with but not without feeling slightly uncomfortable whilst doing so. The two definitions I've always used for use cases, namely a business use case and system use case come from Alistair Cockburn's excellent and pretty much definitive guide: Writing Effective Use Cases (shame on you if this is not in your library).
"A business use case is one in which the design scope is business operations. It is about an actor outside the organisation achieving a goal with respect to the organisation. The business use case often contains no mention of technology, since it is concerned with how the business operates.
A system use case is one in which the design scope is the computer system to be designed. It is about an actor achieving a goal with the computer system; it is about technology."
For a discussion on the differences see this blog post. Ivar Jacobson, the person who pretty much invented the term 'use case', defines it in the following way:
"When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case."
The way in which I am increasingly seeing use case being used is in a more informal, or less precise way, which is best described in terms of how I actually hear them being used. Here are some examples:

"I need to understand the use case(s) for how we would use that product."
"Is that a use case our operations people would support?"
"We need to run some use cases through that solution to test out some of the assumptions."
"That use case calls for a larger number of users than we had envisaged."
In all of these examples the term 'use case' is pretty much synonymous with the term 'requirement'. The scope may be a product, a system, a solution or an organisation and the actor may or may not be clearly identified. The use cases may imply some function of those entities or some quality (such number of users in the last example above).

Does this matter? At first the purist in me said it did. A use case has to have a well defined actor and a clearly stated set of 'steps' that actor performs when interacting with the system or organisation. However on reflection I've become slightly more relaxed about it on the basis that:
  • Any term which becomes a common, de-facto currency of understanding is better than not having one.
  • Adding the prefix 'system' or 'business' still gives us the more formal definitions most architects (business, solution or application) would recognise) so why not relax the use of the term when it does not have one of these prefixes?
Entering into the spirit of this 'relaxed' use of the term here are a set of use cases I've recently used when trying to articulate some of the uses of 'Big Data'.This maps use cases onto two of the three so called "Big Data 3-V' framework" (velocity, variety and (missing on here) volume).
Each of the boxes represents a 'use case' (no prefix) which has an informal description as in the following example.
Use Case: Social media analysis: Although basic insights into social media can tell you what people are saying and how sentiment is trending, they cannot answer what is ultimately a more important question: Why are people saying what they are saying and behaving the way they are behaving? Answering this type of question requires enriching the social media feeds with additional data residing in other enterprise systems. In other words, linking behaviour, and the driver of that behaviour, requires relating social media analytics back to traditional data repositories.
In the traditional context of a business or system use case this could be decomposed into a number of these more detailed and precise types of use case. What it does do however is provide a basic scope for such a further, more detailed, analysis to be performed.

Monday, April 23, 2012

What does IBM's PureSystem announcement mean for architects?

On April 11th IBM announced what it is referring to as a new category of systems, expert integrated systems. As befits a company like IBM when it makes an announcement such as this, a fair deluge of information has been made available, including this expert integrated systems blog as well as an expert integrated system home at

IBM says expert integrated systems are different because of three things: built-in expertise, integration by design and a simplified experience. In other words they are more than just a static stack of software and hardware components - a server here, some database software there, serving a fixed application at the top. Instead, these systems have three unique attributes:
  • Built-in expertise. Expert integrated systems represent the collective knowledge of thousands of deployments, established best practices, innovative thinking, IT industry leadership, and the distilled expertise of solution providers. Captured into the system in a deployable form from the base system infrastructure through the application.
  • Integrated by design.  All the hardware and software components are integrated and tuned in the lab and packaged in the factory into a single ready-to-go system. All of the integration is done for you, by experts.
  • Simplified experience. Expert integrated systems are designed to make every part of the IT lifecycle easier, from the moment you start designing what you need to the time you purchase, set up, operate, maintain and upgrade the system. Expert integrated systems provide a single point of management as well as integrated monitoring and maintenance.
At launch IBM has announced two models, PureFlex System and PureApplication System. IBM PureFlex System provides a factory integrated and optimized system infrastructure with integrated systems management whilst IBM PureApplication System provides an integrated and optimized application aware platform which captures patterns of expertise as well as providing simplified management via a single management console.

For a good, detailed and independent description of the PureSystem announcement see Timothy Prickett Morgan's article in The Register. Another interesting view, from James Governer on RedMonk, is that PureSystems are IBM's "iPad moment". Governer argues that just as the iPad has driven a fundamental break with the past (tablets rather than laptops or even desktops), IBM wants to do the same thing in the data center. Another similarity with the iPad is IBM’s push to have application partners running on the new boxes at launch. The PureSystems site includes a catalog of third party apps customers can buy pre-installed.

What I'm interested in here is not so much what expert integrated systems are but what exactly the implications are for architects, specifically software architects. As Daniel Pink says in his book A Whole New Mind:
"...any job that depends on routines - that can be reduced to a set of rules, or broken down into a set of repeatable steps - is at risk."
So are expert integrated systems, with built-in expertise and that are integrated by design, about to put the job of the software architect at risk?

In many ways the advent of the expert integrated system is really another step on the path of increasing levels of abstraction in computing that was started when the first assembler languages did away with the need for writing complex and error-prone machine language instructions in the 1950's. Since then the whole history of computing has really been about adding additional layers of abstraction on top of the raw processors of the computers themselves. Each layer has allowed the programmers of such systems to worry less about how to control the computer and more on the actual problems to be solved. As we move toward trying to solve increasingly complex business problems the focus has to be more on business than IT. Expert integrated systems therefore have the potential (and it's early days yet) to let the software architect focus on understanding how application software components can be combined in new and interesting ways (the true purpose of a software architect in my view) to solve complex and wicked problems rather than focusing too much on the complexities of what middleware components work with what and how all of these work with different operating systems and computer platforms.

So, rather than being the end of the era of the software architect I see expert integrated systems as being the start of a new era, even an age of enlightenment, when we can focus on the really interesting problems rather than the tedious ones bought about by the technology we have inherited over the last six decades or so.

Wednesday, April 11, 2012

Choosing what to leave out

In his book Steal Like an Artist, Austin Kleon makes this insightful statement:
"In this age of information abundance and overload, those who get ahead will be the folks who figure out what to leave out, so they can concentrate on what's really important to them. Nothing is more paralyzing than the idea of limitless possibilities. The idea that you can do anything is absolutely terrifying."
This resonates nicely with another article here on frugal engineering or "designing more with less". In this article the authors (Nirmalya Kumar and Phanish Puranam) discuss how innovation is meeting the needs of the Indian marketplace, where consumers are both demanding as well as budget constrained and how “the beauty of the Indian market is that it pushes you in a corner…it demands everything in the world, but cheaper and smaller.” This article also talks about "defeaturing" or "feature rationalization", or “ditching the junk DNA” that tends to accumulate in products over time.

As an example of this the most popular mobile phone in India (and in fact, at one point, the bestselling consumer electronics device in the world) is the Nokia 1100. The reason for this device's popularity? Its stripped down functionality (ability to store multiple contact lists so it can be used by many users, ability to enter a price limit for a call and built-in flashlight, radio and alarm) and low price point make it an invaluable tool for life in poor and underdeveloped economies such as rural India and South America.

For a software architect wishing to make decisions about what components to build a system from there can often be a bewildering set of choices. Not only do several vendors offer solutions that will address the needs there are often many ways of doing the same thing, usually requiring the use of multiple, overlapping products from different vendors. All of this adds to the complexity of the final solution and can end up in a system that is both hard to maintain as well as difficult, if not impossible, to extend and enrich.

Going back to Austin Kleon's assertion above, the trick is to figure out what to leave out, just focusing on what is really important to the use of the system. In my experience this usually means that version 1.0 of anything is rarely going to be right and it's not until version 2.0+ that the fog of complexity gradually begins to lift allowing what really matters to shine through. Remember that one of my suggested architecture social objects is the Change Case. This is a good place to put those features of little immediate value, allowing you to come back at a later date and think about whether they are still needed. My guess is you will be surprised at how often the need for such features has passed.