Enterprise Integration: The Target Architecture

June 30, 2008

Refactoring architectural roadmaps. Where to start after time in the wilderness? Surveying the scale of the landscape, evolving mass of vendors, old and new initiatives and legacy sprawl. Getting that cold feeling in the pit of the stomach, like the one you get when the ‘flight’ option is removed from the ‘fight or flight’ juncture…

So how do you actually make headway and add real value to the enterprise?

My revised target architecture is summarised in the following image. We need keep the technology partners trolls under the bridges, and make sure our diverse users know where the bridges are, how wide they are, how much it costs to build one, what it costs to keep a bridge safe,  and make them forget about the noises down below…

Phase 2 will entail sealing the foundations in concrete we mixed ourselves, and re-routing the rivers. Therefore no space for ‘noise’ from the space beneath…happy times.

I’m starting to see the light…

Powered by Qumana


Enterprise Integration : QoS is What not How…

June 30, 2008

Looking at reasons why we adopt certain technical approaches to enterprise systems integration I’m increasingly concerned by a ‘how’ approach, using proprietary, expensive technology to create relatively simple styles of interaction effectively eclipsing the ‘what’. This ‘how’ approach appears to be rooted in technical policy and commercial structures rooted in the past, during which times proprietary/vendor solutions had more credibility than home-grown options. However looking at the ongoing commoditisation of application integration, the dominance of the web, and all manner of open-source technical options, it strikes me that we need to review our position, and attempt to find ways of selectively breaking out of the vicious circle of ‘licence renewal’ and ‘false economy’ in favour of a more blended approach.

Systems integration is dominated by TLA’s with a heavy vendor influence, and as such it’s easy to get lost in the cloud of complexity associated with MOM, JMS, MQ, XA, SSL, PKI, REST, HTTP, SYNCH, ASYNCH, PERSISTENT, QOS, etc. It’s no surprise, therefore that systems integration shoulders the burden of the difficult stuff getting brushed under the ‘proverbial carpet’ as opposed to the aspiration of the ‘intelligent application-aware network’. As that carpet gets ‘lumpier’, we throw more TLA’s into the mix and add more and more intelligence into the network, resulting in more complexit and a vicious circle. It’s no surprise that we’ve struggled to gain the confidence of the enterprise to the extent where we are in a position to move to commoditise what has become a very complex array of sticking plasters upon sticking plasters.

Shifting the focus to ‘the web’ and my interactions across that global ‘unreliable’, diverse, evolving network.  I note initially that I have a natural understanding of what I want to happen each time I select one or my many application’s. My mail client gives me the ability to create asynchronous 1:1 or 1:n distribution flows, with the ability of conveying large payloads and attachments. My instant messenger client allows me to enage in synchronous 1:1 or 1:n interactions, my feed-reader will sink event streams at a frequency I define. My blog client let’s me cache up a range of 1:n broadcast documents which are periodically published to a hosting platform. My twitter client lets me post informal event snippets. The list goes on.

The key point here is that I care not how any of my selected applications undertake my requested interaction, and in all honesty (even though I’ve implemented countless protocols in my time) I don’t have the time to care because if they are working ok, then I understand the QoS I expect, and if I don’t get that QoS I vote with my feet. We sometimes hear terms like Jabber, XMPP, SMTP, POP3, HTTP, HTTPS, IRC, etc. in assocation with the applications we use, but I would argue that only a tiny proportion of users of Thunderbird/Outlook actually have any clue about the implication of those SMTP settings at a technical level.

So to my conclusion. Systems integrators (and adopters of such technology in the enterprise) evolved from a time and a market-place differentiated by the ‘how’ factor. Subsequent up-selling on that original platform has created a momentum of expectation and desire in the technology consumer space, by constantly mapping the ‘how’ factor to the ‘what’ factor, eclipsing the emergence of a more commoditised alternative gaining a foothold. This is a highly effective point of attack when coupled with a reminder of achieving ROI on the last n-years of similar investment right ?!

The web, by contrast has simplifed and commoditised the same kind of end product, and evolved a user community purely focused on the ‘what’, without a care for the ‘how’ factor. As such it is relatively simple to decouple a user of a web-application from any underlying technical infrastructure, so long as the QoS and the ‘what’ factor is maintainted. Would I even know if my Thunderbird/Outlook mail client began using a competely different store-n-forward protocol? I don’t believe I would.

I believe we need to bring this learning into the enterprise space, and detatch our ‘how’ users from the underlying detail and coaching them to become ‘what’ users, such that we in the integration layer can get to work commoditising the technical fabric in such a way that we do gain the necessary ‘specialisation’ from key vendors, but in the main, we regain control/choice of what it takes to actually pass an ‘xml document’ from source to destination, across a trusted network we control, and guarantee it gets there in one piece.

