SOA Explained
Judith Hurwitz, Robin Bloor, Carol Baroudi and Marcia Kaufman explain Service Oriented Architecture in this book for "Dummies."
You know a topic has come of age when a "For Dummies" book is written about it. In this case, it's Service-Oriented Architecture (SOA), which is defined by the authors as "a software architecture for building applications that implement
business processes or services by using a set of loosely coupled black-box components orchestrated to deliver a well-defined level of service."
SOA proponents say it promises a boon for business, allowing cost savings and more nimble development through the reuse of assets and increased interoperability. But skeptics have had many questions of their own, such as whether the standards-based parsing layers used to enable SOAs just slow down performance.
The book's four co-authors are in the first camp, contending SOA isn't a buzzword or a pipe dream, but instead a rapidly maturing paradigm that will change the way business is done and software is developed. "Service Oriented Architecture for Dummies" reads as much like an advocacy position paper as it does a field guide.
"SOA demands a new kind of conversation between business and development. We're going to see more and more business tied to the integrity of development,"
co-author Carol Baroudi says in an interview. "On the business side, we're always thinking about issues of security, compliance and government regulation. Fundamentally, there's no security if there isn't integrity in the development process."
Who Should Read It
The book seems largely aimed at IT administrators and business leaders who are baffled by SOA but want to understand it quickly. For developers, the book may hold value through its depiction of their lives in a SOA-driven world.
Highlights
SOA as force of cultural change
The developer's life under SOA
SOA governance
Business process management
Major vendors' SOA strategies
Writing and consuming Web services
Wiley Publishing Inc.
ISBN: 0-470-05435-2
359 pages
|
On that note, Baroudi suggests many developers know less about SOA than they should: "Many of them are SOA-oblivious."
If you're developing a SOA in your company, or working under a completed initiative, the book may not contain much new information.
But SOA "dummies" will
be served rather well. The text's first five chapters are particularly rich with key and retainable details. The authors provide an overview of SOA's reorder-and-reuse underpinnings in fairly plain language, without failing to introduce and rigorously define key terms and concepts. Throughout, sidebars dive deeper into associated topics, an approach that keeps the main narrative flowing.
Other chapters detail real-life SOA implementations and break down major vendors' SOA strategies, providing an overview of key products and platforms.
The middle of the book deals with technical matters, discussing the various messaging and governance components involved in constructing a SOA: Enterprise service buses, registries and repositories, to name a few.
The chapter on governance is particularly strong. It drills down into governance, stressing the point that organizations that fail to develop a clear system of oversight, maintenance and accountability for their SOA risk widespread pain and confusion, instead of rewards.
The book doesn't center on software development until Chapter 14, and keeps the discussion fairly high-level, exploring how SOA applications will be shaped by business process management (BPM) tools. BPM is geared as a functional bridge between coders and the business side, the authors say.
"BPM development is naturally a kind of iterative application development, driven by a business analyst who has a good understanding of the business and who collaborates both with users and, if needed, with software developers," they write. "... It isn't just the application that's being prototyped; it's the working of the whole business process, including all manual activity."
Culture of Reuse
Moving to a SOA will require cultural change, but also provide major benefits for developers, the authors contend. There's the oft-cited observation that reusing proven code-such as a claims-process used throughout an insurance company-can free up valuable time. "You don't have to worry, 'is the code clean,'" co-author Judith Hurwitz says in an interview. "It's been tested, it's been verified, and you know that it's a good piece of code and works as advertised."
A second big reason to embrace SOA involves politics and positioning, Hurwitz argues: "This is an opportunity for developers to be more respected. You get another seat at the table."
"The business can go nuts and say we need 500,000 services. The smart developer is going to say no, we need 14," she continues. "Now we're both talking about creating services that serve the business. ... Now everybody's speaking the same language."
Hurwitz's latter point hews to the ultimate take-home message of "Service Oriented Architecture for Dummies": SOA is here, and stands to create radical change both in the halls of business and the development/IT shops. It's not necessarily a new argument, but one the book presents with clarity.