On Saturday, October 20, 2007 at SAP Labs, Palo Alto, CA, the Association for Computing Machinery, San Francisco Bay Area Chapter sponsored a professional development seminar on Service-Orientation & Service-Oriented Computing. This blog provides a summary of this event.
As a member of Solutions Management of SAP's Community Network, among other things I am required to drive projects which maintain the current community platform and to drive the identification and adoption of new technologies within the community; however, in focusing on such projects, over time we become blind to what is happening around us. I can tell you first hand that I often speak about SOA and ESOA, and I have a reasonably good high-level understanding of the terms and concepts behind these technologies, but I am by no means a topic expert. I believe that in order to be an effective driver of innovative technologies and projects, we must have a deeper understanding of those technologies and how they impact the organization.
To overcome my lack of understanding of SOA terms and technologies I decided to attend this seminar, and I have provided a very high level overview of this seminar to the benefit of those who are in the same boat as I with respect to SOA understanding. I have also provided feedback from a brief interview I had with the speaker, Robert Schneider. It is not my intent to provide an authoritative manual of terms and technologies; there is a plethora of books and other information repositories which can dive deep on each one of these topics. One particular book worth mentioning is SOA Principles of Service Design by Thomas Erl, Prentice Hall.
The purpose of this seminar is to provide a technical overview of the Service Oriented Architecture landscape and design principles and to provide some introductory information regarding the SOA Training and Certification Program, a series of workshops and modules for preparation for SOA Certification. This seminar is presented in four sections: Strategic Goals and Benefits; Fundamental Terminology and Concepts; Service Delivery Lifecycle; and Adoption Impacts and Requirements. The following sections are from notes I gathered throughout the seminar.
Strategic Goals and Benefits
The primary reasons for implementing SOA technology are to increase intrinsic interoperability, increase federation, increase business and technology domain alignment, increase vendor diversification options, increase ROI, increase organizational agility, and reduce IT burden. The strategic nature of service-oriented computing is one of its distinguishing characteristics, and it contrasts the more tactical nature of traditional silo-based application development.
Fundamental Terminology and Concepts
What is SOA? In very general terms, Service-Oriented Architecture (SOA) is an architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers. And there are several other definitions as well; there is not one agreed-upon definition.
Traditional technology architectures are often delivered in alignment with the current state of a business, but are incapable of keeping up with how the business evolves. As business and technology architectures become increasingly out of sync, business requirement fulfillment decreases. Often this occurs to the point that a whole new technology architecture is required.
Over time, the scope and context of a technology architecture is outgrown by the business as it evolves in new directions. This results in the need to eventually replace the architecture. By applying a business-centric strategic scope to the technology architecture, it can be kept in constant synch with how the business evolves over time.
Other key terms include service orientation, service, service composition, service-oriented solution logic, service inventory, and service oriented computing platform. Full definitions of the these terms can be found at SOAGlossary.
Service Delivery Lifecycle
Prior to commencing with a SOA initiative, a project delivery approach needs to be chosen to best organize the overall delivery lifecycle. Three common lifecycle approaches are top-down, bottom-up, and agile. The primary service delivery lifecycle stages are service-oriented analysis, service modeling, service-oriented design, service development, and service implementation. After the service has been implemented, ongoing service governance takes over.
Adoption Impacts and Requirements
The primary impacts and requirements are standardization, organizational, governance, infrastructure, maturity, and migration considerations. Industry standards are generally represented by technology specifications that are produced by standards organizations and developed by committee. Design standards are produced by an IT department and define custom design conventions specific to an enterprise. SOA initiatives can introduce many new considerations that can impact the organization in a variety of ways, such as new roles and processes. SOA governance requirements can impose organizational and technology challenges. Performance challenges are a primary design concern when building complex service-oriented solutions.
Q&A with Robert Schneider
Q: What is the biggest obstacle in implementing SOA technology in an organization?
A: Biting off more than you can chew. Implementing SOA technologies within an organization should not be underestimated. While the advantages look attractive on paper, the actual implementation can be unwieldy and is usually difficult to pass in committee. Starting small and progressing through each of the applications is usually the best approach. An SOA initiative does not need to be enterprise-wide to provide benefit.
Q: What is the timeline for SOA maturity?
A: It is imminent, somewhere between 1 and 2 years. SOA and Web Service-based standards are very mature and should be finalized over the next year or so. You can also see a complete view of SOA standards at Big SOA Grid.
Q: What is the ROI timeline?
A: This can vary between companies and highly depends on the number of applications affected, but in general companies can see results in as little as 6 months up to 12 to 18 months or longer. It is important to note that most of the investment in a SOA implementation is up-front.
Q: What new roles are evolving to support SOA?
A: A new roll is that of the "Service Asset Manager," a sort of uber-librarian with deep knowledge of both the organization and service oriented technologies. This role typically acts as a front-end to the service governance team. Many other changes to existing roles will be seen as well, such as the Business Analyst and Architect. Traditionally, the business analyst hands over business documentation to the architect, and then the architect interprets the business models and requirements, and designs a business automation system. With SOA design and development methodologies, this interaction changes. The business analyst and architect define conceptual design together to ensure accurate representation of business logic, and then the architect finalizes the physical design. In this second case the business and technology communities are required to collaborate in a hands-on capacity.
About SOA Systems
SOA Systems is a recognized professional services provider specializing in strategic SOA-related planning and consulting services.
About Robert Schneider
Robert Schneider is a senior consultant, instructor, and published IT author with more than 15 years of experience leading successful client services organizations and providing technical expertise on complex IT applications.
