global integration

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 between them?

Encapsulation

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 of XML.) 

Protocols

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)