[¤2] Phase B - the Business Process Level

[¤3] The inputs to ADM Phase B are:

• [¤4] Request for Architecture Work
• [¤5] Statement of Architecture Work
• [¤6] Business Principles, Business Goals and Strategic Drivers
• [¤7] Architecture Principles
• [¤8] Architecture Continuum
• [¤9] Architecture Vision

[¤10] The outputs of this step are:

• [¤11] Statement of Architecture Work (updated if necessary)
• [¤12] Validated principles, business goals, and strategic drivers
• [¤13] Target Business Architecture
• [¤14] Business Baseline
• [¤15] Views corresponding to the selected viewpoints addressing key stakeholder concerns
• [¤16] Gap analysis results
• [¤17] Technical requirements (drivers for the Technical Architecture work)
• [¤18] Business Architecture Report
• [¤19] Updated business requirements

[¤20] As a preliminary to this step it is necessary to define the scope of activity, including what is in scope, what is out of scope, what the limits are and what the financial envelope is. Within this step fall defining the business process, recording the assumptions made and developing any new requirements. The information collected is used to gauge the current system and to determine the return on investment of potential changes. Use-cases are a useful tool in this step to describe the business processes and they can be used to do a sanity check against the resulting architecture.

[¤21] The business goals driving improvements in the sales process were:

• [¤22] to improve the quality of the sales process
• [¤23] to reduce the number of errors in the sales process
• [¤24] to speed up the sales process

[¤25] In this example financial and time constraints, and business return have not been dealt with in detail, but normally these constraints would be used to guide the process along the entire way to avoid over-engineering or "creeping elegance". The architect should especially look at these constraints whenever iterating between steps. Also not shown in this example are the use-cases scenarios. However, the process described below does include participants, or actors, of the use-case with brief descriptions of their roles in Table J-1.

[¤26] For the sake of brevity in this example, it is assumed that the scope of the architectural work would not extend beyond the sales arena, and that the proposed solutions fit within the financial and time constraints imposed by XYZ.

[¤27] The assumptions made by the XYZ architect during Phase B are:

• [¤28] To support the mission of the business, it is desired to have the sales person and the customer meet and interact face to face at the customer location.
• [¤29] The model for such a customer visit should be two persons interacting using a shared PC
• [¤30] The sales person needs to be able to close the deal on site, and then synchronize with information held at the sales base.
• [¤31] There is a clearly defined product set subject of the sales process, e.g. there is a car to buy.

[¤32] The relevant business process in scope of this example in the XYZ company is the customer facing portion of the sales process and the supporting systems. This sales process consists of the following steps:

[¤33] 1. initiate the sales process with the customer

[¤34] 1.1 sales person
[¤35] 1.2 customer

[¤36] 2. discuss the customer requirements

[¤37] 2.1 customer
[¤38] 2.2 sales person

[¤39] 3. work with the customer to create a product configuration

[¤40] 3.1 sales person
[¤41] 3.2 sales person's laptop
[¤42] 3.3 sales person's local (LIPR) and central (CIPR) information process resources
[¤43] 3.4 product configurator
[¤44] 3.5 customer

[¤45] 4. verify that the desired configuration can be delivered

[¤46] 4.1 sales person
[¤47] 4.2 sales person's laptop
[¤48] 4.3 inventory control system
[¤49] 4.4 scheduling system
[¤50] 4.5 customer accepts or rejects

[¤51] 5. determine the price of the requested configuration

[¤52] 5.1 sales person
[¤53] 5.2 sales person's laptop
[¤54] 5.3 pricing system

[¤55] 6. confirm the desire to purchase with the customer

[¤56] 6.1 sales person
[¤57] 6.2 customer

[¤58] 7. place an order

[¤59] 7.1 sales person
[¤60] 7.2 sales person's laptop with printer (for fax)
[¤61] 7.3 order system
[¤62] 7.4 customer

[¤63] 8. customer acceptance

[¤64] 8.1 sales person
[¤65] 8.2 customer

[¤66] The following use-case table represents participants (sometimes referred to as "actors" in use-case) in the rows, steps of the business process in the columns and roles in the cells. Note that this is an example, and it is not intended to be accurate, but rather demonstrative. Constructing a use-case table is a comparatively small effort that will ultimately enhance the speed and quality of the resulting architecture.

[¤67] The meanings of the various acronyms used in the table, and in subsequent figures, are listed below:

[¤84]  

[¤311] Table J-1: Use-Case Table of Sales Process

[¤312] Steps 1, 2, 6 and 8 are not within scope of the architecture work since the only participants involved are humans. The other steps are considered within scope since there are computing components involved in supporting the sales process. Note the computing participants are the first set of identified candidate building blocks - Business Process Driven List.

[¤313] During Step A, the business goals were developed into more detailed business requirements, and these were:

• [¤314] to improve on the current turnaround time of 48 hours for order processing
• [¤315] to reduce the number of errors in orders by a factor of 3

[¤316] A very simplified view of the candidate building blocks required to support the business process with an idea of location is provided below. This model was built from elements of the above table.

[¤317]

[¤318] Figure J-2: Model of the Candidate Building Blocks - "Business Process Driven List"

[¤319] The Technical Functionality and Constraints level

[¤320] Copyright © The Open Group, 1998, 2002