Zapthink and representatives from some major organizations like Amazon have liked what they have read. The book is organized into the following chapters:
- Chapter 1: SOA Basics
- Chapter 2: Business
- Chapter 3: Organization
- Chapter 4: Governance
- Chapter 5: Methods
- Chapter 6: Applications
- Chapter 7: Architecture
- Chapter 8: Information
- Chapter 9: Infrastructure
- Chapter 10: Future
In keeping with the theme of this blog which is client insights, a review of a key question from each chapter fits as I continue to address these questions with practitioners across the world. Chapter 1 SOA Basics has several questions and one question is "What is SOA?"
Although the following is not the complete answer provided in the book it provides a sufficient point of view of how I define SOA. I highlighted the first part of the answer because it summarizes sets the stage for our point of view, on what is SOA.
An agreed-upon definition for SOA eludes the industry. Anyone reading Wikipedia’s definition page for SOA will see the challenges of trying to gain consensus on an SOA definition. Standards bodies, the OASIS group, and the Open Group have provided complementary but different SOA definitions. Presented with a blank sheet of paper, an artist sees a canvas. A poet might fill it with verse. An engineer seizes the opportunity to make a paper plane. Kids may see it as a future pile of spit wads. SOA is that blank sheet of paper.
To the chief information officer (CIO), SOA is a journey that promises to reduce the lifetime cost of the application portfolio, max- imize return on investment (ROI) in both application and technology resources, and reduce lead times in delivering solutions to the business.
To the business executive, SOA is a set of services that can be exposed to their customers, partners, and other parts of the organiza- tion. Business capabilities, function, and business logic can be com- bined and recombined to serve the needs of the business now and tomorrow. Applications serve the business because they are com- posed of services that can be quickly modified or redeployed in new business contexts, allowing the business to quickly respond to chang- ing customer needs, business opportunities, and market conditions.
To the business analyst, SOA is a way of unlocking value, because business processes are no longer locked in application silos. Applica- tions no longer operate as inhibitors to changing business needs.
To the chief architect or enterprise architect, SOA is a means to create dynamic, highly configurable and collaborative applications built for change. SOA reduces IT complexity and rigidity. SOA becomes the solution to stop the gradual entropy that makes applica- tions brittle and difficult to change. SOA reduces lead times and costs because reduced complexity makes modifying and testing applica- tions easier when they are structured using services.
To the IT architect, SOA is the architectural solution for integrat- ing diverse systems by providing an architectural style that promotes loose coupling and reuse. Many IT architects think they have seen this style before with earlier architectural initiatives such as DCE, the Distributed Computing Environment, and CORBA, the Common Object Request Broker Architecture.
To the developer, SOA is a programming model or paradigm where web services and contracts becomes a dominant design for interoperability. It is a web service when it uses a Web Service Description Language (WSDL) or equivalent specification for describing the service. Web services enable organizations to communicate information, using messages, without intimate knowledge of each other’s IT systems.