Documenting Business Requirements

A couple of questions came in on my phone, and I thought I'd share my answers here.

When is a Business Requirements Document good enough?

 

Here are a few considerations to start with

Fit for purpose - What is the document going to be used for - planning, estimating, vendor selection, design or whatever? Does it contain just enough for this purpose, or does it dive (prematurely) into solution design or technical detail?

SMART - are the requirements specific, measurable, and so on, or are they just handwaving? How will you know when (if) the requirements have been satisfied?

Transparency and governance - is it clear whose requirements are being prioritized (FOR WHOM)? Who wrote it and what is their agenda? (Documents written by a vendor or consultancy may suit their interests more than yours.)

Future-proof - are these requirements short-term and tactical, are all the urgent requirements equally important?

Complete - ah, but what does that mean?

When is a Business Requirements Document complete?

Scope completeness - covering a well-defined area of the business in terms of capability, process, org structure, ...

Viewpoint completeness - showing requirements across all viewpoints - people, process, data, technology, ...

Constraint completeness - identifying requirements relating to privacy, security, compliance, risk, ...

Transition plan - not just data migration but also process change, big bang versus phased, ...

Quality and support plan - verification, validation and testing, monitoring and improvement. What is critical before going live versus what can be refined later.

RAID - risks, assumptions, issues and dependencies 

Important note - this is not to say that a business requirements document must always be complete in all respects, as it's usually okay for requirements to develop and evolve over time. But it is important to be reasonably clear about those aspects of the requirements that are assumed to be more or less complete and stable within a time horizon appropriate for the stated purpose, and to make these assumptions explicit. For example, if you are using this document to select a COTS product, and that product needs to be a good fit for requirements for at least n years, then you would want to have a set of requirements that is likely to be broadly valid for this length of time. (And avoiding including design decisions tied to today's technology.)

Conversely, where the requirements cannot be pinned down at this stage, it is important to avoid making premature solution decisions based on optimistic assumptions. There may be a general requirement for flexibility in some areas. 

Quality and Responsibility

One of the key challenges with shared data and shared services is the question of data quality. Who is responsible for mistakes?

@tonyrcollins raises a specific example - who's responsible for mistakes in summary care records?

"NHS Connecting for Health suggests that responsibility for mistakes lies with the person making the incorrect entry into a patient's medical records. But the legal responsibility appears to lie with the Data Controller who, in the case of Summary Care Records, is the Secretary of State for Health."

From an organizational design point of view, it is usually best to place responsibility for mistakes along with the power and expertise to prevent or correct mistakes. But that in turn calls for an analysis of the root causes of mistakes. If all mistakes can be regarded as random incidents of carelessness or incompetence on the part of the person making the incorrect entry, then clearly the responsibility lies there. But if mistakes are endemic across the system, then the root cause may well be carelessness or incompetence in the system requirements and design, and so the ultimate responsibility rightly lies with the Secretary of State for Health.

Part of the problem here is that the Summary Care Record (SCR) is supposed to be a Single Source of Truth (SSOT), and I have already indicated What's Wrong with the Single Version of Truth (SVOT). Furthermore, it is intended to be used in Accident and Emergency, to support decisions that may be safety-critical or even life-critical. Therefore to design a system that is vulnerable to random incidents of carelessness or incompetence is itself careless and incompetent.

What general lessons can we learn from this example, for shared services and SOA? The first lesson is for design: data quality must be rigorously designed-in, rather than merely relying on validation filters at the data entry stage, and then building downstream functionality that uses the data uncritically. (This is a question for the design of the whole sociotechnical system, not just the software architecture.) And the second lesson is for governance: make sure that stakeholders understand and accept the distribution of risk and responsibility and reward BEFORE spending billions of taxpayers' money on something that won't work.

EA Joke or Joker 2

I hope I made it clear in my previous post Enterprise Architect - Joke or Joker that I am not attacking all enterprise architects, or the concept of enterprise architecture (EA). I think there are many excellent practitioners of enterprise architecture, as well as some who don't deserve the job title at all.

In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).

There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.

Stafford Beer introduced the concept of POSIWID - the purpose of a system is what it does. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA.

Are people still playing Framework Bingo? Brenda Michelson suggests a quick poll: What does your enterprise architecture group deliver? (Go direct to poll)

• Standards and policies?
• Reference architecture?
• Proof of concept?
• Reference implementations?
• Business solutions?
• Forums or communities?
• Other?

(These different types of deliverable can be associated with different personality types or astrological symbols. In ancient Chinese symbolism, support networks and infrastructures are associated with Earth, rigorous conceptual frameworks can be associated with Metal, and actually building things is associated with Wood. Motivation is Fire and insight/inspiration is Water. Water feeds Wood, Wood feeds Fire, and so on.)

James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.

• Does federated identity enable better security for your business partners?
• What is the quality of source code within the enterprise?
• Is the enterprise architect participating in user group meetings that help propel the ecosystem forward? Are we working for interoperability across the industry?
• How well managed is the enterprise spend? How much money is being spent on compliance? Is this strategic investment being leveraged for other purposes?

But even if we can build a comprehensive measurement framework from such a collection of questions, this still leaves an important question - are we judging the success of enterprise architecture within an organization, or are we judging the success of the whole organization in using and leveraging enterprise architecture?

Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.

The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.

Flight from Quality

TIBCO (TIBX:NSQ) shares soared in December, following impressive financial results. This week they have fallen to a 52-week low, following a Sell advisory from Goldman Sachs (Euro2day via Tim Bass). Goldman Sachs analyst Derek Bingham predicts a flight from quality.

Customers will move away from buying more expensive “best-of-breed” offerings, like Tibco’s products, and more toward buying less expensive “good enough” substitutes that are bundled with broader solutions from the likes of IBM, Oracle Corp. and SAP AG.

This is not about whether TIBCO has the best products, but about the buying behaviour of TIBCO's customers.

The SOA mantra of Loose Coupling works both ways here. On the one hand, greater standardization and interoperability could mean there is less reason to buy everything from a single supplier, and so “best-of-breed” offerings become more viable, even during an economic downturn. On the other hand, some companies may feel that it is less critical to get the highest quality infrastructure from the beginning, since greater flexibility makes it easier to contemplate changing things later.

The traditional economics of the software industry has generally favoured the giants, which is why IBM and Microsoft have seen off so many rivals. Meanwhile, the ecology of SOA favours diversity and heterogeneity. Traditional investors such as Goldman Sachs and its Wall Street clients may not appreciate this yet. The important question for TIBCO and other niche vendors is the extent to which the economics of SOA can overcome the economics of software.

Update and Correction

The TIBCO shareprice recovered on January 16th, and has risen further since, perhaps helped by buy-out speculation following Oracle's acquisition of BEA.

But Tim and I were misled by the original story (apparently from Thomson Financial) linking the shareprice fall to the Goldman Sachs advisory. According to Yahoo (another company that knows something about buyout speculation!), the Goldman Sachs advisory was last April.

I stand by my original point, however, that stock market investors and city analysts don't necessarily appreciate the economics of SOA.