Archive for the “Service Oriented Architecture” Category

CBDI’s David Sprott released an article (free registration required) yesterday that updates the SOA Maturity Model that they originially published in 2003. The article starts with a quick tour through the recently published models from Sonic/AmberPoint/Bearing Point/Systinet, IBM and BEA before discussing their updated model.

In the SOA Vision section, Sprott makes the following observations about SOA:

  • SOA is as much a business modeling approach as it is a software engineering paradigm. Today SOA might be mostly about technology, but by the time we are finished business and IT will share the service perspective in business processes, products and in planning.
  • Service-oriented architecture is a design approach to standardize business processes and software functions, or services, so that numerous dissimilar value chains and technologies can share them—both inside and outside the company. The standardization however is also balanced with the capability to assemble differentiated business processes that can support innovation and strategic goals.
  • Our fundamental objective with SOA is to achieve broad sharing of services in new runtime contexts in order to deliver an inherently agile business environment. We do this by decoupling solutions from providing resources supporting both business and infrastructure services.
  • Comments No Comments »

    Brenda Michelson is a Senior VP with the Patricia Seybold group where she focuses on SOA among other things. While reading through her Elemental Links blog this evening, I ran across a link to her “Service Oriented World” Cheat Sheet.

    This 15-page PDF provides some foundational definitions of the SOA architectural pattern as well as some of the buzzwords and standards that support it.

    As of this writing, PSGroup is providing this as a free download.

    Comments No Comments »

    Recently, I have had the opportunity to review SOA Maturity Models (SOAMM’s) from a few different sources for a project in which I am participating.

    Today I was on the phone with Michael Kuhbock, Chairman of the Integration Consortium and he pointed me to a recent ICBlog post he had written that takes issue with the usefulness of these models.

    Michael suggests that while SOA Maturity Models may be helpful for assessing an organization’s progress on the roadmap toward SOA adoption, they are not general purpose enough to be used to measure overall IT capability in the same way that a model such as the CMM / CMMI models.

    Michael quotes his Integration Consortium colleague, Jake Freivald, who writes:

    Suppose someone in the days of time sharing systems discovered that client/server systems were a brilliant way to create new applications. They studied the problem closely, and came up with a five-level model based on the CMM / CMMI:

    1. Initial client/server deployments – new functionality implemented in client/server technologies
    2. Architecture-oriented client/server applications – IT cost reduction and control
    3. Business-oriented applications – responsiveness of client/server applications to new business requirements
    4. Measurable business applications – client / server applications that provide metrics of how well an organization meets business goals
    5. Optimized business applications — client / server applications that can be reconfigured to optimize business applications automatically

    What should we do with this model?

    On the one hand, we should note that it does, in fact, provide a reasonable roadmap for the current technology. But we should also note that it’s nothing more than the CMM repackaged with a technological slant.

    That leads to objection number one: do we want a technological slant? The purpose of the CMM is to define optimal processes for all of IT, client / server or not. In fact, the CMM specifically defines an optimization step in order to help the organization absorb new technologies that can help it optimize its development processes. So does it make sense to limit our use of an IT optimization model to client / server technologies?

    And this leads us to objection number two: the model may show us when client / server usage is “mature”, but it doesn’t address the more important problem, which is understanding when client / server technologies themselves are obsolete. The model I propose above isn’t great, but it might be acceptable with some refinement — but who, these days, wants a client / server maturity model?

    Having left the cozy confines of a Big 5 consulting firm to pursue opportunities with a client / server consulting firm a decade or so ago, I can personally relate to not being able to see past client / server to n-tier, distributed systems and certainly not to web services and SOA.

    I would agree then that while SOA Maturity Models are useful things for now, we should all take care not to get so caught up in the technology-specific discussions of the day that we forget that something else always replaces today’s current new approach.

    Comments No Comments »

    I liked this defintion of Service Oriented Architecture contained in the IBM Redbook “The Solution Designer’s Guide to IBM On Demand Business Solutions”.

    Definition of SOA

    SOA is an integration architecture approach based on the concept of a service. The business and infrastructure functions that are required to build distributed systems are provided as services that collectively, or individually, deliver application functionality to either end-user applications or other services. SOA specifies that within any given architecture, there should be a consistent mechanism for services to communicate. That mechanism should be loosely coupled and support the use of explicit interfaces. SOA brings the benefits of loose coupling and encapsulation to integration at an enterprise level. It applies successful concepts proved by Object Oriented development, Component Based Design, and Enterprise Application Integration technology to an architectural approach for IT system integration.

    Services are the building blocks to SOA, providing function out of which distributed systems can be built. Services can be invoked independently by either external or internal service consumers to process simple functions, or can be chained together to form more complex functionality and quickly devise new functionality.

    By adopting an SOA approach and implementing it using supporting technologies, companies can build flexible systems that implement changing business processes quickly, and make extensive use of reusable components.

    Comments No Comments »

    Mark G. alerted me to the Apache Synapse proposal a couple of weeks ago. At about the same time Dave Linthicum, former CTO of Mercator, was sharing his thoughts on his RealWorldSOA blog.

    Despite the fact that he can’t spell “canonical” ;-) , I think Dave’s take is right. It’s too early to get very excited about a proposal that will require slow moving application vendors to add a “mediation layer” that probably won’t sell any more licenses or professional services.

    If the app vendors can figure out a way to cut their own costs by shedding themselves of deals with established integration vendors or by cutting out their own development costs then I think we could see increased adoption and traction for Synapse.

    Comments No Comments »