6.3 Inter-enterprise scenarios

 < Day Day Up > 



6.3 Inter-enterprise scenarios

In the second phase of the implementation, ABC Electronics wishes to enable their Retail systems to place orders to external wholesale partners. Currently, the Retail departments fill out an order form and mail it to the external partner organization. Difficulties arise when orders cannot be filled because of latency in the manual process and outdated inventory.

Selecting a Business/Integration pattern

In 4.2.1, "Business and IT drivers" on page 71, the following drivers are listed for selecting the Extended Enterprise business pattern:

  • The business processes need to be integrated with existing business systems and information.

  • The business processes need to integrate with processes and information that exist at partner organizations.

Both drivers apply to ABC Electronics. The business processes of the Wholesale partners and the Retail departments need to be integrated by integrating the existing partner systems with the existing Retail business systems. The pattern would integrate the Retail departments with processes and information that exist at partner Wholesale organizations.

The Extended Enterprise business pattern can be applied in our inter-enterprise scenarios, as shown in Figure 6-6.

click to expand
Figure 6-6: ABC Electronics- Stage III and IV architecture overview diagram

6.3.1 Stage III: External get delivery date on demand

With the success of the internal Retail and Wholesale systems, ABC Electronics has now decided to integrate their external Wholesale business partners. The goal of the third stage of implementation is to integrate the external partner systems with the internal Retail system. As with the internal Wholesale system, the external partner systems will need to be able to provide delivery dates to the Retail systems.

For Stage III of our business scenario, we can identify an additional actor:

  • The partner system or systems

We also need to provide the Partner System actor with access to the Update Inventory use case.

Actors

Table 6-5 provides details on the partner system actor.

Table 6-5: Retail system actor details

Actor name

Partner system

Brief description

The partner system implements the partner Wholesale inventory business process

Status

Primary

Relationships

001 Get Delivery Date, 002 Get Earliest Delivery Date

Associations to use cases

 

The Stage III use case model is shown in Figure 6-7.

click to expand
Figure 6-7: Stage III use case model

Selecting an Application pattern

In Table 4-3 on page 75 and Table 4-4 on page 76, the following drivers are listed for selecting the Router variation of the Extended Enterprise::Broker application pattern:

  • Improve the organizational efficiency

  • Reduce the latency of business events

  • Support a structured exchange with business partners

  • Support real-time one-way message flows to partner processes

  • Support real-time request/reply message flows to partner processes

  • Support dynamic routing of messages to one of many target partner's processes

  • Leverage existing skills

  • Leverage the legacy investment

  • Enable back-end application integration

  • Minimize application complexity

  • Minimize enterprise complexity

Because we require a solution that includes numerous external partner Wholesale applications, these drivers are a good match for the Stage III scenario. The same reasoning used in use case 001 applies here.

6.3.2 Stage IV: External get earliest delivery date on demand

The final stage of the scenario addresses "parts shopping" situations where the Retail systems want to find the external Wholesale partner that can supply a part at the earliest date.

The Stage IV use case model is shown in Figure 6-8.

click to expand
Figure 6-8: Stage IV use case model

Selecting an Application pattern

In Table 4-3 on page 75 and Table 4-4 on page 76, the following drivers are listed for selecting the Router variation of the Extended Enterprise::Broker application pattern:

  • Improve the organizational efficiency

  • Reduce the latency of business events

  • Support a structured exchange with business partners

  • Support real-time one-way message flows to partner processes

  • Support real-time request/reply message flows to partner processes

  • Support dynamic routing of messages to one of many target partner's processes

  • Support dynamic distribution of messages to multiple target partner's processes

  • Leverage existing skills

  • Leverage the legacy investment

  • Enable back-end application integration

  • Minimize application complexity

  • Minimize enterprise complexity

This use case has the same requirements as use case 003 and the same drivers. In addition, this use case has introduces the need to poll multiple Wholesale departments, both internal and external for a delivery date. The key driver here is the ability to support dynamic distribution of messages to multiple target partner processes.



 < Day Day Up > 



Patterns. Broker Interactions for Intra- and Inter-Enterprise
Patterns. Broker Interactions for Intra- and Inter-Enterprise
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 102

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net