Page 282 -

CHAPTER 10 SYSTEM ENGINEERING 253

objects: customer, and product A. The two objects can be connected by the rela-
tionship purchases; that is, a customer purchases product A or product A is purchased
by a customer. The data objects (there may be hundreds or even thousands for a
major business activity) flow between business functions, are organized within a
database, and are transformed to provide information that serves the needs of the
business.
The application architecture encompasses those elements of a system that trans-
XRef
A detailed discussion of form objects within the data architecture for some business purpose. In the context
software architecture is of this book, we consider the application architecture to be the system of programs
presented in Chapter (software) that performs this transformation. However, in a broader context, the appli-
14.
cation architecture might incorporate the role of people (who are information trans-
formers and users) and business procedures that have not been automated.
The technology infrastructure provides the foundation for the data and application
architectures. The infrastructure encompasses the hardware and software that are
used to support the application and data. This includes computers, operating systems,
networks, telecommunication links, storage technologies, and the architecture (e.g.,
client/server) that has been designed to implement these technologies.
To model the system architectures described earlier, a hierarchy of business process
engineering activities is defined. Referring to Figure 10.2, the world view is achieved
As a software through information strategy planning (ISP). ISP views the entire business as an entity
engineer, you may and isolates the domains of the business (e.g., engineering, manufacturing, market-
never get involved in
ISP or BAA. However, ing, finance, sales) that are important to the overall enterprise. ISP defines the data
if it’s clear that these objects that are visible at the enterprise level, their relationships, and how they flow
activities haven’t been between the business domains [MAR90].
done, inform the The domain view is addressed with a BPE activity called business area analysis
stakeholders that the (BAA). Hares [HAR93] describes BAA in the following manner:
project risk is very
high. BAA is concerned with identifying in detail data (in the form of entity [data object] types)
and function requirements (in the form of processes) of selected business areas [domains]
identified during ISP and ascertaining their interactions (in the form of matrices). It is only
concerned with specifying what is required in a business area.
As the system engineer begins BAA, the focus narrows to a specific business domain.
BAA views the business area as an entity and isolates the business functions and proce-
dures that enable the business area to meet its objectives and goals. BAA, like ISP, defines
data objects, their relationships, and how data flow. But at this level, these characteris-
Business Process
Engineering tics are all bounded by the business area being analyzed. The outcome of BAA is to iso-
late areas of opportunity in which information systems may support the business area.
Once an information system has been isolated for further development, BPE makes
a transition into software engineering. By invoking a business system design (BSD)
step, the basic requirements of a specific information system are modeled and these
requirements are translated into data architecture, applications architecture, and
technology infrastructure.