Combining Service Oriented Architecture with a Single Business Approach

This month I've come across one great article and one great report on Service Oriented Architectures. The first came from Sally Rogers at Ohio State University in the form of an article from CIO magazine last year:

Koch, Christopher. 2006. The Truth About SOA. CIO Magazine, June 15. http://www.cio.com/archive/061506/soa.html (accessed March 27, 2007).

This article does a great job at laying the groundwork for the broad "what" and "why" (as well as the "why not") of SOA, and I agree with Sally that it makes a better introduction to the topic than most of the white paper that I presented at the meeting. The two best paragraphs out of the article come towards the very end:

In the '90s, your integration strategy was simple: Buy as many preintegrated applications from a single vendor as possible. That worked for you, and it worked extremely well for the vendor; integrated application suites fetched a high price and required long-term maintenance and support contracts that promised a steady, predictable stream of revenue from customers.
[...]
But the rise of service-oriented architecture has produced a shift in integration strategy. SOA makes the radical assertion that the enterprise application infrastructure is irrelevant. Technology is constructed according to services specified by the business, not by processes contained within an enterprise application vendor's software box. In this scenario, packaged software is a piece of the service, just another component in a larger business process — such as an insurance claims process that links a jumble of functions and data inside [Enterprise Resource Planning], [Customer Relationship Management] and old mainframe legacy systems. The application's vendor doesn't matter anymore; the linkages between the applications is the important thing.

Does that sound familiar to anyone? I'd like to couple this with a paragraph from the report by the National Library of Australia on a "Single Business Approach" (discovered via a blog posting by Lorcan Dempsey):

IT Architecture Project Report. 2007. N.d. National Library of Australia. http://www.nla.gov.au/dsp/documents/itag.pdf (accessed March 28, 2007).

The paper defines Single Business Approach in a library context this way:

Even with a service-oriented approach, the Library's capacity to meet its directions will continue to be eroded as new applications are brought online. As budgets continue to tighten and the Library needs to do more with less, there will come a time when a large proportion of development effort will be spent just maintaining existing applications.

To address this issue, and as part of implementing the service-oriented architecture, it is proposed that the Library regard its digital library services as a single business with a single data corpus that can be deployed in a range of contexts. Rather than developing separate applications to meet a new requirement, each requirement would be viewed as an enhancement to the business that could be deployed across all relevant business contexts.

This is a significant change to the way the Library currently works. As well as resulting in further significant efficiencies for IT staff, it has the potential to bring library staff together in unprecedented ways to work on problems and ideas and to prototype solutions that enhance the user experience regardless of the point of access.

The Australia report focuses on this Single Business Approach along with SOA and the adoption of open source solutions to come up with a vision to support the management, discovery and delivery of the National Library of Australia's collections. There is a lot here that could be adopted to other similar situations, such as OhioLINK's.

The text was modified to update a link from http://www.cio.com/archive/061506/soa.html to http://www.cio.com/article/21975/The_Truth_About_SOA on June 9th, 2011.