The problem is that with SOA in general is that we are trying to tackle two really hard problems in one go; specifically one hard technical problem and one hard organizational problem (I'll leave it to the reader to decide which is the harder). The first is the need for integration technologies and approaches for the leverage of IT assets that actually works (seemingly a minor requirement or even an afterthought in many organizations). The second is the need not to bridge the Business/IT gap (see here for a discussion) but to eliminate the concept - to say there is an enterprise which achieves it's aims through business knowledge and IT capabilities which are inseparable. Some customers are moving toward such a model where projects are not conceived in the business world and then thrown over the wall to IT for implementation but where teams consist of business and IT folks from inception through to delivery and in some cases into the monitoring and optimization as well. Fundamentally the key concept, or rather the concept that should be key, in the business domain is the business process as it is really the delivery vehicle for the value that a business provide. And yet right now in IT we have so many key concepts you'd need to sit for a week with a dictionary to get to grips with them - the concept of a service has the value of providing a single abstraction that due to it's granularity can be used to describe the actions performed as steps within a business process, this there is a common vocabulary now in terms of business actions and services. It is in this approach that we see the real need for an enterprise-wide view of the services that IT provides, the capabilities of the IT that support the business processes, we need to be able to identify services that exist that may be reused in a given solution, we need to be able to see the current and planned interaction between services as we expand the portfolio and finally we need the ability to use this information during design, implementation and integration phases.
I read a good article entitled Service Orientation in Enterprise Computing from Mike Burner at Microsoft while I was traveling and Mike touches on some of these topics (and uses the service portfolio term). Specifically Mike introduces the separation of service orientation as the technologists view of the patterns and practices for service development, and the Service Oriented Enterprise or SOE which is the set of processes used to manage the IT service portfolio.
Each well-designed service and service-oriented solution becomes part of the organization's technology portfolio, components in the service-oriented enterprise. The hallmarks of a successful SOE are rigorous service factoring, a thorough, forward-looking integration strategy, and a common, coherent approach to the management and governance of services and solutions.
This separation is very useful as it allows us to describe the set of processes that govern development of individual services, that govern the development of a solution and that govern the management of the service portfolio as separate lifecycles that share common goals and many common activities. In this regard IBM is set to extend and re-release the current RUP for SOA plug-in with specific guidance on the development of a service portfolio as a broader governance activitiy. This additional guidance, developed in conjunction with our customers, we hope to be able to make available on developerWorks before the end of the year.
This does lead us nicely back to a point made in the first paragraph above, when you start to discuss the term SOA Governance you very soon end up discussing SOA Registries. As we have seen, this is inevitable as the nature of the SOA Governance processes are to manage the service portfolio, one expression of which may be through a service repository. However, there is a second aspect here, which is a vendor and analyst push to convince uss that we all need a global run-time repository of service metadata. In the RUP we certainly recommend that there be a design-time model of the services in your enterprise, if you are using modeling tools to design your solution from services it seems only appropriate to have your portfolio accessible in the same medium. However we do discuss the need for, or at least the desirability of a central repository for service specifications and additional information. So should we not be able to provide concrete guidance on the form this repository should take? Well as it turns out we have a number of standards applicable in this area as well as a number of vendors competing for the limelight. So what about standards in this area? Well it seems we have a choice of standards, both interestingly enough now under the OASIS banner, UDDI and ebXML Registry as well as the possibility of using the Reusable Asset Specification (RAS) as a means to describe the metadata associated with services. As for vendors, there are companies such as such as LogicLibrary looking to recast existing repositories for an SOA purpose as well as new players such as Systinet, Infravio and AmberPoint providing a specific SOA play.
- Note, when using the term services I do not imply a) web services, there may not be any HTTP or SOAP in sight, and b) that these are new-fangled things, COBOL on CICS is still a fine way to build IT capabilities.
- While most of the above vendors have chosen to build repositories around UDDI one, notably Sun (Sun registry) has chosen to also implement the ebXML registry.