global integration

Business modeling

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 model.

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)