Java Reference
In-Depth Information
miss certain requirements, or fail altogether. Choose a project that won't undermine your busi-
ness if it takes some extra work to get it up and running as a service.
This makes service enablement of existing pain points an attractive pilot project. There is
already a process or functionality in place to fall back on should it prove necessary. Obviously
I am not recommending that you plan to fail, but things happen, and it's smart to be realistic
about it up-front.
NOTE
The fact of the matter is that services are hard. They are hard conceptually, and they are hard prac-
tically. There is enormous complexity added to an environment to make your services portable, re-
usable, composable, and interoperable. They are difficult for both the business and IT to wrap their
minds around.
Do some research on architectural frameworks, methodologies, and design patterns, and select
some that will support you best given your environment.
The second pilot
Once you have completed the initial pilot, the second project, which should probably be con-
sidered a pilot extension, becomes very important. The chief goal of the pilot is to establish
a foundation for SOA, understand the technical implications, and create something of value
using new constraints and new strategies.
The second project provides a key opportunity to build out some of the organizational
and cross-cutting concerns that SOA precipitates, such as governance (see
Establishing
Governance
)
. The second pilot will, for this reason, need to have a similarly limited business
scope as the initial pilot. Don't leap into rewriting your payment infrastructure with your
second SOA project. You need time to learn the behavioral patterns of your new tools and
time for the education and daily reality of running the production services environment to set
in.
You can also use the second project to build on your initial architecture. You may add func-
tional or meta services, such as a rules service or security service. You may introduce BAM
tools at this stage, or deepen your work with WS-Policy or security concerns in general. You
might clarify and refine how you will handle service versioning, which may not have been a
central focus of the pilot. You might take advantage of some more robust features of orches-
tration than you may not have had time or need to explore initially.
These things should have been laid out in your SOA roadmap. The roadmap will change, but
keep it updated, and remember that SOA is a long-term investment. Plan big, but start small.
