When we are building a brand new solution, we have to figure out the information components that are needed. Let us suppose that we have a high level e-business requirement as follows:

A customer needs to submit a document on-line. This gets reviewed by an internal agent, who either accepts it or tells the customer what’s wrong and asks them to resubmit.

What information components are needed to support this requirement? Here’s how I think about it; if you want to, pause to see what you think might be needed.

First, I do the happy case first of all, the one with no errors.

• The customer submits a document. This is two pieces of information; first the document, then the fact that they have submitted it. The submission indicates who the customer is, a pointer to the document they submitted, and a time stamp.
• By customer, I assume a logged in user, so we will need an information component called customer. If the document submission is part of a multi-step application, we might also need a component called application.
• Over to the agent. The agent gets notified of the document submission. There could be multiple submissions in play from different customers, so let’s assume for now that there is a container for document submissions which we’ll call a work queue. Later, we’ll need to explore details of how this is displayed and how an agent takes a submission off the queue for processing. Right now, we know the work queue will indicate the agent, the date they started to handle the submission, and a pointer to the submission.
• Hmm, just realized we’ll need an information component for agent. Let’s defer escalations and supervisors for later.
• The agent (somehow TBD, we are not doing UI, yet) looks at the document, deems it OK, approves the submission, and marks the work queue item as complete. Now that the document has been approved, we might want to store it somewhere permanent, lets say a component called customer documentation.
• The system may generate an email. It’s good if email boilerplate is not hard coded deep in the system, but is stored in an information component called email boilerplate.

Then I do the error cases:

• The agent looks at the document, and realizes there is a problem. It would be nice if there were a fixed set of problems that they could choose from, with associated online and email messaging. We will need a structure for the problems.
• The agent specifies the problem and rejects the submission. This also closes the work queue item. We will like to record the fact that the submission was rejected. Often the customer will be doing other things than submitting documents, so we often have a customer history log showing all interactions with customers.

So that’s what my first pass looks like. Some of this is based on looking at the nouns and verbs in the requirement; some is recognizing that this is common pattern that I worked with before.

Have I finished? Not at all, just started. But it’s a good first step.

The Information Artichoke Home Page   |  Modern IA Course Table of Contents