Point-2-Point Integration versus Incremental Service Reuse…?

Service and asset reuse is the cornerstone of most SOA business-cases. From the top-down, with an Enteprise Architecture perspective it makes complete sense to group analogous integration projects into a common service-creation program, and inject governance and policy to ensure the resulting service is reprentative of the combined needs of the various individual integrated endpoints. The traditional point-to-point approach, of funding just enough integration to get you to the next problem is therefore frowned upon, and we often hear how P2P is at the opposite end of the CIO ‘must-have’ scale to the more saleable SOA reuse story. So what is so bad about an incremetnal P2P integration approach. Clearly the worst-case scenario is a relatively organic integration landscape with reactive, narrow spikes evolving between systems over time with arguably limited vision in terms of the long game. Individual stakeholders fund their specific integration projects based on simpler and therefore a relatively quantifiable cost/benefit story. Exponentially increased maintenance cost, lack of clear ownership/sharing of the integation assets and errosion of agility generally grind this one into the ground over time. SOA as a strategic programme would aim to get all those stakeholders into one room, make them link arms, make them agree on their combined ‘requirement’ and fund that through a business case of lower incremental cost over time based on initial capital injection to get connected to the SOA backplane. However, in reality, even within an Enterprise SOA Transformation programme where all the policy and governance frameworks are in place, I still see a P2P approach to integration albeit under the thin veil of ‘strategic integration’ using approved design patterns and models. The result is simply down to the fact that despite having an aggressive drive towards standardisation and conformance, the business is still operating on departmental targets, budgets, risk, and accountability. As such it’s almost impossible to find an optimal intersection between the moving parts of the organisation such that real service reuse can be achieved initially. So the incremental SOA implementation, funded by specific stakeholders, is intended to grow the reusable assets over time, based on the assumption that all increments will have the big-picture in mind and not compromise the quality of the reuse-potential. Yeah right ! What we do see is successive increments, bending and skewing the core services such that incompatibility and runtime duplication begins to emerge. This is a real problem as it is little better than an explicit p2p approach. The significance of this issue is related to the scale of the Enterprise, as well as the level of planned reuse for any particular component, but it takes a very strong governance body to win the argument between departmental bonus (based on delivery and customer benefit) versus architectural purity and long-game ROI?  My point is simple. There is little or no difference between the explicit P2P and incremental Service Reuse approaches – other than you get the former for nothing, and the latter relies on a startup cost associated with a SOA programme. If they deliver the same result….then it becomes a perfect candidate for a Dilbert sketch…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: