Start from the top down or the bottom up to zero in on a set of possible candidates, and know that you will likely approach development from the middle out, according to business process requirements.
Recalling that the term “service” does not imply any specific implementation platform, a proposed piece of software might be a good service candidate if you can affirm at least some of the following criteria:
Could this functionality be appropriately designed to satisfy the definition of a service as stated in this chapter?
Is this service likely to be consumed across multiple platforms? Does it need to interoperate? Would external business partners have any use for this service? Does it need to cross functional barriers or firewalls? Can it use a popular protocol such as HTTP or SMTP?
Would implementing this functionality as a service help you break an integration barrier? Would it wrap or replace a proprietary point-to-point interface? Would it operate in front of ERP, CRM, financial applications, or other systems?
Does it clearly map to one or more business processes? Or is it simply a program? (It is generally accepted that services can map to a single process, but mapping to more than one process can offer more opportunities for reuse.)
Does the function that the proposed service represents cross business domains? This could point to a greater opportunity for reuse.
Does the service exchange business documents or fall readily into one of the three general service categories identified in Identifying Different Kinds of Services.
Would a business person be interested in reports on the output of this service? Would IT be interested in monitoring its life cycle or runtime? Or perhaps it represents a functional or utility service that in the long term could increase general business agility. (If none of these, it may be too small an operation to merit a place in the service catalog.)
Does it offer business value? Is there an existing service commodity that already performs this function?
Is the proposed service the right level of granularity? (If it is very fine-grained, this will weaken the interface aspect of the contract, shrink the possibility of reuse, and promote undue chattiness. If it is very coarse-grained, it could be a candidate for a process service that decomposes into other entity or functional services.)
Would making this function a service allow it to be composable? That is, can it participate as a seamless blackbox with other services behind a unifying contract (like an orchestration)? Or does it represent just an isolated function, with little relation to other system components?
Does the candidate represent an idea with an identifiable life cycle? Can the business define the interface?
Is it advantageous if the software can be discovered dynamically (as from a registry/repository)?
Does it present an opportunity to aid in the goal of providing a “single version of the truth”?
Depending on the implementation, would the benefit derived from using XML to represent your data outweigh the performance hit for marshaling and unmarshaling to and from XML? Is human-readability of the documents exchanged a factor?
Would implementing this as a service lower the cost of future integration projects? Would it facilitate new products or business services?
Again, these are just points to consider. There are no hard-and-fast rules in this area. The idea is to make sure that you don’t run out and make everything into a service. I know of companies that did this years ago; they now have more than 5,000 “services” and they’re in a lot of pain. Just use this as a guideline.
Not everything in your enterprise can or should be made a service. Do not fall into the “tool trap”: if you have a hammer, everything looks like a nail. There are many real and important problems that services and SOA simply do not address. Once you have established SOA as a goal within your organization, it may be tempting to declare that every new project coming down the pike should be written as a service. This is not going to aid in the creation of a functioning SOA that gives you a real return on investment in the long run. It will, however, start the process of building out Just a Bunch of Web Services, the anti-pattern mentioned earlier.
But the fact of the matter is that you do have some services to build, and some SOA infrastructure to get in place, and so the question remains: “How will I know a service candidate when I see one?” As you start building out your service catalog, it is important to have solid criteria for determining what should and should not be a service.
It is important to conduct interviews with business segment leaders and use other information gathering techniques to understand the business models that you will use as the basis of your service elicitation analysis. Ultimately, such models will be the real key to deriving service candidates. It is this model that can be iteratively refactored in order to determine if the appropriate boundaries have been defined for the service, and that it meets an appropriate level of granularity.
As you begin to populate your service catalog, and through the life of your SOA, there are two basic approaches that you can use in analyzing and assessing your enterprise to discover service candidates.
While the checklist just shown features a number of useful questions, it should be viewed only as a guideline. When you as a developer/architect are asked to determine if some proposed software should be written as a service, refer back to this checklist, and you’ll be well on your way. In time, you will likely start to tailor your own set of criteria.
A top-down approach starts from a high-level business view. Using this approach, you examine a road map laid out by the business that sets established business goals for a given time frame. You then evaluate the goals for potential service creation. This is not a process that simply maps a list of prioritized business projects directly to services. It requires instead that you use existing architectural documents and business process modeling techniques to determine what in your enterprise would make the most sense if written as a service.
The architects, CTO, CIO, or other responsible party in your organization should have an IT roadmap that is based directly on a business roadmap. That roadmap may exist at various levels of granularity or span a variety of timelines or departments within IT. But such documents can serve as the basis for identifying hot topics that can be examined as candidates for service creation. The roadmap itself, if it exists, will be too high level for service design. But once items on the roadmap are approved for work, start with identifying the business processes that are involved. Mapping the business processes required by a project will often point to an external system that you might be able to integrate via services, and will frequently point to internal systems that can be wrapped as services.
Many IT projects include a user-facing presentation layer. Often, only certain aspects of a project should be written as a service on the backend. Service-oriented architects need to communicate with project managers across projects or products to coordinate their efforts. This can be challenging in an environment used to dedicated project teams.
Businesses that are relatively young, have few disparate systems, or are generally very forward thinking might benefit most from this approach. It is easier for businesses to champion SOA efforts in such a scenario, as they get new products delivered that have been on their wish list.
A bottom-up approach starts from the view of a legacy technology. It takes existing functionality and wraps it in a service in order to achieve more general business goals such as increased agility, interoperability, or eased integration. This can sometimes be termed “service enablement”: the basic functionality exists already, but you make it available as a first-class citizen within a service-oriented architecture.
This approach starts by identifying “pain points” within the enterprise that could be usefully addressed as a service. This is a common approach if you have had no architects doing forward planning work with your systems integration, and find yourself with an “accidental architecture” of rampant, undocumented, proprietary, or generally ugly point-to-point communications. If this is the case, you must approach such an effort with caution, taking care to understand the processes that are already using this tightly coupled functionality.
The business realizes value with this approach by freeing up previously complicated intersections of technology for greater agility and flexibility going forward. This can translate directly into shorter time to market.
This approach may work best for companies that have been in business for decades, have lots of legacy systems, use a wide range of disparate platforms (possibly as the result of many mergers or acquisitions), or have many existing point-to-point connections. But beware of simply taking the existing interfaces of these legacy systems and then making a web service out of them. A bad interface that runs with SOAP over HTTP is still a bad interface. Designing the interfaces so that they will be usable going forward often means that you have to do some overhaul within current state business models (that you might have defined using a top-down approach for something else).
A bottom-up approach rarely works. IT can end up being the driver, which you don’t want. The business needs to be aware of SOA and assist in the governance and the definition of processes. The interfaces of the future are not likely to be found in legacy code. Legacy code can be wrapped with new interfaces. And this usually means that you start not at the top or the bottom, but in the middle, according to the requirements of your business processes. You can then find ways to reuse existing systems with a new facing appropriate for the process.