The ĎLonger Viewí on SOA Reuse

*Editorís note: This article is an expanded version of The SOA Collaboration Challenge, published in May 2006 on ebizQ.

Moving to SOA isnít just about implementing new technologies, defining interfaces and creating services. Itís also about creating, fostering and enabling a more collaborative development process and collaborate technology environment that most organizations are used to.

While the payoffs from transitioning to SOA can be bigógreater agility, increased efficiency, etc.ódoing SOA right requires some significant changes to the traditional development lifecycle. Or, more appropriately, it requires a rededication and realignment of the traditional development lifecycle. Especially when it comes to capturing the benefit of reuse.

With SOA, the work begins when a development team starts to create a new serviceóbut the work actually starts once that service is successful and the team needs to find efficient ways to support that service across multiple applications and across different projects throughout a company, coordinating updates, providing support, and ensuring consistency and quality over time and over different forms of deployment.

As a result, SOA development isnít just about development. Itís also about collaboration and lifecycle support. Doing SOA right requires taking the longer view with an understanding to not just how services will be used, but re-used. You also need to understand what it will take to actually support, service and upgrade those services as they fan out across a distributed organization.

For example, a developer or business user may be using a service that was created by another department or IT group. What happens when they want to report a problem with itótheoretically they would contact a support engineer who would help them capture the environmental artifacts that can reproduce the problem for the developers or testers to verify against and fix. The service developer would come in and fix the service, run it through testing, and then release an updated version. The challenge is capturing all the relevant information for that process (and others) in a consistent and usable manner so that different production teams and users are operating effectively and efficiently.

In other words, itís the SOA lifecycle and reuse challenge. Letís look at what it takes to meet the SOA lifecycle challenge and make services reusable. Service oriented architectures require services, and to use more than one service you need to have a way of keeping track of services. Reusing services requires the ability to find, identify and use pre-existing services. Hence the rise of SOA service registries. SOA registries are services which themselves keep track of other services. Organizations can use service registries based on web services standards such as UDDI to help them identify and connect to appropriate services for their needs. Itís the initial step toward creating an environment where services can be re-used.

But, SOA registries aren't enough when it comes to creating an effective and efficient SOA infrastructure. Whatís needed to support the entire lifecycle requires more than just tracking the technical aspects of servicesóit also requires that companies set up ways to track, communicate and collaborate on the definition, creation, deployment and management of services. Whatís needed is a collaborative SOA environment.

Registries are great for keeping track of some of the programmatic requirements for services, but they donít necessarily help you learn about the serviceóthey canít help you understand when and where to use a service or how to use the service, they canít provide suite of associated test modules, and they donít necessarily provide insight into the definition or requirements or discussions that went into the creation of the service.

Another aspect to consider is governance and policy issues. For example, governance issues can be particularly important as organizations start to scale up their SOA efforts. In many cases, organizations will be defining policies around the definition and use of their services, (such as the WSDL contracts) and theyíll need to ensure that those polices are enforced consistently. For example, some WSDL contracts can be incredibly complex and might have hundreds of schema documents attached, leaving a tremendous amount of room for misinterpretation between business analysts, architects and business users.

Testing is another area thatís important to consider when planning your SOA strategy and considering how teams of developers may interact with SOA services. Whether an organization uses or adapts their existing testing tools (such as tools from Compuware or Mercury Interactive) itís important to determine how services and composite applications will be testedóeven in the cases where services are not completed or inaccessible.

Simulation capabilities can be important in these types of cases, where you need to be able to allow developers to create a simulation of a service (or of multiple services). This can be important if the service youíre connecting to is not available (perhaps itís not developed yet) or perhaps its actually a mainframe service thatís only available at 2:30 in the morning or during limited times (or via a customer or partnerís extranet). A good solution will be able to simulate what a service looks like to the outside world (even if the service isnít defined yet), so that developers and testers can understand and simulate how the service will eventually appear.

Another aspect of whatís needed is the capability to create a community around the services within an SOA environmentónot just a repository of the technical specifications of services and how to invoke them, but a multi-faceted environment that will let developers, testers, operations personal and potentially even partners or customers gain a broader understanding of how services are defined, where they should be used, and how theyíre supported.

The end result is that services can get developed faster, reuse becomes more effective, support becomes possible and business analysts, developers, testers, and operations people can work together as a team. In the end, I believe that once you move beyond SOA pilot projects, you really canít do SOA without effective collaboration capabilities.

About the Author

David Kelly - With twenty years at the cutting edge of enterprise infrastructure, David A. Kelly is ebizQ's Community Manager for Optimizing Business/IT Management. This category includes IT governance, SOA governance,and compliance, risk management, ITIL, business service management,registries and more.

As Community Manager, David will blog and podcast to keep the ebizQ community fully informed on all the important news and breakthroughs relevant to enterprise governance. David will also be responsible for publishing press releases, taking briefings, and overseeing vendor submitted feature articles to run on ebizQ. In addition, each week, David will compile the week's most important news and views in a newsletter emailed out to ebizQ's ever-growing Governance community. David Kelly is ideally suited to be ebizQ's Governing the Infrastructure Community Manager as he has been involved with application development, project management, and product development for over twenty years. As a technology and business analyst, David has been researching, writing and speaking on governance-related topics for over a decade.

David is an expert in Web services, application development, and enterprise infrastructures. As the former Senior VP of Analyst Services at Hurwitz Group, he has extensive experience in translating the implications of new application development, deployment, and management technologies into practical recommendations for enterprise customers. He's written articles for Computerworld, Software Magazine, the New York Times, and other publications, and spoken at conferences such as Comdex, Software Development, and Internet World. With expertise ranging from application development to enterprise management to integration/B2B services to IP networking and VPNs, Kelly can help companies profit from the diversity of a changing technology landscape.

More by David A. Kelly

About ebizQ

ebizQ is the insiderís guide to next-generation business process management. We offer a growing collection of independent editorial articles on BPM trends, issues, challenges and solutions, all targeted to business and IT BPM professionals.

We cover BPM standards, governance, technology and continuous process improvement, as well as process discovery, modeling, simulation and optimization, among many other areas. We follow case management, decision management, business rules management, operational intelligence, complex event processing and other related topics. We closely track important trends such as the rise of social BPM, mobile BPM and BPM in the cloud. We also explore BPMís use in functional areas, such as supply chain and customer management, and in key verticals, such as financial services, health care, insurance and government.

ebizQ's other BPM-oriented content includes podcasts, webcasts, webinars, white papers, a variety of expert blogs, a lively online forum and much more.