A rapidly-growing mobile phone company developed 'arthritis', with every
expansion and procedural change becoming increasingly complex. A disparate
collection of software in the various departments was fingered as the problem,
and the IT division was charged with tackling the situation.
With the assistance of TriReme, they began by making a model of the
business. It soon became apparent that the same terms had subtly different
meanings in different departments, causing miscommunication between people,
quite apart from the sofware. The scope of the project was expanded to
define common terms and consistent views of the business process. The resulting
models were then used to define common protocols between the software.
A common model: not just about data
A huge soap and ice-cream manufacturer, that absorbs several medium-sized
companies a year, wanted to make it easier to interconnect its many and
diverse software systems. They began by devising a common data model of
chemical formulations, and imposed this as a standard on all new software
developments. The result is that it is now possible to move a formulation
devised in a laboratory spreadsheet in Tasmania straight into a manufacturing
database in Finland. Unfortunately, the data are still interpreted differently
by the different software applications. There is one 'temperature' field,
and local developers needing two temperatures adhere to the standard variously,
by encoding the two temperatures in one field, or by recording the second
temperature in the 'weight' field that they don't use, etc.
More recently, the architectural team have realised that you must (a)
focus on an extensible data transmission protocol, leaving local
data representations encapsulated within each application; and (b) standardise
not just the data, but also the meanings of the attributes. They have settled
on an XML data definition, and used UML to define semantics. Local developers
are now freed from the need to force their applications into the standard
data definitions (which restores their option to purchase third-party software),
provided they define adapters that translate to and from the corporate
Business before software
A corporate financial services house began in Belgium and then expanded,
planting subsidiaries in different European countries. Each country manager
was given free rein to develop local products and procedures; and were
also free to make local modifications and additions to the business software,
to support their own inititives. All went well for ten years until they
wanted to provide cross-border services for international corporate clients,
and to do business via a single web server. At first, this was perceived
as a software problem: CORBA would solve it by allowing the different systems
to talk to one another.
A review by TriReme made it clear that it would be necessary to integrate
the businesses before integrating the
software. For example, orders were processed in a different sequence in
different countries, payment being expected at different stages. As things
were, an order made in France and then passed to the UK could have been
fulfilled without the customer ever being invoiced; conversely, customers
ordering in UK for fulfillment in France could have become very annoyed.
The integration activity was entirely restructured, focussing first on
the political delicacies of making the business processes compatible.
Not a new problem
Before the Romans, Europe was a chaotic and largely impoverished place.
The Roman Empire imposed a common language of commerce, common trading
standards, and common definitions of weights, measures, contacts, and so
on. This facilitated trade across the Empire, greatly improving prosperity.
This was somewhat before TriReme.
complete solutions for integration
(consultancy, courses, workshops, mentoring, seminars, development)