pondering SOA the UK and Aussie way

Service-Oriented Architecture (SOA) is not for the faint of heart, nor for those weak in technology expertise. 
SOA is fundamentally a methodology for systems design, informed by an overall Enterprise Architecture (EA).

If you don't have the scale of organization, or the organizational technical expertise, to sustain an EA and advanced development group, then SOA may not be for you.  You may want to focus more on consuming services and connecting services together.

Or in other words, we just have the latest in a line of IT best practices:

• If you're big enough to have an extensive software development shop, use SOA as your guiding methodology.  If you have a smaller shop, you may use or develop services defined by some other group, in their SOA.
• If you're big enough to have substantial IT infrastructure, use EA to guide the planning for that infrastructure.

Keeping that in mind, the library environment as a whole is clearly of the scale to benefit from an SOA, it's just a matter of how we put it all together.  Who defines the services?  Who will the service providers be?  What will the business model be for service consumers?

All this by way of introducing some recent reports and presentations on SOA, as well as signalling that I will be providing more of my library SOA thoughts in a few upcoming venues.

Firstly the National Library of Australia IT Architecture Project Report (PDF) has gotten some attention for its prominent mention of SOA.  (Thanks to Lorcan for pointing it out to me, DLTJ also mentioned it today.)

Second, via Brian Kelly I see that there were recent JISC conference presentations on EA and SOA.

e-Framework, SOA and EA: Using the e-Framework, Service Orientated and Enterprise architectures to develop more flexible and better aligned ICT infrastructures  Abstract

• Session commentary
• Presentation "The e-Framework, SOA & Enterprise Architecture" - JISC (PowerPoint)
• Presentation "Enterprise Architecture" - Open Group (PowerPoint)

Overall I think both SOA and EA are challenging topics to present simply.  That being said, I think both are typically presented far over to the extreme of complexity.  What was it that the rather inaccurately titled SOA for Dummies said you had to have in your SOA?  ESB, registry, broker, supervisor, BPM, yadda yadda... It's simply not true.  That's what you'll get if you let the kindly vendor hold you by the hand and take you into the twisty SOA maze.  All you actually need for SOA is to make sure you're using some basic software design principles:

autonomous, loosely-coupled and coarse-grained services with well-defined interfaces that support

the flexible reuse of application logic through composition

(The above an extraction from my 2005 presentation "Service-Oriented Architecture Methods to Develop Networked Library Services" which I am uploading to Slideshare... now.)

The same for EA.  Zachman is all well and good, but you need to be a mega-corp to fill in all the Zachman boxes, and even then the methodology doesn't help you much in translating that knowledge into action.  CISTI uses a much simpler and more practical methodology (based on InfoMajic) that focuses on translating business needs into an implementation framework.

There is lots of work and complexity in doing feasible EA and SOA without making it even more complex.

This may be why most of the published outputs available for library SOA are currently at such a very very high framework level.  I have to say, these frameworks don't do much for me.  As a technology person, all I see is some Dewey Decimal system for services, a top-level set of categories.  To actually start doing any service implementation work, you need to go much deeper, with models of how the detailed business functions inter-connect and inter-relate.

I wish I knew how to take the overall library community to that next level.  e-Framework (JISC - DEST - NZ MoE - SURF) is a piece, DLF Services Framework is a piece, Knowledge Exchange (JISC - DEFF - DFG - SURF) http://www.knowledge-exchange.info/ is as well... Maybe it's simply impossible given the scales of organizations involved to go beyond the highest-level conceptions.

All I know is we at CISTI can think of some relatively easy Web Service wins within an overall SOA - copyright / pricing services, query services - there are lots of possibilities.  Until we start getting more service providers and consumers up, we're all sort of stuck.

What do you think?  Is SOA too abstract or unachievable for your organization?  Are the service frameworks too high-level to impact on your development work?  Would you actually consume some library Web Services if more were available (keeping in mind the service interface might be simpler than full SOAP).  Are there services you're already providing that aren't being consumed?  Are the digital library people producing services that aren't being used by the rest of the library?  The Fedora repository already has Web Services, Amazon and Google already do - where do you see libraries fitting in?

Lots of questions... any answers?

I feel that I'm kind of reaching the limits of what I can do in terms of fairly abstract SOA evangelism - and I'm hoping there may be some concrete initiatives around which some services can coalesce...