Java Reference
In-Depth Information
can remain supportive. Illustrate clearly that the real return on SOA is realized over the course
of several years, as IT may be more responsive and ready to quickly address changing busi-
ness needs.
Does the project have limited scope?
The project should have limited scope. It should represent functionality that is somewhat isol-
ated from systems that are not well known. But you will get the most out of your pilot project
if it does span multiple systems. It cannot be merely a proof of concept about web services,
but must be a full-blown, real-world project. Otherwise, you run the risk of underestimating
scalability requirements and overall complexity.
NOTE
Some practitioners recommend starting with a basic service set, and introducing the ESB and orches-
tration services later. In my view, you want to choose a project of limited business scope so that you
have the time and clarity to simultaneously introduce the ESB initially. You don't want to over-engin-
eer your solution, but if you are planning to connect your work with an ESB at some point, you won't
have to revisit this. Moreover, because ESB is not standardized, products offer very different features
or different means of providing certain functionality. You want to understand this central piece of
your architecture early on.
Introducing SOA can lead to a lot of new APIs for developers, new application servers, new
languages, and new infrastructure. It represents a new way of thinking about development.
Thinking in services is different from thinking in objects. Making a switch from functional
or procedural programming to object-oriented programming can take time, and represents a
dramatic change for developers. I have seen Java classes in excess of 15,000 lines of code,
with a single method 700 or 800 lines long. Just because you're writing in Java and a program
compiles and runs doesn't mean it's object-oriented, and doesn't magically make it good. Do
not underestimate the difference that services can represent for OO developers too. You need
to take the time to educate everyone on the team (though not necessarily at the same time).
That takes development time away. If the project has a very large scope, it might never be
completed when you have so many external considerations.
You want to be able to isolate unknowns so that you can more easily identify problems during
the development and quality assurance phases of the project. Be careful of choosing a product
that uses brand-new products. The team will already have a number of mysteries to deal with
when working with new infrastructure and APIs. Isolate your changes so that the SOA enable-
ment work can be a leading focus. Consultants can help here.
