ServiceTechMag.com > Archive > Issue XXXIV: November/December 2009 > Reporting on the SOA Manifesto: A Meeting of the Minds
Joe McKendrick

Joe McKendrick

Biography

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. His popular 'Service Oriented Architecture' blog is published regularly at the ZDNet site. Joe is also SOA community manager for ebizQ, and speaks frequently on Enterprise 2.0 and SOA topics at industry events and Webcasts. He also serves as lead analyst and author of Evans Data Corp's highly regarded bi-annual SOA/Web Services and Web 2.0 surveys. Joe writes a regular column for Database Trends & Applications, and has authored numerous research reports in partnership with Unisphere Research for user groups such as SHARE, Oracle Applications Users Group, and International DB2 Users Group. In a previous life, Joe served as director of the Administrative Management Society (AMS), an international professional association dedicated to advancing knowledge within the IT and business management fields.

Contributions

rss  subscribe to this author

Bookmarks



Reporting on the SOA Manifesto: A Meeting of the Minds

Published: December 3, 2009 • SOA Magazine Issue XXXIV
 

Introduction

For many standards groups, time is measured in years, punctuated by bi-annual meetings in which wording, specifications, and other details are hashed out in long, intensive meetings. For the SOA Manifesto Working Group meeting at the Second Annual SOA Symposium in Rotterdam, Netherlands, however, there was no such drawn-out timetable. The group committed itself to drafting a viable set of core values and guiding principles for announcement at the conclusion of the conference - giving authors three days to reach a consensus across varying opinions and perspectives.

The group accomplished just that - providing the first industry-wide document to establish values and guiding principles for service orientation and service oriented architecture. The 17 members of the Working Group comprised a broad spectrum of SOA proponents - including enterprise architects, authors, analysts, consultants, and vendor representatives. Member participation was an individual initiative, and not based on formal sponsorship or input from members' employers. The Manifesto's final draft [REF-1] was announced in a closing ceremony at the end of the SOA Symposium on October 23rd, followed a month later by the separately published annotated version [REF-2].

The SOA Manifesto is based on the same format as the Agile Manifesto, created in 2001 to enunciate the values and principles of Agile software development. Likewise, members of the Working Group saw a need for a similar document to help clarify the vision of service oriented architecture, and address any confusion that has existed around its meaning and purpose.

For starters, the group tackled semantics, drawing the distinction between the terms "service orientation" and "service oriented architecture." This point was elevated to the SOA Manifesto's preamble, which defines the overall mission of service orientation and service oriented architecture:

"Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation."

The purpose of this statement is to emphasize the point that SOA, being an architecture, cannot be "done," any more than one can "do" Roman or Greek Architecture. The activity that one undertakes to build service-oriented technology architecture is "service orientation." This is intended as a clear statement that SOA is not a product that can be packaged and sold, such as is the case with ERP or financial software.

The remainder of the preamble is a mission statement that describes what service orientation and SOA contributes to organizations, underscoring the commitment of Working Group members, as well as the follow-on signatories to the Manifesto, to the core values and principles that follow:

"We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs."

The Working Group crafted a total of six core values that define the purpose and intent of SOA and service orientation. In this format - also modeled from the Agile Manifesto - more-favored values within an SOA context were identified and contrasted against less-favored values. That is to say, while the latter item in each statement is still considered important, the former item is considered more relevant in service orientation efforts:


Business Value over Technical Strategy

There was widespread agreement among Working Group members that business value should be the most important strategic priority of SOA, and that it should not confined to information technology operations. It is not about technology determining the direction of the business, it is about the business vision dictating the utilization of technology. This may seem like common sense, but all too often technically focused projects take on lives of their own, resulting in expensive and complex solutions that ultimately add little or nothing to the growth of the business.


Strategic Goals over Project-Specific Benefits

Along with business value, the group recognized that SOA should be focused on long-term benefits, resulting in a journey that addresses problems and opportunities across the entire enterprise. Many IT efforts begin at the project or tactical level to address a single problem, but remain confined within the silo of a department or business unit. Such efforts are duplicated across the enterprise, resulting in an IT enterprise landscape that is convoluted and burdensome, expensive, and slow to evolve. Service orientation emerged in response to these problems, encouraging the development and deployment of repeatable or sharable solutions that address common problems across the enterprise.


