Java Reference
In-Depth Information
But the fact of the matter is that you do have some services to build, and some SOA infra-
structure 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 ap-
propriate 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.
Now let's turn to the matter of how to approach discovering service opportunities within your
organization.
Top-down or bottom-up approach
A top-downapproach starts from a high-level business view. Using this approach, you exam-
ine 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 determ-
ine 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 doc-
uments 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 pro-
cesses 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.
Search WWH ::




Custom Search