Effective SOA Governance Doesn't Always Require a Registry and Repository

Editor's note: Missed our SOA in Action Virtual Conference? Replay sessions on demand here.

There's no question that a registry and repository can play a critical role in the success of service-oriented architecture. After all, as part of a larger governance strategy, a registry and repository can be key to managing service artifacts and their lifecycles, eliminating redundancies and encouraging reuse -- the core benefits of SOA that have been touted over the years.

However, if a company with a small, centralized IT team has created a handful of services, is a full registry and repository necessary? Couldn't the information just as easily be tracked using existing tools?

Most companies already use a repository (such as a source control system) to store SDLC artifacts during design time. In many environments, metadata about these artifacts and their associated services and lifecycles is managed using existing collaborative workflow tools that are often tightly integrated with these SDLC repositories. Therefore, storage and management of both service data (repository) as well as metadata (registry) already exists in some form within many organizations. If runtime audit capabilities are additionally needed, this can also be achieved using simple log queries and archiving techniques.

Meanwhile, some architects question whether or not the learning curve associated with adopting a registry and repository is worth it in the long run. While each company building an SOA will have to decide whether or not the investment in a registry and repository will pay off, it is very important to understand that effective governance is absolutely possible without one.

Like any IT decision, it comes down to identifying the needs of the business and selecting the right tools that fit appropriately. For some companies, a registry and repository may be overload if they only need to manage a few services. For others, however, a registry and repository is the logical next step for managing and organizing a vast amount of services and their lifecycles, artifacts and various other technologies that may make their way into the SOA as it is exposed to different environments through customers, partners, or distributors.

Yet, what seems to be erroneously and inextricably linked is the notion that effective governance is not possible without a registry and repository. Of course, governance can and does complement a registry and repository. However, a governance strategy doesn't require a registry and repository to help architects enforce policies and obtain greater visibility to mitigate the risks associated with developing software that's designed to support the business goals of the SOA.

The role of the registry is to serve as the central location for identifying information about services that have been created and deployed. Ideally, the registry enables you to better understand those services and their associated governing policies. Working hand-in-hand with the repository where the service artifacts are stored, a registry facilitates the management of IT projects by enabling businesses to more easily discover and reuse relevant services.

Further defining and differentiating the registry and repository is how they are used with regard to design time and runtime. In simple terms, during design time, the focus tends to be on the description and identification of the relevant code and services as they are being checked in. Runtime is more concerned with service contracts, runtime policies, auditing and tracking services as they are used throughout the organization. Given that design time and runtime are terms that also refer to approaches to governance, you can further see how governance can complement a registry and repository -- yet continues to stand on its own.

Let's assume that a company today has a half a dozen services. However, longer-term plans call for the creation of many more services as the infrastructure evolves through a multi-year SOA journey. At what point is a registry and repository required? Where is the fork in the road when it comes to making the switch over to fully using a dedicated service registry and repository to track and monitor all of your web services, artifacts and applications?

If the goal is to put into place effective governance as your SOA evolves, you may or may not need a registry and repository. Effective governance tools exist for both the design time as well as runtime that do not require a registry or repository installation. However, you'll need a way to manage and track the services to avoid the creation of insecure services and redundant efforts. As cited above, existing online collaboration and workflow products along with the integration of policy management and governance tools will work in tandem with simple auditing and log querying capabilities for many organizations.

So when do you need a registry and repository? Based on customer experiences and feedback, a registry and repository is optimal in environments that need to:

Manage more than 50 services that are either created

  • in house or will traverse the architecture through external sources.
  • Dynamically discover services located throughout the organization.
  • Expose services to public registries for community reuse.
  • Adhere to extensive compliance regulations using advanced security, policy enforcement and auditing capabilities.
  • Perform extensive and continuous auditing and logging of these services, check against SLAs at runtime etc.

Regardless of whether a registry and repository is in place, one of the most effective ways to ensure the highest quality governance is when it is enforced early at design time. This way, you can ensure that policies and best practices are being followed as the software is being designed and developed until the point when it is deployed. This significantly reduces the cost of re-work due to non-compliance with policies. As the service artifacts move along throughout the software development life cycle (SDLC) they can be governed at each step to ensure full compliance with enterprise policies prior to distribution throughout the SOA.