Bring Back Tight Coupling and P2P Integration !?

March 18, 2008

So we aspire to loose-coupling, re-usable interfaces model abstraction as a means of implementing our SOA. Why? Well we’re told that the alternative is bad ! That alternative is unconstrained tactical wiring between applications, with the resulting unsustainable wiring being the essence of bad practice. I do agree to a point about the unconstrained integration being a bad thing, but there’s also some marketing greyness I need to dispel.

Point-to-Point or tactical integration is the term used to describe the creation of an application integration solution between 2 components, where the aspiration, the design, and the solution is only concerned with that specific requirement at that point in time. Shock horror – who would do such a thing?! Well there’s plenty of reasons for why this kind of approach may be suitable in some scenarios – in fact this IS the most popular approach to integration right!

However the subtle difference between the archetypal P2P interface and a reusable service is in how the design is approached – bear in mind P2P interactions still exist via re-usable services too. Has the interface been based on open standards in the infrastructure layer, has the interface been abstracted at a functional and information level to support additional dimensions (i.e. products, customer types etc) over time? Whether we use web-service technology or not we can still create re-usable services in the application integration landscape.

Now at the other end of the food chain we have our new-friend the coarse-grained, heavily abstracted, reusable Business Services driven out of the mainstream SOA approach to rewiring the Enterprise. Here we have, from the outside looking in, a single exposure for a complex array of related functions (i.e. multi dimensional product ordering), based on WSDL/SOAP/XSD/XML/WS* standards. This kind of approach is the current fashion, and is purported to simplify integration. Wrong!

What we do find is that the new, extensible interface simply creates a thin but strategic veil over the previous P2P interfaces, and effectively causes 2 areas of complex integration. Firstly – behind the new exposure, the service provider has to manage the mediation of an inbound request across his underlying domain models. Secondly the consumers of this newly published service have to deal with their own client-side mediation to enable their localised dialects to be transformed into a shape which can traverse the wire and be accepted by the remote service provider – or at least by the new strategic facade.

My point here is that SOA and the inherent style of wrapping functionality introduce integration challenges in their own right! So it’s not all rosy in the SOA garden, and this is where I’m seeing opportunity for a hybrid approach….and (appologies for the heresy, I’ll burn in hell if I’m wrong) a resurgence of P2P runtime integration based around a well managed reusable service design process.

Eh!? Have I unwittingly turned to the dark-side?


What I mean is P2P is OK if the cost of change is minimal – and if we minimise the client specific aspect we can reduce this cost to a point where it’s comparable to that of the alternative of exposing the common model to the wire. In traditional approaches, cost of change is high because the entire design of the solution was hardwired to one specific purpose. Introduce a requirement to flex that solution and we have to rip and replace. However if the P2P ‘design’ is managed correctly and involves the creation of mappings between a common model and the provider domain models, then in addition to exposing that generic interface to the wire, we have a facility to enable the consumers of the service to declaratively derive their own native transformations, which can cut out a transformation step in the runtime.

If we use a toolset such as Progress DXSI, for capturing the Service Provider mappings into the Common model, and then capturing the Consumer mappings into the Common model, then we can relatively simply derive transformations between the Consumer dialect and the Provider dialect. Any changes to the provider, or the Common model would simply require a re-generation of the transformation code that would then execute on the client. This sounds sort of logical…unless my logic has become skewed somehow 🙂

So this hybrid approach simply blends the best of a fully decoupled SOA approach with the runtime efficiencies of a tightly coupled P2P approach, based on the fact that the design-framework is declarative and can reduce the cost of change so as to mitigate the risk of P2P solutions.

I’m going to explore this in more detail, but I’m confident there’s a way of getting the best from both worlds…unless the SOA police catch me first…


Architect, Developer or Mineral?

March 17, 2008

Working within the IT community of a large Telco I am fortunate enough to work with a range of specialists across a range of IT related disciplines. I use the term specialist intentionally, as one of the biggest culture shocks I encountered when joining the corporate entity from a start-up and freelancing background, was the degree of specialisation afforded IT professionals within the protective enclave of the corporate firewall. Terms like ‘I only deliver software I don’t support it’, ‘I am a solution designer, not a developer’ and ‘I don’t do customer’ were sadly common and although strategic programmes have re-aligned focus on what matters (i.e. customers) there is still a great degree of specialisation by choice rather then specialisation by demand as in the open-market.

So why is this important. Well I constantly hear and experience (mostly) light-hearted jousting between Developers and Enterprise Architects (such as I). The fundamental basis for this banter is the fact that the Developers believe the Architects are ‘wannabe developers’, seemingly detatched from the build process because they are too busy sculpting new ivory towers in which to postulate the meaning of next months’ ‘strategic strategy for planning’. Developers meanwhile, (I’m led to believe) keep the business running by cutting code in their sleep, being part of some niche music scene, knowing why Ruby is far better then Perl, and have discovered cool t-shirt and bag shops where the doors are closed to anyone with MS Powerpoint installed on their laptop !

Having recently made the transition from a pure Architecture to a pure(ish) Developer role to get a closer appreciation for skills I had stopped using some years ago, I now consider myself able to understand a little more clearly, this perceived void between Developers and Architects. It is simply a matter of specialisation through necessity.

Enterprise Architects have a role in which they are rewarded for looking toward the horizon, and dove-tailing business and IT activities to make optimal use of available resources whilst mindful of all the constraints in the delivery engines. The number of bases one must cover (speaking from painful experience) if one is to be an effective Enterprise Architect, does require a similar degree of intensity as that of a developer with head-in-code, albeit detail of a different nature. It is unlikely that Enterprise Architects, however technically minded, can find time to drop beneath a system-level perspective.

Developers have a role in which they are rewarded for effective delivery of solutions involved in a current or near-term horizon, by ‘going vertical’ into the detail with a narrower ‘enteprise’ scope but becoming a domain expert within a specific field. The level of focus required for a developer to become fully integrated with the evolving solution, leaves little ‘free memory’ or ‘cpu cycles’ for engaging in the Enterprise planning activities keeping the EA guys so busy.

Moving between these roles does take a period of mental refactoring of one’s head-space from a horizontal to a vertically arrangement, so it’s not the sort of thing one can do on demand (unless you are one of the lucky ones with unbounded mental scalability which I aint!). So I am emphasising the specialisation thing again, where we specialise on either 1) What we get paid to, or 2) What we enjoy. So to round off this ramble…

An Enterprise without Architects is a ship without a rudder…

An Enterprise without Developers is a ship without an engine…


So let’s start appreciating each other…