As the field of service-oriented architecture (SOA) evolves, it brings interesting challenges that should be addressed in order to drive its adoption and realize the benefits it has been promising. It took a while for many to understand that SOA is not purely a technology issue.
SOA is an IT strategy and it requires a shift in the way we think about how IT is aligned with business and how an organization can support and drive SOA within the enterprise. The popular IS Strategy Triangle framework emphasizes the 
need for alignment between business, IT and organizational strategies.[1] Figure 1 shows the extension of the IS Strategy Triangle and how SOA fits in. Business strategy should drive the SOA strategy, which is an IS/IT Strategy and SOA strategy must support the business strategy.
In order for the SOA strategy to be effective, the organizational capabilities and processes should be aligned with the business and SOA strategies. A number of surveys have identified SOA organization and governance-related issues as a top inhibitor for SOA adoption.
Effective adoption of SOA requires changes to the traditional structure and processes of an organization. The implementation of SOA strategy might introduce new organizations, governance bodies, roles, responsibilities, and other governance issues. It may change the way business capabilities are built and rolled out to the business. These changes introduce challenges around the ownership of assets. The purpose of this article is to develop a framework for identifying ownership issues around SOA assets. Every organization’s culture and organizational capabilities are different. The framework discussed in this article is generic enough to be customized for any organization.
The effectiveness of the governance processes depend very much on the definition of roles, the clarity around the ownership of assets and processes, and the degree of empowerment of the governing bodies. SOA introduces several challenges around the ownership of SOA assets for a couple of reasons:
- Services are built to address enterprise concerns. Individual business units no longer own all parts of a service, as doing so would completely defeat the purpose and benefits of SOA. The decisions made around SOA should be based on the best interests of the whole enterprise, not the interests of one particular group within the enterprise.
- Services are made up of several parts that are generally distributed in nature. This distribution is multi-dimensional. For example, a service may span physical (deployed across several hardware layers) and organizational boundaries (different organizations may be involved in the development and deployment of the service).
When determining the ownership of SOA services, it’s important to clarify the purpose of identifying ownership, and to understand the underlying assets exposed and the boundaries around services.
Purpose of Identifying Ownership
The purpose of identifying ownership is multifold. Every organization has different reasons or objectives as to why it should identify the owners. These objectives drive how ownership is defined and shared across organizational entities.
In general, the common reasons for identifying ownership are listed below.
Single Point of Accountability (SPOA)
Ownership identifies a single point of accountability (SPOA). Property rights have been identified as the key to economic development and property rights lead to prosperity.[2] The property rights within an organization play a critical role in leading it to prosperity. O’Driscoll’s article refers to the following passage from the work of Mises.
Ownership of the means of production is not a privilege, but a social liability. Capitalists and landowners are compelled to employ their property for the best possible satisfaction of the consumers. If they are slow and inept in the performance of their duties, they are penalized by losses. If they do not learn the lesson and do not reform their conduct of affairs, they lose their wealth. No investment is safe forever.[3]
This observation applies perfectly to SOA as well. The owners of service assets must ensure that these assets serve in the best interests of the consumer and the enterprise. Owners are expected to be held accountable for the part they own. Without a sense of ownership, the organization can not achieve a state of prosperity. As organizations achieve higher levels of SOA maturity, they would most likely have a “business-like” model where providers of a service serve consumers and are measured on the value they create through the services. Owners must understand that they have a liability to the enterprise and must strive to serve and satisfy the consumer. Failing to do so would diminish the value they provide to the enterprise, raising questions about their existence.
Subject Matter Expertise
Ownership provides Subject Matter Expertise (SME) to define, design, develop, and maintain the services. Owners are typically experts in some or all parts of the assets. For example, some may be experts in the functional area for which the capability is built, while some may be experts in the technologies used to build the business or technical capabilities.
Asset Protection and Evolution
Services need to be protected and promoted for the benefit of the enterprise and the owner(s) plays a key role in that. The protection of assets really means evangelizing and promoting the reuse of it in order to realize business value. If the assets are not protected, duplicate capabilities will be built, eventually forcing them to retire. The owner(s) typically protects the services to ensure that they can cater to the consumer and evolves them to support the changing business needs.
Funding
Ownership in most cases clarifies the source or use of funding. Owners either fund or recover the cost of building a service, although there are occasions when other consumers may pitch in. In light of the enterprise value added by the service, a funding model should be developed to assist the owners with managing the cost of building and running the service.
Change Control
The owner(s) is responsible for controlling any changes to the service and generally has the authority and knowledge to validate changes to the service. They ensure that the changes cause improvement without affecting the semantics of the service.
GO (Governor-Owner) Service Ownership Framework
Services are complex entities that span across organizational and technical boundaries. The distinct technical and process components of the service should be identified and assigned ownership appropriately for the reasons stated earlier. A single owner model will not work for SOA services. One entity or group may not be able to own and govern the services due to the distributed nature of service components and life-cycle processes. It’s necessary to distinguish the role of owner(s) from that of governor, which is discussed later.
From the time IT demand is created for a business capability to the time a service is deployed to provide that business capability, the service goes through several stages. During this development process, different groups perform the tasks required to evolve the service to the next level. The service could have different owners at different points in this life cycle. The coexistence of different versions of the same service introduces additional complexities. A great deal of coordination is required to ensure a smooth hand-off between these organizational entities. Also, there are other stakeholders in the process that need to be involved at the right times. This warrants the need for a governing body that would independently orchestrate these efforts. We call this governing body the “governor” in this framework.
Figure 2 explains the service ownership using the GO service ownership framework. As IT demand is generated, concepts are prioritized and appropriated for implementation. As part of the concepts and requirements phase, services and business processes are identified and modeled. These activities are typically performed by the business unit. Then they go through the design, construction, and testing phases. A service provider typically performs these tasks to build the services. Then the service begins its operational life cycle, where it is deployed, managed, and monitored. The metrics gathered are fed back to the business to improve the services further or to generate new ideas. As new versions of the services evolve, the old services will be retired.
The various components of the service should be considered for the purpose of ownership. You need to ask a few questions with respect to these components. Should these components be owned by the same entity or does it make sense to have different units own different parts of the service? Who has the final say on the design decisions around these?
Service Contract
The contract includes the business requirements or semantics of the service and non-functional requirements.
Service Interface
Interfaces are the entry points to the services. The operational infrastructure exposes the interfaces for access by the consumers.
Service Implementation
Implementation of the service may include the following:
- Underlying assets
- Business (or utility) logic implementation
- Policies
- SOA infrastructure components like registry and ESB
- Physical infrastructure such as the hardware servers, network components, etc.
We need to make sure that each one of the components has rightful owner(s) identified. The GO Framework breaks service ownership down further into the following ownership types to address the ownership needs of these components:
- Semantic Ownership (Conceiver)
- Development Ownership (Builder)
- Operational Ownership (Maintainer)
Each of these ownership types are discussed in detail below.
Semantic Ownership (Conceiver)
The lifeblood of the service is its business (or technical) semantics. The semantics include the meaning of the underlying assets, information, business rules, or algorithms. Semantic ownership of the service typically lies with the owner of the underlying asset. The business (or the business representative) typically holds this ownership for business services. The business is in the best position to judge the impact of any semantic changes or enhancements. Since this owner conceives of the service, we will call it the Conceiver.
In the case of shared services that are used by multiple business units, identifying the rightful owner may not easy. In such cases, the governor would need to determine the right semantic owner under the direction of the SOA leadership team or steering committee.
In certain cases, related services can be grouped into portfolios of functional categories. These services would typically have an underlying semantic relationship and the same semantic owner.
In most cases, semantic owners are the initial consumers of the service as well as the ones in need of the service functionality.
Development Ownership (Builder)
Development ownership refers to the responsibility of designing, developing, and provisioning the services. The development owner is responsible for the technical aspects of the service that include the following:
- Service interface definitions
- Schema definitions
- Technical implementation
- Policies
- Service architecture
- Implementation of nonfunctional characteristics
The development owner can modify the nonfunctional characteristics of a service without changing the semantics of the underlying assets.
Service providers would usually fill this role. They work with the semantic owners to understand the service requirements and implement the service. In some cases, they may need to work with a different group to implement all or part of the business or access logic. Since this owner builds the service, we will call it the Builder.
Operational Ownership (Maintainer)
The operational owner is responsible for maintaining the service in the operational life cycle of the service. The operational owner owns the “runtime instances” of the services. Changes to the runtime instance and configuration would be controlled by this owner. The development owner typically hands over the service to the operational owner when the service is ready to be transitioned from the development life cycle to the operational life cycle. The operational metrics of the services are gathered and provided back to the business for continuously improving business capabilities. Since the operational owner is responsible for maintaining the services, we will call it the Maintainer.
Governor
Service ownership can not be discussed without talking about the role of the governor, which is typically an organizational role. A centralized organizational body should be assigned these responsibilities to protect the interests of the enterprise. The governor role has the following responsibilities.
- Governance: The governor should handle the governance and coordination among the various stakeholders and owners. As discussed earlier, a service changes hands many times throughout its life cycle. The development and release of the service should be synchronized with the development and release schedules of the consumer as well. On top of that, it should be ensured that the service follows enterprise standards and best practices. The governing body is responsible for these activities and it may leverage other groups within the organization to execute these.
- Promote Reuse: Sometimes, owners may not be interested in promoting service reuse as they may be measured on delivery but not on enterprise value or cost savings. It’s the responsibility of the governor to promote service reuse and mediate between parties to accelerate the adoption of the services.
- Brokering and Mediation: Owners own the service and have the final say on the part they own. The governor brokers the requests between consumers and other parties for access, changes, and enhancements. In a complex enterprise ecosystem, conflicts are inevitable. The priorities of stakeholders could be very different and the governor brokers the communication between the various parties.
- Funding Management: The governor is generally responsible for administering the funds for building and running the services. The funding model should support the allocation of funding for services and chargeback to recover costs. The governing body could run as a cost center or investment center. In a cost center model, it’s responsible only for the costs and recovers costs through chargeback to the consumers. In an investment center model, it earns revenue through capital budgeting and chargeback and reinvests into building additional enterprise services at its discretion.
- Cost Allocation: The governor ensures that the cost of development and the maintenance of services are allocated appropriately to the consumers of the service. To measure and motivate the performance of the firm, the costs should be measured and allocated equitably. Failure to do so would result in the misuse of valuable resources.
- Release Management: The governor also manages the development and release cycles of the various versions of the service with the help of the portfolio architect. As shared services are being developed and enhanced actively, it’s not uncommon for multiple versions to coexist. In such cases, different service versions may be owned by different owners at any point. Figure 3 explains this concept where v1.0 is in production and being monitored and managed by the operations, while v1.1 is being implemented by the development owners (service provider). At the same time, the semantic owner may be working on fleshing out the requirements to create a newer major version of the service (v2.0). The governor coordinates the release and retirement of these versions among the owners and consumers.
- Continued support of services: The governor measures and understands the value of the services and should ensure that the services are supported by the appropriate owners until they are retired from use.
Now that the framework has been explained, a useful exercise would be to identify the various owners for your services. A good starting point would be to identify the respective owners for each category of services. Table 1 lists the standard categories of services. Write down the owners for these service types in your organization. Also, it is a good time to start thinking about which group or groups will perform the governor duties in your organization. If you can’t determine which group will perform the governor role, then it could potentially be a current gap.
Summary
Effective SOA governance depends on the identification and assignment of ownership of various components of the service. During the life cycle of a service, it requires that the semantic, development, and operational owners go from concept to production. Coordination between various owners and other stakeholders would require the involvement of the governor. The GO (Governor-Owner) Framework captures these elements of service ownership.
References
- Pearlson, Keri E., Saunders, Carol S. Managing and Using Information Systems: A Strategic Approach. Third Edition. John Wiley & Sons. ISBN: 0-471-71538-7.
- O’Driscoll, Gerald P. & Hoskins, Lee. (2003). “Property Rights: The Key to Economic Development.” Policy Analysis. No. 482.
- von Mises, Ludwig. (1966). Human Action: A Treatise on Economics, 3rd rev. ed. Chicago: Henry Regnery Company. pp. 311–12.