This Week’s Micro-Obsession

July + Sunshine + Arctic Wind =>

Geek + Wifi + (Geek Fuel == Books) + Garden =

Green Spiky Mental Energy

Having spent some months working in an application centric continuous integration and test-oriented developement project I am now wondering how I ever survived without it? The mental loading you have to bear if you manage the ‘virtual’ CI in your head is a pretty heavy price and detracts from the creativity at the sharp end as a result of mental-resource-contenton. Having experienced the CI model for the first time, I’m a complete convert and have been amazed how simple it is to create a very effective CI process out of public-domain tools…

Now exploring if the same automation can actually be exploted to the same extent, with the same degree of certainty being introduced into large scale integration projects through a synergy of SOA and Contract-First design philosophy, Cross Domain Test Driven Development where I write tests against your contract, Continuous Integration meaning explicit verification of tests against contracts and implementations of contracts. This takes the concept I’ve been hearing about – that associated with ‘integration of components’ witin an application or system, and expands it out to sit across numerous application / system engineering projects to provide an overarchiing, verifiable build or ‘integraiton’ process triggered by modifications to key aspects of what defines the inter-domain contract.

Interesting challenge…

More later.

Powered by Qumana

Is ‘Mandatory Community’ Still a Community?

In the public domain people form real communities out of true, intrinsic personal interest and gain (or at least that is the motivation initially). As such the cost of entering those web2.0 communities – ‘purchasing’ the infrastructure to gain access the the web (i.e. a pc and a pipe) and conforming to the globally agreed web protocols and community behaviours, is trivial when compared to the benefit we attribute to being part of a community and gaining the knowledge, support, respect, participation, belonging, etc.

The phenomenal growth we see in specific aspects of the web community, especially those formed by knowledge based or more proactive open-source engineering communities has changed the world in a sense that a new, viral, problem solving engine has been created to harness the grey-matter of an ever increasing resource-pool.

It’s amazing to think that such a powerful entity has been formed on a purely volutary basis by people sharing little more than a common interest. Looking to this kind of community model as a means of increasing innovation and collabration within the workplace is a natural aspiration, and a valid aspiration, but I’m wondering if the essence and the inherent success of the open community model does actually translate effectively into the closed community model (I refer to that which exists between employees within a large organisation).

When we look at the motivations of individuals in the workplace I am guessing that the vast majority see their labour as a means of generating income and as such tune their labour inputs to a level which is comfortable in respect of the income generated. Within that population we then have a subset, and I would argue a small subset, who generally aspire to going the extra mile and see their labour as an opportunity to take things to the next level – using that as a means of justifying increased effort with the goal of longer term reward. Regardless of the numbers/ratios, my point here is that the population within this kind of community is less interested in the value of the community model than those who choose to opt-in to an open community such as those we see in the public domain.

If we therefore make participation in the community a ‘mandatory’ obligation, with an expectation of quantifiable value, over and above meeting the daily functional goals against which we are measured and rewarded, I fear we are likely to alienate more than inspire. This does not mean I have no faith in the community model, I believe I am someone who aspires to more than ‘breaking-even’, but more of an interest in terms of how much we can expect to gain from the imposition of community on a mixed popultion of employees, who at best may form pockets of shared interest. I guess a large part of this is the business-as-usual model by which we stay in business. Add to that the associated issues of corporate regulatory policy and intellectual property rights which further isolate the enterprise community from the public domain and again we’re further limiting the viral expansion and value generated from this kind of model.

Funny that probably the most effective shared-interest community I can see in my enterprise today is the Union, which is not entirely focusing on the same goals as that of an innovation-centric community like apache now is it?

“In human communities, intent, belief, resources, preferences, needs, risks, and a number of other conditions may be present and common, affecting the identity of the participants and their degree of cohesiveness.”

Powered by Qumana

Enterprise Integration: SOA “re-use” is a wolf ?

Is our focus on achieving Service re-use actually harming the work we’re doing in the creation of the SOA? Are we so focused on the re-use model that we’re damaging the implementation of the SOA blueprint? Let me try explain why I believe this is the case.

Re-use is a measure of what? In some cases it means how much common code is duplicated and leveraged in new software developments. In other cases it means the more literal measure of concurrent exploitation of a shared resource. In our SOA governance structure, re-use is definitely analagous to the latter case – the one-size-fits-all coarse grained, generic service that enables me to service all variants of any particular requirement through a single, common service interface. Breathe………..!