We seem to have missed this…as it doesn’t cost me six 0’s to hook into, and run an effective real-time business over the web now does it?

Powered by Qumana


REST: Logical, Cosmetic or Fundamental

June 24, 2008

In my experience the successful application of the RESTful architectural style to any given software integration opportunity, requires an appreciation of the levels of RESTfulness gained from the relative levels of effort expended. I will attempt to explain my interpretation of these and identify where I see positive an negative implications:

Logical REST

The approach where the interactions between agents are ‘designed’ as resource-oriented, based on a finite set of well-defined methods analagous to the RFC2616/HTTP ‘verbs’, or more generally a CRUD scheme. This kind of approach achieves common-ground in the design-space, but is not followed-through with a strict adherence to the RFC2616/HTTP protocol as a framework for implementation, possibly using a proprietary xDBC stack, language-specific binary protocol or heavy SOAP stack. As such we see a logical resource-oriented perspective but with none of the true benefits truly embracing the web as a foundation.

Advantages

  • Achieve uniformity in resource/interface design.
  • Establish a common inter-domain design philosophy.

Disadvantages

  • Not addressing the heterogeneous middleware friction.
  • Stopping short of realising the full value of REST.
  • Little or no departure from traditional CRUD data-access.

Cosmetic REST

This is possibly the most common category where a Logical REST design is implemented within a RFC2616/HTTP framework, exposing concrete resource addresses on well-defined http URI’s in a web-compatible manner. However, the cosmetic dimension relates to the fact that these RESTful endpoints are thin, ‘cosmetic’ wrappers over traditional RPC oriented service endpoints, effectively acting as proxies. As such Cosmetic REST is of benefit to clients who have less intellectual and technical friction in consuming a service, but do little to thin-out the general integration sprawl within the domain of the service-provider. As such the addition of public RESTful to private RESTless bridging increases the integration burden of the provider.

Advantages

  • Creation of real RESTful service endpoints removing technical friction from clients when consuming service.
  • Unhook clients from internal integration dependencies by providing a uniform, intuituve interface.

Disadvantages

  • Increases the integration burden of the provider.
  • New facade on existing brittle integration points.
  • No increase in productivity gained from supporting simplified exposure.

Fundamental REST

This approach is a full application of the architectural style in a deeper sense than the cosmetic use of the HTTP protocol in exposing interfaces. Resource oriented design of a system is a significant departure from simply exposing functionality or information services from a complex machine using some arbitrary exposure/protocol dialect. Instead resource orientation inverts the ‘functional’ exposure of traditional RPC styles of integration by facilitating an information-first (not functionality first) interaction between a client and a system. In simple terms your interaction with a true RESTful system is through the manipulation of these resources, where creation, updating or deletion of resources or resource-atributes has explicit (or implicit) behaioural contracts which will conclude within a stateless atomic context. This completely decouples a client from the internal workings, dialects, processes, etc of a traditional approach to opening out the functions within a ‘RESTless’ system not based on the resource orientated architectural style.

Advantages

  • Cleaner relationship between RESTful exposure and implementation of underlying system.
  • Reduces the ‘thickness’ of interation logic sitting between the network addressable endpoint and the implementation.
  • Integrate clients with your information and not your process and/or functional granularity.

Disadvantages

  • Despite the RESTful or resource-oriented architetural style being synonymous with the web, it is still perceived as a ‘new approach’ in the context of internal enterprise business systems.
  • A more significant mind-shift is required before this appreciated
  • Still little hard evidence of the positive implications of resource orientation over traditional approachs  –  it just ‘feels’ like the right thing to do.

In my experience to date, for anything other than a green-field web-application which may go directly to a Fundamental REST approach, the larger integration challenges associated with service enablement of a more complex enterprise or enterprise system will ultimately start life, as we have, in a Cosmetic RESTful approach – most likely resulting from the combination unmovable silo’s of historical investment, as well as the limited impact of a Cosmetic or Facade based approach when breaking new ground.  In such cases the cost-effectiveness of REST and resource-orientation do become hamstrung, purely because to exploit REST you have to build more layers of mediation initially…until the confidence in REST increases to a point at which true, or more Fundamental REST can be driven from the edge of the enterprise, down into the silos.


The Mean Machine on tour…

June 19, 2008


The Mean Machine on tour…

Originally uploaded by Wertster

We entered our first beach-touch-rugby tournament last weekend in Bridlington. Took some time to adapt to the tag-rules variant but made it into the semi-finals before running out of legs. Very respectable and a good day had by all :-).

We adopted the team name ‘The Leeds Winoes’ as a subtle play on ‘The Leeds Rhinos’ super league team. That is now our official brand…

More action here at the Leeds Winoes photo log.