[¤1] Phase A - the Business Process Level   


[¤2] Phase B - the Business Process Level


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

[¤10] The outputs of this step are:

[¤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:

[¤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:

[¤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:

[¤68] CIPR [¤69] Central Information Processing Resource
[¤70] ICSys [¤71] Inventory Control System
[¤72] LIPR [¤73] Local Information Processing Resource
[¤74] OrdSys [¤75] Order Processing / Information System
[¤76] ProdConfig [¤77] Product Configurator System
[¤78] ProdSys [¤79] Product Information System
[¤80] SchSys [¤81] Scheduling System
[¤82] $Sys [¤83] Pricing Information System

[¤84]  

[¤85]   [¤86] 1. initiate [¤87] 2.discuss
[¤88] reqs
[¤89] 3. create
[¤90] config
[¤91] 4. verify
[¤92] config
[¤93] 5. price [¤94] 6. confirm [¤95] 7. order [¤96] 8. accept
[¤97] sales
[¤98] person
[¤99] greets
[¤100] customer
[¤101] listens [¤102] represents
[¤103] options with
[¤104] different
[¤105] capabilities
[¤106] accesses
[¤107] ICSys and
[¤108] SchSys and
[¤109] presents
[¤110] availability
[¤111] to customer
[¤112] accesses
[¤113] price
[¤114] system and
[¤115] presents
[¤116] price to
[¤117] customer
[¤118] presents
[¤119] offer
[¤120] accesses
[¤121] order
[¤122] system
[¤123] presents
[¤124] contract
[¤125] customer [¤126] accepts
[¤127] sales
[¤128] person
[¤129] discusses
[¤130] problems
[¤131] /desires
[¤132] listens and
[¤133] decides on
[¤134] options
[¤135] based on
[¤136] capabilities
[¤137] accepts or
[¤138] rejects
[¤139]
[¤140]
[¤141] accepts or
[¤142] rejects
[¤143]
[¤144]
[¤145] signs or
[¤146] rejects
[¤147] sales
[¤148] person's
[¤149] laptop
[¤150]
[¤151]
[¤152]
[¤153]
[¤154] interacts
[¤155] with
[¤156] configurator
[¤157] interacts
[¤158] with
[¤159] ICSys and
[¤160] SchSys
[¤161] interacts
[¤162] with
[¤163] Price
[¤164] System
[¤165]
[¤166]
[¤167] interacts
[¤168] with order
[¤169] system and
[¤170] receives
[¤171] fax
[¤172] response
[¤173]
[¤174]
[¤175] sales
[¤176] person's
[¤177] CIPR
[¤178]
[¤179]
[¤180]
[¤181]
[¤182] provides
[¤183] central information processing
[¤184]
[¤185]
[¤186]
[¤187]
[¤188]
[¤189]
[¤190]
[¤191]
[¤192]
[¤193]
[¤194] sales
[¤195] person's
[¤196] LIPR
[¤197]
[¤198]
[¤199]
[¤200]
[¤201] provides
[¤202] local information processing
[¤203]
[¤204]
[¤205]
[¤206]
[¤207]
[¤208]
[¤209]
[¤210]
[¤211]
[¤212]
[¤213] ProdConfig [¤214]
[¤215]
[¤216]
[¤217]
[¤218] presents
[¤219] configs to
[¤220] sales person
[¤221] per needs,
[¤222] providing
[¤223] capabilities
[¤224]
[¤225]
[¤226]
[¤227]
[¤228]
[¤229]
[¤230]
[¤231]
[¤232]
[¤233]
[¤234] ICSys [¤235]
[¤236]
[¤237]
[¤238]
[¤239]
[¤240]
[¤241] provides
[¤242] availability
[¤243]
[¤244]
[¤245]
[¤246]
[¤247]
[¤248]
[¤249]
[¤250]
[¤251] SchSys [¤252]
[¤253]
[¤254]
[¤255]
[¤256]
[¤257]
[¤258] provides
[¤259] delivery
[¤260] date
[¤261]
[¤262]
[¤263]
[¤264]
[¤265]
[¤266]
[¤267]
[¤268]
[¤269] $Sys [¤270]
[¤271]
[¤272]
[¤273]
[¤274]
[¤275]
[¤276]
[¤277]
[¤278] provides
[¤279] price
[¤280] information
[¤281] on a config
[¤282]
[¤283]
[¤284]
[¤285]
[¤286]
[¤287]
[¤288] OrderSys [¤289]
[¤290]
[¤291]
[¤292]
[¤293]
[¤294]
[¤295]
[¤296]
[¤297]
[¤298]
[¤299]
[¤300]
[¤301] processes
[¤302] order and
[¤303] sends fax
[¤304] of order to
[¤305] sales
[¤306] person's
[¤307] laptop
[¤308]
[¤309]
[¤310]

[¤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:

[¤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] model of candidate building blocks - business process driven list

[¤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