That’s great for the provider who can now hide behind the ‘re-usable’ facade, pointing knowingly at the SOA governance literature every time you try to have the conversation that his service requires a PhD in data-modelling and xml cryptography to use it?

“But it’s re-usable” comes the reply as you weep, holding out your outstretched arms, cradling the tangled reams of xml-embossed printer-paper representing the only ticket into the service you need to use to avoid being branded a heretic. “Are you challenging the SOA governance policy? Let me just make that call to the department of SOA Enforcement…err I mean the Chief Architect…what’s your name again?” comes the prompt follow-up as the hand reaches for the phone…

I’m now convinced that re-use is a proverbial wolf in sheep’s clothing. We must look more closely at the cost of creating and operating these ‘jack-of-all-trades’ services, not just the fact that we can create them. If it transpires that we’re incurring more cost (both financial and operational) at both the provider-side and the consumer-side, by virtue of aspiring to ‘re-use through generalisation’ then we have truly lost the plot. Could this be part of the reason that SOA ROI is such a difficult subject to discuss and often results in a “year-n payback” kind of response?

I also think there’s an analogy to make here. Take one of our local government services which are considered part of the service fabric of our community. If the services are made too generalised and therefore spawn highly complex forms and a high level of complex dialogue in face-to-face scenarios, who is that helping? Yes we can say that we’ve consolidated ‘n’ simpler services into a single generalised service and saved on office infrastructure and so forth. But if we then increase the cost of processing requests for that generalised service both in terms of ’steps’ to get from the generalised input to the specific action (therefore requiring larger offices in which to house the longer queues) and also in terms of now having to cater for the increased and excessive fall-out volumes based on the fact that it’s just so damn complex to fill the forms in (therefore requiring even larger offices to in which to house the even longer queues)….then we really missed the point about re-use.

It makes complete sense to look to generalise and re-use in the SOA design-space, such that we can converge similar designs to a common reference model and avoid the unconstrained artistry of technicians with deadlines. In terms of service contracts and interface specifications through,  translating that design-time re-use to a wire-exposed endpoint seems like we’re stopping short of the ultimate goal of accelerating re-use by empowering consumers to bond more efficiently with that service.

Powered by Qumana

Enterprise Integration: Don’t Look Down !

Can SOA truly be successful if service consumers have to be technology consumers? The service layer is supposed to insulate us from the technical complexities and dependencies of the enabling technology, but I see more and more the technology being the centre of attention.

The promise of Web Serivces whilst standardising on the logical notion of integration,  has embroiled us in a complexity relating not to the ‘act’ of exchanging documents, but instead relating to the diversity within the Enterprise, the various technologies and tools used across a widely disparate ecosystem, and debating the finer details of which interpretations of which standards we want to use.

More significantly the large deployed base of messaging software, and the service endpoints exposed to MQ or JMS endpoints are left out of the handle-cranking associated with the synchronous style of endpoint. As such – a SOA layering ‘consistency’ across such a diverse ecosystem is a myth in my experience. We’re still struggling to find the SOA ‘blue-touch-paper’ despite all of the top-down justification and policy.

I believe that until we push the technology further down towards the network such that it becomes irrelevant to the service consumer, and raise the service interaction higher up in terms of decoupling the ‘interaction’ from the ‘technology’ we are going to struggle to not only justify the benefit of service orientation, but more significantly we’ll continue to struggle to justify the inevitable rework and technical implications of that service orientation in mandating conformance to brittle and transient technical standards.

I’m going to explore an approach to doing this – by encapsulating middleware facilities as RESTian resources, and then looking at the bindings between WSDL generated stubs and these infrastructure resources…effectively removing technologies (apart from the obvious RESTian implications) from the invocation of a web-service. Various header indicators can flex QoS expectations in the service invocation (i.e. synch or asynch, timeouts, exception sinks etc) but that has no relationship to any given protocol or infrastructure type. Furthermore, the existence of such a set of ‘resource primitives’ would enable direct interaction where WSDL-based integration does not yet exist…where I resolve, send, receive and validate though direct interaction with RESTian services from any style of client-side application.

This is motivated purely by the belief that, much like the chap in the picture, our focus is on the endpoint and not what lies beneath…