SOA represents a brave new world of system design. The business benefits - increased
reuse, reduced time to market, and lower total costs of ownership - are often
touted by vendors and analysts alike. A major challenge remains that the technical
aspects of SOA - WSDLs, schemas, and the like - are often much easier to articulate
and implement than the organizational and process methodologies associated with
how you actually achieve SOA.
Structure and governance help to guide the people, processes and applications
that make SOA successful. As with any emerging society, the participants within
an SOA environment need a common governance framework that provides the rules
of engagement, in order for everyone to reap the associated benefits.
As we talk with IT organizations, too often we see them making the same mistakes,
pushing forward with the technical aspects of SOA without considering the governance
implications. Here are the most common mistakes we run into, and some tips on
how you might avoid them:
Mistake 1: Decentralizing common artifacts
When common artifacts such as WSDLs, schemas or configs are scattered in various
locations, organizations waste time searching for interfaces and schemas. This
is because they lack a central authority for the published service interface,
which discourages discovery and reuse across an enterprise.
Solution: A centralized authority
Creating a centralized repository or registry allows others to more easily
reuse artifacts and utilize an authority for what services, schemas, and applications
are available. It also enables an organization to track not just what is available
during design-time, but also what services are running in production. More often,
an organization must mandate the use of a registry or repository otherwise it
will be ignored and no SOA benefits will be realized.
Mistake 2: Reinventing the wheel
In the typical decentralized IT organization, services and applications are
often written again and again to perform the same function. As a result, many
different versions of the same artifact are built and integrated, increasing
development times and creating a huge maintenance cost burden.
Solution: Collaborate and recycle
The way to avoid falling into this trap is simple. Share requirements and collaborate
on building artifacts. Reuse applications, services, and artifacts whenever
possible and use a centralized repository or registry to store information,
discover existing services, and collaborate on new ones.