| Understanding
EIDX Business Models
There are a
number of ways of representing a business process graphically. Many
organizations are adopting the Unified Modeling Language
(UML) for representing business processes. The
most commonly used are:
- Use
Case Diagram - Defines the scope
of the process, who the players are, and what
the activities are
- Activity
Diagram - a/k/a "Swim Lane" diagram,
defines the flow of activities, with one swim
lane per "actor" (party); shows where
one actor hands off the process to another, and
guard conditions that cause a decision to be
made about taking one path vs. another.
- Sequence
Diagram - Defines information
flows; one limitation is that this type of diagram
cannot represent concurrent activities.
- Class
Diagram - Describes objects (such
as a purchase order), their data attributes and
operations that may be requested for a given
object.
The EIDX community
is made up of both business and technical constituents,
and, as mentioned earlier, EIDX models are conceptual. EIDX
is using some UML, as described here.
Traditional
EIDX Representation (Use Case)
Although UML
notation is not used, the traditional EIDX representation
is still considered to be very understandable to business
people, and it serves the same function as a UML Use
Case, i.e. to illustrate the scope of a process, the
players, and the basic activities.
Click here to view a larger image.
Activity
Diagrams
The base activity
diagram for a component model or scenario represents
our best attempt at a standards-neutral,
technology-neutral view. As mentioned before,
technology-specific or standards-specific views may also
be presented. Examples include:
- Order
Model 1 - Base Activity Diagram
- Order
Model 1 - Technology = Traditional EDI
- Order
Model 1 - Technology = Buyer's Web Application
Click here to view a larger image.
Context
Diagrams
EIDX uses the
term "context diagram." EIDX
uses this term for a diagram that represents best-practice
relationships between the component and scenario models.
Other ways
of combining component models are technically possible,
but if they are not shown on the context diagram,
it's because they are not identified by EIDX as best practices. Implementation
costs can be reduced by agreeing on ways in which
processes can be combined to create scenarios, instead
of expecting
companies to support every possible combination.
Each context diagram is from the perspective of one component
or scenario
model.
Example: Compare
context diagrams below for Forecast
Model 3, Order
Model 2, and Order
Model 3A. All three diagrams show all
three component models, but each model is slightly
different because each describes only that component
model's relationships with other models.
|
contact
us 
