A Goal-Driven Approach to Enterprise Component Identification and Specification

1. Customer Relationship Management
2. Order Management
3. Product Management
4. Inventory Management
5. Financial Management

Each business process will be mapped onto an Enterprise Component that encapsulates use cases related to a single or possibly several closely related business processes. The use cases provide a set of large-grained services that are exposed on the component’s interface. Highly interdependent (coupled) use cases belong in one component. If a use case has many external dependencies then it should be assigned to another component; refactoring may be needed for use cases and/or components and may imply the need for business process reengineering in cases where such feedback is within scope.

We further decompose the subsystems into the following set of constituent business processes and business process steps:

1. Customer Relationship Management = {Account Management, Contact Management (Addresses), Security, Customer Profile and Preferences}
2. Order Management={ {[Identification], Presentation, Selection {Shopping Cart Management}, Purchase [Identification], Confirmation, Order Fulfillment, Billing}
3. Product Management = {Products, Catalogs, Pricing}
4. Inventory Management = {Fulfillment {Picking and Shipping}, Vendor Management}
5. Financial Management ={Billing, Accounting and Bookkeeping{Accounts Payable, Accounts Receivable}}

Step 3: Create the Goal Model Using Goal-Service Graphs. In this step, high-level business goals are identified and refined into sub-goals with explicit dependencies. At each level, a sub-goal will need a set of services that will achieve its requirements. Goals are usually discovered through interview and rapport with the business side of a project. Business modelers, although a very important source of business goals, may often be out of synch with the business owners or higher-level/executive management whose job it is to set goals. Therefore, verify the goals with executives, preferably start with their direction and keep them involved as you determine goals, sub-goals, and services. Space is too limited here to provide an exhaustive set of goals from projects that have resulted in e-bazaar, so we present a subset of sample goals, sub-goals, and services that have been identified, fed back to the business for verification, and refined.

It is interesting to note that from an IT perspective, goals can often be categorized with high-level non-functional requirements and these are often realized through a set of functional requirements, often expressed as use cases. Here is an excerpt from a recent interview with an executive: "Our primary goals are to increase sales and retain customers through higher quality of our products and the ease of use of information system services that enable customers to rapidly place orders. For our B2C side, this translates into customers easily and rapidly finding the products they want, placing orders with minimal re-typing over successive visits to the site. Inside the company, product managers should be able to introduce new offerings fast (within one week versus currently, three-week cycles). For B2B this means credibility as a link in the value chain of the e-marketplace where service consumers and providers can rely on our services." For brevity, we will focus only on the B2C side and on one of the high-level goals, Customer Loyalty, in the example shown in the sidebar "Goal-Services Graphs."

Step 4: Service Allocation. Once the structure of the components is identified through domain decomposition and subsystem analysis, their functions or services are then identified through Goal Service Graphs. Now we have some large-grained components and some services. The next step is called service allocation where we assign services to the components. This process is facilitated by the fact that each business process is tied to the fulfillment of a business goal. Likewise, the Goal Model corresponds a set of sub-goals with services required to fulfill the higher-level goal. These goals can be used to match the services with the enterprise components that will provide those services.

Note that the assignment of services to components needs to take into consideration the granularity of the service. For example, Order Management has a large-grained service called Make Online Purchase. In a B2B scenario only the actual Order and Customer Information would be necessary to be supplied to automate the order process from one service requestor to a service provider within a value chain. In a B2C scenario, the automation may be replaced by the need to present catalogs of products, allow the user to browse and select products, add them to their shopping cart and submit the order (possibly providing Customer, Billing, and Shipping information if they do not have an online account that stores that information). In the latter case, more granular services would reside the Order Management component interface; namely, Identification, Presentation, Selection, Shopping Cart, Order Confirmation, and so forth.

Step 5: Specification of Enterprise Components. Specification requires three key ingredients: services (interfaces), contracts, and manners. Respectively they address: what capabilities the component provides to support the business goals and processes, what it requires to do so, and an abstract specification of the design of how the services realize goals. Thus, so far, we have defined the services and interface signatures. Next we need to specify the pre- and post-conditions of each service; the sum total of which are the services provided and required by the component. The last item is to define component manners or an abstract specification of the context-dependent behavior of a component: how the component in a given state should behave within a given context; which subset of rules to check once an event has been triggered (see the sidebar "Grammar Definition").

Step 6: Structuring Enterprise Components. Enterprise components are defined around business processes boundaries and often encapsulate a set of related use cases. The progression is often seen to be "business process –> subsystem –> enterprise component encapsulating design decisions and business rules"; how it realizes a set of cohesively related use cases and exposes/provides a set of services on its interface that trigger each use case. This brings us to the design of the internal structure of enterprise components. A recurrent solution we have applied across many projects is the Enterprise Component compound pattern, which provides a uniform design mechanism and terminology that can be used across all development teams with minimal instruction. In addition, the pattern can be used as a checklist to validate that all relevant aspects of a component-based design have been addressed. In this manner, multiple teams can work with the same basic design template and factor in the placeholders necessary for an evolving software component’s design needs.

Frequently, enterprises with multiple business lines (such as retail, wholesale, institutional or credit card, traveler’s checks, financial services, insurance, and so forth) find the need to fulfill many product lines through a configurable component-based approach that addresses the needs of their families of applications. We have realized the emphasis on the design of components (the parts) should be shifted to the emphasis on the configuration of components within a business context (the whole). This allows the identification, conceptual separation, physical reification or encapsulation and externalization of a semiformal specification for the flow logic within the application and within components to be captured in an externalized, configurable component profile. Thus, the system and its components can be "soft-wired" and allowed to evolve independent of their static and dynamic configurations.

Externalization is a design-time or refactoring-time activity whereby variations are encapsulated and a description of the axes of variation of a component are externalized into a configurable profile (CP). The participants in this pattern are described in [3] and are summarized in the accompanying table. Thus, an enterprise component’s manners provide the opportunity for short turnaround reconfiguration by targeting changes only to the externalized flow. The CP can then be changed (reconfigured), by the Service Provider, Consumer, or Broker at compile time, startup (initialization) or runtime to provide dynamic customization of streamlined services. Figure 2, part (a) shows the structure of an Enterprise Component with Externalized Manners in a CP; part (b) shows an example implementation of an Account Manager component. Its workflow can externalize its component’s manners in a CP containing the following grammar:

AccountMgr = {Open, Transactions, Close}
Transactions = {{checkFunds, debitAccount}|{creditAccount} | Transfer | queryAccountBalance}
Transfer = {fundTransferAllowed, checkFunds, debitAccount, creditAccount}

The extensions to processes such as the Unified Process are shown in Figure 3. These extensions consist of a set of business modeling extensions including domain decomposition, subsystem analysis, and goal-oriented object design. The architectural modeling extensions include variation-oriented analysis and design [3].

1. Customer Loyalty

a. Reward Customers for Loyalty

i. Frequent Purchase Programs

ii. Frequent Service Registration Programs

b. Rapid Order Placement

i. Finding The Products Easily and Fast

1. Effective User-interface Design

2. Intuitive/Clear Categorization of products

3. FindProduct

c. Increase Customer Satisfaction

i. Decrease Order to Fulfillment Cycle

1. Automated order-processing

2. E-order management

ii. Fast Pick and Ship

1. »Automatic Replenishment

d. Minimal Re-entry of data

i. Maintain Customer Profile

1. Maintain Contact Information

2. Maintain Billing Information

a. Multiple methods of payment have their own properties

3. Maintain Shipping Information

ii. Defaults are maintained with option to choose or add another information record

2. Faster Introduction of Product Offerings (for both internal product managers and external Service Providers who use the marketplace)

a. Ease of Adding New Products and Services

i. Maintain Online Product Catalog

1. Add /Modify Rules to Products in the Catalog

2. Link Products for Cross Sell

a. Capture Demographics

b. Capture Product Purchase Patterns

c. Cross-reference products in search results (customers who bought…also bought…)

b. End-to-end electronic catalog maintenance

c. Strong e-Product Management

i. »Create Product

ii. »Search Product

d. Flexible Business Rules for Promotions

i. Promotions should not entail long coding cycles to change rules