In order to move to more realistic systems, we will now introduce two higher-complexity examples: an air transportation service and a home information network. We’ll begin by identifying the functional intent expressed as solution-neutral function. We use intent to designate goals for a system. In order to reason about the architecture of a system, we need to understand something about the goals.

We will focus here on the functional intent derived from the primary need of the primary beneficiary. A more detailed and comprehensive approach to prioritizing stakeholders and goals derived from their needs will be presented in Chapter 11.

For the air transportation service, we’ll focus on the traveler as the primary beneficiary. The traveler’s primary need might be to develop business in another city by traveling to see a client. For our home data network, the primary beneficiary is the person using the network, whom we will call the surfer. His or her primary need might be to buy an interesting book online.

With the ingredients discussed so far, we are building a procedure for deriving a solution-neutral statement of a functional intent, which is summarized in Question 7a of Table 7.1. The procedure is as follows:

• Consider the beneficiary.

• Identify the need of the beneficiary you are trying to fill.

• Identify the solution-neutral operand that, if acted upon, will yield the desired benefit.

• Identify the attribute of the solution-neutral operand that, if changed, will yield the desired benefit.

• Perhaps identify other relevant attributes of the solution-neutral operand that are ­important to the statement and fulfillment of the goal.

• Define the solution-neutral process that changes the benefit-related attribute.

• Perhaps identify relevant attributes of the solution-neutral process.

The results of following these steps are shown in Table 7.2 for the air transportation service and home data network. These examples illustrate how carefully you have to think about the beneficiary’s needs in order to write a solution-neutral statement of goals.

In the first case, we have to understand that the traveler needs to visit another city. Visiting is a conceptually rich idea, which involves a traveler traveling to someplace, staying for a while, and returning. So the operand in this endeavor is the traveler. The value-related state of the traveler is location, and the value-related process is changing, which give us changing location of the traveler as the value function. Changing location can also be called traveling or transporting. It is also useful to know other attributes of the traveler (that the traveler is alone, with light luggage) and attributes of traveling (it needs to be done on demand and safely).

Here is a summary version of the solution-neutral function: “safely and on demand transporting to a new location a traveler with light luggage.” Note that we have not said anything about how the transporting happens. We are in the solution-neutral domain.

Table 7.2 also lists the results for the home data network case, where the surfer wants to buy a book. Book is the operand, and ownership is the value-related attribute. The other attribute has something to do with a book you want to read. Buying is the process of changing ownership by exchange of a good for money, and online is an attribute of how the buying will take place. The solution-neutral function is “buying online a book that the buyer likes.”

These solution-neutral functions become the functional intent of the systems. Meeting these value-focused goals will probably meet the need of the beneficiary and deliver value. There will certainly be other intents for the system based on secondary value delivery: the needs of enterprise stakeholders and so on. Examining all the influences that impact goals is discussed in Chapter 10, and the process of deriving a complete set of goals is presented in Chapter 11.

When the system operates, an interesting thing happens. The intent vanishes! When people fly in an airplane, it hard to tell why they are traveling. When we see a room of servers, it is hard to tell for what purpose these servers are being used. In designing a system, it is critical that the architect state the solution-neutral function. However, once a system is built, it can be difficult to determine what the intent is.

This may seem elementary, but this formalism captures a key idea: Intent is often discussed but rarely written down. Intent may be discussed casually in the hallway (“I thought we were building a retro-inspired minivan.”) or it may be the centerpiece of product concept renderings (“Here’s the artist’s sketch of our retro-inspired minivan.”). The architect must identify and record the main functional intent of the system and use it to guide design.

In summary:

• The functional intent for a system should be stated as a solution-neutral function.

• The solution-neutral function contains an operand and a process (and their ­attributes) that are linked to the delivery of value; It contains no reference to solution.