Intrinsic Interoperability over Custom Integration

The SOA Manifesto Working Group wanted to illustrate that service orientation helps applications and systems to natively interact with one another from the point in which they are designed. The challenge for many organizations has been that integration has been an art and science practiced after systems have been put in place, resulting in the need for expensive and often fragile connectivity solutions and dependency on further consulting services. SOA-aware applications and services should be designed for compatible interoperability from the start.


Shared Services over Specific-Purpose Implementations

An important aspect of service orientation and SOA is the provisioning of common services that can be shared or reused across enterprise walls. A shared service establishes itself as an IT asset that can provide repeated business value while decreasing the expense and effort to deliver new automation solutions. While acknowledging that not all services can or should be reusable, an SOA-aware organization should endeavor to meet this goal. The group acknowledged that there are and will be many specific-purpose applications that will only be deployed in one instance - such as those that run on scientific or engineering workstations. However, wherever possible, applications and services should be built with eventual sharing in mind - as opposed to building the same solution logic over and over again.


Flexibility over Optimization

Optimization in many cases is a worthy core value, as systems may need to be tuned or adapted to increase performance or to overcome bandwidth limitations. However, building applications, services, or systems to address immediate, one-time needs leads to rigidity and less capability to meet changing business requirements. When an existing business process changes or when a new business process is introduced, businesses need to be able to add, remove, and extend services within the composition architecture with minimal effort.


Evolutionary Refinement over Pursuit of Initial Perfection

Services should be built to change, as opposed to being built to last in a static state. No one can predict how a business will need to evolve over time, and therefore it's not likely a "perfect" service will stay perfect for long. While getting something "right the first time" is an important value to strive for, SOA proponents should not be overly consumed with trying to achieve a service or set of services that gets everything absolutely correct on first release. Rather, the goal is to create and offer services that can rapidly meet business objectives as they change. Business users may need a service within a matter of days, or even hours, and a fundamental ambition of SOA and service orientation is to enable such agility.


Guiding Principles

