Page 27 -

12 HEVNER, LINGER, PLESZKOCH, PROWELL, AND WALTON
ies of the system can change, perhaps as mobile devices move in and out of range, the system’s
boundary, and thus its capabilities, can change over time.
The fundamental challenge is to identify stable, dependable anchors for system specification,
analysis, design, and implementation on which we can build a unified engineering discipline for
large-scale network system development. The Flow-Service-Quality (FSQ) framework provides
these anchors (Hevner et al., 2002; Linger et al., 2002). The FSQ approach does not solve all these
problems; rather it provides a rigorous framework with which to understand and reason about
such systems. In the remainder of this chapter we introduce the FSQ approach and its underlying
framework and semantic model as a discipline for engineering complex, network-centric systems.
A central concept in this discussion is the treatment of mission task flows of system service uses
as first-class artifacts for specification and design under intellectual control, despite the structural
and functional uncertainties that characterize large-scale network systems. Other methods that
focus on component and architecture specification and design often lose sight of the mission-
driven dynamic behavior that network systems are required to provide. FSQ engineering focuses
on dynamic flow behavior and provides a stable framework within which these other methods
can be employed to best advantage.

SERVICES, FLOWS, AND QUALITIES

Information systems can be viewed as networks of asynchronously communicating components,
each of which provides some set of system services. These services are combined in various pat-
terns to satisfy business requirements, which are structured into mission-centric user tasks called
flows. The flow structures of FSQ provide the bridge between mission requirements and the ser-
vices provided by various system components. Qualities of flow structures are determined from
the qualities of the services invoked and the engineering of the flows on the network systems.

Services

A service is the basic abstraction in the FSQ framework. One or more components may provide
a service in a variety of ways. The service may even be accomplished by invoking another large,
networked system. For our purposes a service is simply a function provided by a system compo-
nent or set of components.
For example, user authentication may be viewed as a service. Authentication of users may be
done in a variety of ways, against different sources, using multiple components. Figure 2.1 shows
two examples of authentication services. On the left is a simple authentication service that main-
tains an internal database of encrypted passwords for comparison. On the right is a more complex
authentication service that itself depends on other services. For example, if biometrics is avail-
able, it may be preferred. Because biometrics may not be available in every circumstance, other
authentication mechanisms are also provided, such as a Lightweight Directory Access Protocol
(LDAP) server and even simple password hashing. This component also provides a database of
access rules that can provide user rights based on both the user to be authenticated and the form
of authentication used.
A given service may participate in multiple asynchronous requests or even in multiple concur-
rently operating systems. The response of a service to a request may depend not only on the request
but also on the complete history of prior requests. We treat services as black boxes (Prowell et
al., 1999) whose response to any given request can depend not only on the request but also on the
history of use of the service. This history of prior requests is captured as state information internal