Java Reference
In-Depth Information
Establish organizational boundaries within IT. SOA represents a significant change in how
a business operates. It's not the case that, in the manner of Internet startup accounting de-
partments circa 1997, the SOA team should decide that all of the old rules don't apply to
them. But an enterprise that is used to operating with traditional project teams may find the
cross-cutting concerns of SOA very difficult to work with. Expect some resistance from
teams who may feel threatened by SOA. Expect resistance from a potentially large set of
tools that you may have in place to manage projects. SOA requires some organizational
change, and you need to be prepared to address this. While this step may gradually be-
come easier with each iteration of the architecture, each iteration will bring new concerns,
and it will likely remain an important a challenge.
3. Do the work. Get the tools, write the code, automate the processes, build out infrastruc-
ture, update build processes, flesh out the governance scheme, do whatever it is that needs
to be done to fulfill your concrete objectives. This is the execution step. Recall that SOA is
not merely a technological endeavor, so part of the execution is also to engage the business
to ensure that you have sponsorship and support. They must understand to some degree
what SOA is, why you're doing it, the organizational changes that are typically necessary,
and the new kind of input and involvement you'll require from them. At each iteration,
re-engage the business to ensure that you're still on the same page, and highlight the ways
in which future business initiatives will be supported by new SOA increments.
4. The final step is to optimize and adapt. Some of the choices that you made earlier might
need to be revisited. Determine how you can improve efficiency, interoperability, pro-
cesses, or other items within your SOA.
Create a set of roadmaps, each with a different scope. One might be a five-year plan for SOA
that contains general goals. Another could zoom in on a more confined scope, perhaps a year
or a quarter, and define tasks very concretely. It should indicate how you plan to address each
aspect of SOA:
▪ Governance
▪ Business agility and organizational shift
▪ Tools
▪ WS-* specs or other related supporting items to learn and use
▪ RESTful or WOA concepts
▪ Monitoring, KPIs, BAM
▪ Rules engines/rules as a service
▪ Security enforcement points/security as a service