Members of the SOA Manifesto Working Group agreed upon a set of 14 guiding principles that are provided as guidance for adhering to the values and realizing the vision. The principles are as follows:

  • Respect the social and power structure of the organization: No SOA effort can get underway or flourish if it does not have the support of key decision-makers within the organization. As Thomas Erl stated in his annotated manifesto, "The adoption of service orientation is very much a human experience. It requires support from those in authority and then asks that an IT culture adopt a strategic, community-centric mindset." [REF-2] However, one of the most common SOA pitfalls is approaching adoption as a technology-centric initiative. The IT department may be enthused about SOA, but business decision-makers may fail to see the value to the organization's vision and goals. Organizational support and buy-in is one of the essential hallmarks of SOA success.
  • Recognize that SOA ultimately demands change on many levels: While it may start out fairly innocuously as an endeavor within the IT department, SOA is an architecture that, if built successfully, will ultimately transform many aspects of the business, and this needs to be recognized. Not only do technology systems need to be reconfigured if SOA is to streamline and improve their interoperability, but the business may need to change other systems as well - such as compensation, governance boards, and supplier relationships.
  • The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries: While the previous principle addresses transformation that may eventually sweep through many parts of the organization, it's not based on attempting to "boil the ocean," or in a "big bang" approach, especially in the initial stages. Successful SOA adoption doesn't require an enterprise approach - it is achievable through incremental steps or milestones. An SOA adoption effort needs to be determined as a result of planning and analysis in conjunction with pragmatic considerations, such as impacts on organizational structures, areas of authority, and cultural changes. These types of factors help determine a scope of adoption that is manageable.
  • Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you: You can't buy SOA, and you can't expect SOA to spring from a set of standards. Service orientation and SOA will be part of a methodology and approach that may invoke these products or standards, but they are not exclusive to SOA.
  • SOA can be realized through a variety of technologies and standards: "Service orientation is a technology-neutral and vendor-neutral paradigm. Service-oriented architecture is a technology-neutral and vendor neutral architectural model." [REF-2] The success of SOA is not dependent on any particular product or standard. There are organizations that are employing service-oriented methodologies using CORBA-based objects, while many use either Web services or REST. SOA can be realized using any suitable set of standards, and any suitable technology platform.
  • Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards: As noted in the preceding principle, SOA does not depend on a specific set of standards because "...the use of industry standards alone does not guarantee that services will be intrinsically interoperable." [REF-2] Such standards may be industry-wide standards - such as WS-* or REST - or they may consist of standards developed and used within the enterprise itself. The key is consistency - for SOA success, it's important that when standards are used, that they are adhered to.
  • Pursue uniformity on the outside while allowing diversity on the inside: SOA introduces a federated endpoint layer that abstracts service implementation details while publishing a set of endpoints that represent individual services within a given domain in a unified manner. SOA enables organizations to deploy services regardless of the varieties and types of systems they may have across their enterprises. However, even if your internal infrastructure is chaotic, this should appear as one single infrastructure or interface to end-users. This principle does not advocate diversification itself - it simply recommends that we allow diversification when justified, so that "best-of-breed" technologies and platforms can be leveraged to maximize business requirements fulfillment.
  • Identify services through collaboration with business and technology stakeholders: The most important element of SOA is that it encourages end-users to be more engaged in the design, building and deployment of services. The resulting services should be meaningful to both business and technology professionals and managers.
  • Maximize service usage by considering the current and future scope of utilization: As enunciated in the core value of "shared services over single-purpose implementations," designers and developers should, as much as possible, build SOA-aware services with sharing and reuse in mind. Modeling multiple services in relation to each other helps establish a blueprint of the services that will eventually be built. Not only should services meet current requirements, but should also be functional and flexible to adapt to changes that will arise as the business changes.
  • Verify that services satisfy business requirements and goals: The underlying meaning here is measurement - the organization needs to have a way to measure the impact SOA-aware applications and services have on the business. This may be in the form of key performance indicators, which tie specific initiatives to specific measures, such as customer retention rates or inventory levels. Modern tools provide various means of monitoring service usage, but there are intangibles that also need to be taken into consideration to ensure that services are not just used because they are available, but to verify that they are truly fulfilling business needs and meeting expectations.
  • Evolve services and their organization in response to real use: Service design and creation should not occur in a vacuum. Simulations and testing cannot provide service designers and developers a true picture of how that service fits into the business, in terms of granularity, scalability, and functionality. Once services are in production, it's important that service providers seek ongoing feedback from users as to how the services can be improved - as per the core value of "evolutionary refinement over pursuit of initial perfection." As real world business requirements and circumstances change, the service may need to be augmented, extended, refactored, or perhaps even replaced. Service orientation design principles build native flexibility into service architectures so that, as software programs, services are resilient and adaptive to change and to being changed in response to real world usage.
  • Separate the different aspects of a system that change at different rates: This introduces the element of separation of concerns, based on the rationale that a larger problem can be more effectively solved when decomposed into a set of smaller problems or concerns. In service orientation, corresponding units of solution logic are built to solve individual concerns. This approach introduces numerous layers of abstraction that help shield service-comprised systems from the impacts of change.
  • Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change: This principle introduces the notion of transparency of services provided, as a way to establish trust between providers and consumers of services. The potential issues posed by dependencies - such as hidden direct database access - have long been a limitation that has held back the integration applications and systems. Published technical service contracts need to disclose the dependencies that service consumers must form in order to interact with services. By reducing internal dependencies that can affect these technical contracts when change does occur, we avoid proliferating the impact of those changes upon dependent services consumes.
  • At every level of abstraction, organize each service around a cohesive and manageable unit of functionality: Each service requires a well-defined functional context that determines what logic does and does not belong. Determining the scope and granularity of these functional service boundaries is critical. Too coarse, and the service may be too inflexible to be effective, especially if they are expected to be reusable. On the other hand, overly fine grained services may tax an infrastructure in that service compositions will need to consist of increased quantities of composition members.

Conclusion

The SOA Manifesto is intended to offer high-level guidance for service orientation and SOA efforts within enterprises in the years to come. The core values and guiding principles are intended to help practitioners solidify the value of SOA to the business.


References

[REF-1] The SOA Manifesto, www.soa-manifesto.org (by The SOA Manifesto Working Group)

[REF-2] The Annotated SOA Manifesto, www.soa-manifesto.com/annotated.htm (by Thomas Erl)