Service Oriented Architecture & SOA Governance
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
Service-Oriented Architecture (SOA) Definition
Service-oriented architecture (SOA) is an approach used to create an architecture based upon the use of services. Services (such as Restful Web services) carry out some small function, such as producing data, validating a customer, or providing simple analytical services.
In addition to building and exposing services, SOA has the ability to leverage these services over and over again within applications (known as composite applications). SOA binds these services to orchestration, or individually leverages these services. Thus, SOA is really about fixing existing architectures by addressing most of the major systems as services, and abstracting those services into a single domain where they are formed into solutions.
One of the keys to SOA architecture is that interactions occur with loosely coupled services that operate independently. SOA architecture allows for service reuse, making it unnecessary to start from scratch when upgrades and other modifications are needed. This is a benefit to businesses that seek ways to save time and money.
SOA is known to provide both time-to- market advantages, as well as business agility. The use of orchestration engines, or leveraging development environments that leverage services and SOA, allow those who build applications to do so quickly, since the services provide much of what the application requires. This provides the time-to- market advantage.
- Organizations that choose to adopt Service Oriented Architecture (SOA) quickly realize that Governance must be established quickly in order to manage a successful SOA program or initiative. SOA Governance, however, has been difficult to establish successfully in many organizations for a variety of reasons.
- To understand SOA Governance (and how Governance can be successfully initiated in your enterprise), there must be a clear understanding and definition of enterprise SOA Governance Principles and an operational, holistic SOA Governance Model. Clarifying Governance Principles (creating a common, shared definition of SOA Governance in an organization) and creating an organizational Governance Model will provide the necessary foundation towards more advanced Governance activities.
- This article will address the most basic challenges in establishing SOA Governance. First, it will attempt to explain to define SOA Governance by comparing and contrasting “strategic governance” and “tactical governance”. Next, a SOA Governance Framework will be presented that can be customized for an organization in any maturity stage. Finally, this article will provide actionable steps your organization can take to move forward in its SOA Governance efforts and initiatives.
- SOA Governance is more than a group of people who meet once a month (or less) to talk about SOA topics, create enterprise SOA Policy, and then retreat to SOA Ivory Towers. In fact, establishing SOA Governance can be a challenging, disruptive, and destructive force in an enterprise’s SOA efforts.
- For years, SOA evangelists have asserted that the most challenging obstacle in establishing SOA Programs and initiatives has been the cultural and political obstacles that must be overcome for success to be supported by a collective group. Consequently, it should come as no surprise that establishing SOA Governance – or organizing a group of SOA domain owners in an effort to establish enterprise SOA policy – would be a (if not the most) significant challenge that an organization will face, early, when establishing an enterprise SOA program. After all, Politics is inherent in Governance.
- Inevitably, political battles will, in most cases, determine who wins specific SOA domains – and specific SOA Governance responsibilities. However, many battles can be minimized and isolated (and organizational damage averted) if there is a clear boundary of domain areas and a clear definition of what is being fought for (in efforts to create SOA policy). The purpose of this article is to provide such foundations to the reader.