Expanded Discussion of Information Engineering
When business automation was first introduced in the early 1960s, companies looked for areas of opportunity and simply automated business functions that were previously performed in a manual fashion. As time passed, individual computer programs were combined to encompass business applications. The applications were grouped into major information systems that served specific business areas. Although this approach was workable, it resulting in problems. Systems were difficult to connect to one another; redundant data was everywhere; the impact of changes to applications that served one area of the business were difficult to project and even more difficult to implement; old programs outlived their usefulness, but lack of resources causes them to be used long past their prime.
In their book on "reengineering the corporation," Hammer and Champy [HAM93] state:
Information technology plays a crucial role in business reengineering, but one that is easily miscast. Modern, state-of-the-art information technology is part of any reengineering effort, an essential enabler [that] permits companies to reengineer business processes. But to paraphrase what is often said about money and governments, merely throwing computers [and software] at an existing business problem does not cause it to be reengineered.
The global objective of information engineering is to apply "information technology" in a way that best serves the overall needs of the business. To accomplish this, IE must begin by analyzing business objectives and goals, understanding the many business areas that must work together to achieve these objectives and goals, and then define the information needs of each business area and the business as a whole. Only after this is done, does IE make a transition into the more technical domain of software engineeringthe process where information systems, applications, and programs are analyzed, designed and built.
Information Strategy Planning
The first information engineering step is information strategy planning (ISP). The overall objectives of ISP are: (1) to define strategic business objectives and goals; (2) to isolate the critical success factors that will enable the business to achieve these goals and objective; (3) to analysis the impact of technology and automation on the goals and objectives, and (4) to analyze existing information to determine their role in achieving goals and objective. ISP also creates a business-level data model that defines key data object and their relationship to one another and to various business areas.
The terms objectives and goals take on a specific meaning in ISP. An objective is a general statement of direction. For example, a business objective for a maker of cellular telephones might be: reduce the manufactured cost of the product. Goals define a quantitative course of action. To achieve the objective noted above, the manufacturer might state the following goals:
decrease reject rate by 20 percent within 9 months
gain 10 percent price concessions from suppliers
reengineer keypad to reduce assembly cost by 30 percent
automate manual assembly of components
implement a real-time production control system
total quality management strategy for the manufacturing organization
worker training and motivation
higher reliability machines
higher quality parts
sales plan to convince supplier to reduce prices
availability of engineering staff
Technology impact analysis examines objectives and goals and provides an indication of those technologies that will have a direct or indirect impact on achieving them successfully. The information engineer addresses the following questions: How critical is the technology to the achievement of a business objective Is the technology available today How will the technology change the way business is conducted What are the direct and indirect costs How should the business adapt or extend objective and goals to accommodate the technology
Because every business area makes some use of information technologies, ISP must also identify what currently exists and how it is currently used to achieve objectives and goals. Business process reengineering (BPR) is an activity that examines existing system with the intent of reengineering them to better meet business needs. BPR is discussed in Chapter 27.
Enterprise modeling creates a three dimensional view of a business. The first dimension addresses the organizational structure and the functions that are performed within the business areas defined by the organizational structure. The second dimension decomposes business function to isolate the processes that make function happen. Finally, the third dimension relates objectives, goals, and CSFs to the organization and its functions. In addition, enterprise modeling creates a business-level data model that defined data objects and their relationships to other elements of the enterprise model.
The business organization is defined in a classical business unit hierarchy (e.g., an "org chart"). Each box in the org chart represents a business area of the company. Like all hierarchies, it is generally possible to refined the boxes within the org chart until small working groups or even individuals are noted. However, for ISP purposes, business areas are all this required.
Business functions are identified and the the processes that are required to implement the business functions are defined. Each of the business functions is then related to the business area that has responsibility for it. In general a business function is some on-going activity that must be accomplished to support the overall business. It can usually be described as a noun phrase. A business process is a transform that accepts specific inputs and produces specific outputs. It can generally be described as a verb phrase.
To illustrate how a business function is refined into a set of supporting processes, consider the market analysis function. A process refinement follows:
Collect data on all sales inquiries
Collect data on all sales
Analyze data on inquires and sales
Develop buyer profile
Compare profile to demographic research
Study industry buying trends
Establish focus groups to determine best sales message
Design rough sales materials
Test sales materials and refine
Finalize sales approach
Each of the bulleted process steps could be further refined to provide a detailed road map for accomplishing the business function.
During ISP, the information engineer does not become concerned with areas of automation opportunity. The intent is simply to understand and model the business.
1.1.2 Business-Level Data Modeling
Business-level data modeling [SCH92] is an enterprise modeling activity that focuses on the data objects (also called entities) that are required to achieve the business functions noted earlier. At the business level, typical data objects include: producers and consumers of information (e.g., a customer), things (e.g., a report), occurrences of events (e.g., a sales conference), organizational roles (e.g., a Vice President of Engineering); organizational units (e.g., Sales and Marketing), places (e.g., manufacturing cell), or information structures (e.g., an employee file). A data object contains a set of attributes that define some aspect, quality, characteristic or descriptor of the data that is being described. For example, during enterprise modeling an information engineer might define the data object: customer. To more fully describe customer, the following attributes are defined:
Once a set of data objects is defined, their relationships are identified. A relationship indicates how objects are connected to one another. As an example, consider the objects: customer, product A, and salesperson. An information engineer creates a entity relationship diagram to depict these relationships. Referring to the figure, relationships imply a connection between data objects. In general, relationship can be read in either direction; hence, a customer purchases product A and product A a is purchased by a customer. In reality additional information is provided as part of the data model, but we postpone discussion of this until Chapter 12.
The culmination of the ISP activity is the creation of a series of cross reference matrices that establish the overall relationships between the organization (and its business areas), business objectives and goals, business functions, and data objects. Examples of such matrices are shown in Figure 10.7.
1.2 Business Area Analysis
In his book on information engineering, Martin [MAR90] describes business area analysis in the following manner:
Business areas analysis (BAA) establishes a detailed framework for building an information-based enterprise. It takes one business area at a time and analyzes it in detail. It uses diagrams and matrices to model and record the data and activities in the enterprise and to give a clear understanding of the elaborate and subtle ways in which the information aspects of the enterprise interrelate.
During BAA, our focus shifts from the world view to the domain view. To model "the elaborate and subtle ways in which the information aspects of the enterprise interrelate," the information engineer must depict how data objects (described during ISP and refined during BAA) are used and transformed within each business area and how the business functions and processes within each business area transform these data objects. In essence, both exogenous and endogenous data are analyzed and modeled for each business area.
To accomplish this work, BAA makes use of a number of different models:
data models (now refined to the business area level)
process flow models
process decomposition diagrams
a variety of cross-reference matrices
The data objects defined during ISP are refined for use within each business area. For example, the data object customer described in the preceding section is used by the sales department. After evaluation of the needs of the sales department (an analysis of the sales domain), the original definition of customer is further refined to meet the needs of sales:
company name Object: Company
job classification and purchase authority
business address and contact information
date of last contact record of contacts
status of contact status of last contact
next contact date
recommended nature of contact
The attribute company name has been modified to point to another object called Company. This object contains not only the company name but additional information about the size of the company, its purchasing requirements, the name of other contacts, etc. This information will be useful in the sales domain. Other attributes have been modified and added as noted above.
The work performed within a business area encompasses a set of business functions that are further refined into business processes. To illustrate, consider a simplified version of the sales function discussed earlier. The processes the occur to accomplish sales are:
Establish customer contact
Provide product literature and related information
Address questions and concerns
Provide evaluation product
Accept sales order
Check availability of configuration ordered
Prepare delivery order
Confirm configuration, pricing, ship date with customer
Transmit delivery order to order fulfillment
Follow-up with customer
A process flow diagram (Figure 10.8) can be developed for this sequence of processing. It should be noted that each business function relevant to the business area can be refined in a similar manner.
Information Flow Modeling
The process flow model is integrated with the data model to provide an indication of how information flows through a business area. Input and output data objects are shown for each process, providing an indication of how the process transforms information (Figure 10.9) to accomplish a business function.
Once a complete set of process flow models have been created, the information engineer (along with others) examines how the existing process can be reengineered (e.g., [HAM93], [JAY94]) and where existing information systems or applications might be modified or replaced by more efficient information technologies. The revised process model is used as a basis for the specification of new or revised software to support the business function.
The domain view established during BAA serves as the basis for business system design (BSD) and construction and integration (C&I)IE steps that are actually part of the software engineering process. The steps will be considered in later chapters.