New: the PoPoToPi!

The very main reason for me to write this blog-entry is to introduce a new word: Popotopi. I would love to see this home-made word pop-up in upcoming discussions over the world. To be honest, I used another word for it: PoJo: Plain Old Java Object. The word PoPoToPi means Plain Old Point To Point Interface. I like the word, because of its cadens, how it rolls over your lips.

Ok, another reason then: to explain one of the questions I'm currently involved in. My current customer has just celebrated the first aniversary of their EAI department. That means they have been busy with integration for quite some years. Mainly on Tibco. But now they have some projects going around introducing two other ESB/Soa platforms, one of them being Oracle SoaSuite. This drives them to think about integrating the integration platforms. How to exchange services, what is the scope of one integration environment, how to define bridges etc.

Looking into this I also discovered that they have several environments of their current Tibco Platform, because of having several domains. One of the colleagues I have in this department is catagolizing the services of one of the domains. His impression is that about 80 percent is just point to point. Although most of them are neatly defined using a so-called Canonical Data Model.

Having a Canonical Data Model is nice. It's just like the Hub-and-Spoke architecture of Oracle's Industrial Archeology Artefact: InterConnect. InterConnect was technical not a very sophisticated product. But the whole idea behind InterConnect I do like still. The Common View in InterConnect, that is the Canonical Data Model, is the abstraction on message level between end-points. It is based on Logical Entities on which you map the physical entities of your Enterrpise Information Systems (EIS).

But if you conclude that 80% of your integrations is point to point then you should think about how successfull you were in implementing EAI (Enterprise Application Integration).
A coupling is point-to-point if the two end-points are not re-used anywhere. Although the coupling uses a Canonical Data Model, the business event that is based on the CDM is not re-used. The reuse and thus the advantage of this approach only pays-off when you subscribe another end-point to the business event in the hub, if you have another application publish the business event or when you decide to replace one of the end-points without modifying the CDM.

Although the couplings are based on a CDM it is very interesting to compare the different CDM's (the message definitions) of the different integrations. As said: a CDM should be based on logical entities. This Logical Entities should also be reused over the different integrations. For example: an order in the "CreateOrder" integration should be the same in the "UpdateOrder" integration.

Drilling down in to the Logical Entities, it should also be interesting to reuse parts of the Logical Entities. For example: the address of a person, a customer, a supplier or an organization, be it a home, billing or shipping address, should be allways the same in structure. Actually a person being a customer or a supplier or a TradingPartner's contactperson is allways the same in structure.

It would be very interesting to see to what extent the standardization on CDM's is put through. Honestly, it would surprise me if there are not more then one definition of whatever Logical Entity in the different interfaces.
Every coupling, integration is defined and implemented in different projects. Only if a project-member does know of the existance of a reusable artefact and/or if there is budget to make artefacts generic enough, a project might leverage the advantage of EAI or feed the potential of it.

If every Logical Entity is neatly defined only once ever, especially when it is describe in a central library of artefacts, that would be great. Then you could say that you were quite succesfull in implementing a sufficient EAI.

If not, you can't speak of a succesfull, efficient EAI. Then, to me, you have implemented Popotopi's on a modern platform, where so-called services are not much more then simple building blocks (not services). But ask yourself and decide for yourself if it was worth the investment.

It is too bad, because a good EAI with uniquely, accurately, correctly and completely described buildingblocks, triggers, CDMs and message-object-mappings could be a very good base for the implementation of a SOA. Where a buildingblock could really be a service, a trigger could really be a Business Event in your Event Driven Architecture and the CDM's and mappings a base for your Enterprise Business Objects with their transformations.

I used to do Quick Scans on the performance of Custom Development Applications. It would be nice to do such a scan on EAI implementation to see what the impact on the implementation of SOA is in such a case. Or at least to think about it along with a customer.