how do you do it?
The ideal is to achieve 'pluggability': the ability to reconfigure
the business processes and the software that supports them, to cope with
any likely change that may occur.
A common model
Firstly, this means designing a common language about the business,
with clear definitions of terms and their relationships. This is most effectively
done in a language like UML. For example, what is the corporate definition
of a Customer or an Order? What attributes do they have, and what associations
with other concepts?
The model should not just be a data model. Once the terms are
clearly defined, you use them to define the business rules: the constraints
that must always be observed no matter what variations on the basic processes
are devised. Also, you can define what it means to perform commonly-understood
operations. For example, what does it mean to 'fulfill an Order'? What
are the resulting effects on the attributes of the objects and the associations
The idea is not to impose a data model that every business
department and software application must use internally. On the contrary,
they could go on using all their old terms and procedures, provided it
is possible to translate them unambiguously to the standard terms; and
provided they translate to the common language when talking to anyone outside
their own locality. In software terms, this means writing an adaptor or
'wrapper': and always providing only procedural access to data.
In most cases, each locality (software or business area) will use only
part of the corporate model; conversely, there will be local definitions
not known at the corporate level. Each locality should be capable of carrying
and ignoring attributes it doesn't understand. (This is one of the strengths
Once there is a common model, the means of connecting different
applications and business processes can be standardised. CORBA and COM,
XML, TCP/IP, EJB, MTS, and so on provide the technology; on top of this,
we need to think about what the systems say to each other about your business:
this is something you can't buy off the shelf, and is part of what gives
you the edge over your competitors.
Common protocols make business components (software, people, business
departments,...) 'pluggable': you can easily substitute one for another
to change part of the process; or reconfigure them easily, to make different
variants of the whole system.
Boundaries between components
The boundaries of components need to be reviewed. The most
flexible configuration is that each component corresponds to one feature
of the business process, so that if we want to change one feature, we need
only change one component. For example, if we have one person (or piece
of software) who handles everything to do with checking a Customer's credit,
but does nothing else, then when we change our creditworthiness criteria,
we only need worry about altering one component. The traditional separation
of concerns criteria are important here.
On the other hand, we must balance flexibility against performance,
and good engineering is about making that balance carefully.
complete solutions for integration
(consultancy, courses, workshops, mentoring, seminars, development)
us or tel UK:
01625 850 839 international:  +44 1625