AmWINS Group

In many ways, Service Oriented Architecture is going through an extended "trough of disillusionment" (to borrow a phrase from Gartner). Industry experts seem to avoid the term, preferring to focus on the nuanced approaches that have built on the principles of SOA, like micro services and service buses. In my view, much of this embarrassment arises from the difficulties of maintaining a proper SOA environment once the initial build has finished. As an industry, we have done a terrific job of promoting the construction of service-oriented environments and a terrible job of figuring out how to maintain these same environments.

If we are honest with ourselves, most will admit that it's more fun to build than to maintain. Few engineers took up programming so that they could take care of something someone else built! However, it is this same resistance to maintenance that causes so many SOA environments to decay over time. Without pre-planning, practical standards and realistic governance, most SOA environments will fall into chaos over time.

In many cases, SOA implementations start with a single project declaring that they'll be using services of some kind. From there, other projects pick up the call and begin building their own services. But what about the message model? Are they using the same domain model to build messages? Are they using REST or SOAP? There are dozens of basic considerations that make an SOA viable. These aren't standards issues, though there is some overlap. Rather, this is about the foundational concepts on which an SOA is built. Each difference between implementations compounds over time, making the overall SOA less maintainable. Beyond these foundational concepts, there is the planning of the implementation. Determining which systems will expose which services is an often overlooked issue. Business critical services should be planned across the enterprise lest you end up with many conflicting implementations of the same service.

Importance of standardizing SOA implementation

Standards are the vitamins of our industry. We all know we should be defining and applying them, but few of us actually are. As with pre-planning, differences in standards between implementations result in the need for “small” integration efforts. These integration efforts compound over time, creating repeated labor over the lifetime of the system. And as more systems integrate with the SOA, these differences demand increasingly complex integration efforts. While there are many ways of handling these differences, they are avoidable. Just setting standards and enforcing them through practice and peer review can resolve such issues before they materialize. The challenge is to define the "right" standards. Rather than focus on every detail, one must focus on those issues that complicate integration between service implementations. For example:

• Versioning schemes

• Security implementation

• Protocol usage (PUT vs PATCH, etc)

• Error and exception handling

• Messaging formats (XML vs JSON, etc)

Simply setting standards won't resolve the issue though. There needs to be mechanisms in place that enforce the standards before they are violated. Peer reviews, audits and compliance tools (such as JetBrains' Resharper, lint and M Squared's RSM) can all help to identify potential issues before they hit production.

View on governance

Many organizations struggle with governance and with good reason. Too often, governance becomes a set of meetings that occur because a schedule says they should. So let's start with what governance for an SOA should look like. There are three primary things SOA governance should be concerned with:

• Managing the growth, usage and lifecycle of services

• Evolving the standards that define how services are used

• Monitoring the performance and health of the SOA

Incorporating changes

Too often we look at services and software in general, as immortal and unchanging. Services need to be tracked over time, modified and retired. While this activity can be driven by a project team for shared services there is a need to track and communicate these changes. In some cases, this means initiating entirely new projects to make changes across many services.

Just as with services, the standards that define those services need to evolve over time. As new techniques are developed, standards need to keep pace. But simply updating the standards, making a grand announcement and assuming all is well is a recipe for disaster. This is one area in particular where an SOA can devolve and become less maintainable - as some areas of the firm adopt new approaches and others do not. Changes need to be phased in over time and supported by leadership through funding and time. In some cases, this will mean new projects that focus on bringing a set of services into compliance (although such efforts can often be bundled with functional changes).

“SOA is one of the foundational developments in enterprise technology”

One aspect of governance that is overlooked is the tracking the health and performance of the SOA. As an industry, we track the performance and health of infrastructure and applications, but we treat services as "appendages" to applications. Like nearly all technology, services tend to become less efficient over time as accumulated changes are made. Failure to monitor service health can lead to a slow decline in the performance and health of the applications they support. Failure to address this as an issue with the service can ripple across all of the service’s consumers.

SOA remains one of the foundational developments in enterprise technology. Like so many innovations, in our collective rush to reap the advantages of SOA, we haven't spent as much time on running an SOA environment. Fortunately, with a little bit of pre-planning and some basic diligence we can continue the initial benefits of SOA deployments well into the future.