Service Orient or Be Doomed!: How Service Orientation Will Change Your Business (Hardcover)

by Jason Bloomberg (Author), Ronald Schmelzer (Author) "Business books today are a sorry lot indeed..." (more)
Key Phrases: Web Services, Moore's Law, Service-Oriented Enterprise (more...)

Editorial Reviews

Product Description
How Service Orientation Will Change Your Business

"The real value of this book is that it makes SOA and Web services, which are critical and business-transforming, crystal-clear to the layman, both business and IT leaders. The book stays focused on the real-world issues facing business and government institutions today. In an industry full of experts of many stripes, Ron and Jason are the real thing: savvy, experienced, and realistic. They have produced a must-read book for management."
—Paul Lipton, Senior Architect, Unicenter Web Services and Application Management Computer Associates

"This is by far the finest publication on SOA of our time. From cover to back, Service Orient or Be Doomed! strips away the layers of confusion most IT stakeholders face when confronted with enterprise architecture, and illustrates pragmatic and practical paths towards a sustainable and efficient enterprise architecture. Both the technically savvy and the bean counters will enjoy this book that speaks to the critical points they need to understand."
—Duane A. Nickull Senior Standards Strategist, Adobe Systems, Inc. Chair, OASIS SOA Reference Model Technical Committee Vice chair, United Nations CEFACT (UN/CEFACT)

"If you're looking for a guide that's based on reality, this is it. These guys know how you can service-orient your enterprise and have the best chance of success. This book is the best SOA tool you can buy. I'm recommending it to everyone."
—Dave Linthicum, CEO, BRIDGEWERX

"Jason and Ron are experts on Service-Oriented Architecture (SOA) and have written the first book that is aimed at helping a nontechnical businessperson understand why the SOA computing revolution is critical to business. Rather than provide a nerdy death via buzzword book, Jason and Ron take a humorous, clever, and insightful romp through this new technology and how it impacts business in general."
—Brad Feld, Mobius Venture Capital

Authors Jason Bloomberg and Ronald Schmelzer-senior analysts for highly respected IT advisory and analysis firm ZapThink-say it all in the title of their new book, Service Orient or Be Doomed!: How Service Orientation Will Change Your Business. That is, if you fail to service orient your company, you will fail in competing with the organizations that do.

This provocative new book takes service orientation out of its more familiar technological surroundings within service-oriented architecture and introduces it as a philosophy that advocates its rightful place within a business context, redefining it as a new way of thinking about organizing your business and its processes.

Informal, challenging, and intelligent in style, Service Orient or Be Doomed!: How Service Orientation Will Change Your Business shows you how you can best use technology resources to meet your company's business goals and empower your company to go from "stuck" to "competitive."

From the Inside Flap

Introducing service orientation as a vision and philosophy that can impact a business, this innovative new book equips the reader to:

• Best use technology resources to meet goals
• Unleash their "inner nerd" to embrace IT as part of their business as a whole
• Address the "mother of all business problems": inflexibility
• Know the technological factors that pressure a business to innovate
• Understand buzzwords with Jargon Watch sidebars

Conversational in style and alternately irreverent, humorous, and intelligent in tone, authors Jason Bloomberg and Ronald Schmelzer—senior analysts for highly respected IT advisory and analysis firm ZapThink—offer a magna carta to CEO and small business owner alike that erases the line between business and technology toward a new service-oriented approach.

See all Editorial Reviews

Product Details

• Hardcover: 272 pages
• Publisher: Wiley (March 10, 2006)
• Language: English
• ISBN-10: 0471768588
• ISBN-13: 978-0471768586
• Product Dimensions: 9.1 x 6.1 x 0.7 inches
• Shipping Weight: 1 pounds (View shipping rates and policies)
• Average Customer Review: 4.7 out of 5 stars See all reviews (16 customer reviews)
• Amazon.com Sales Rank: #474,554 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

9 of 10 people found the following review helpful:

5.0 out of 5 stars A must read for executives, managers, architects & analysts, March 5, 2007

By	Damon Farnham - See all my reviews (REAL NAME)

Overview

Having read a number of other SOA books, I've developed a pretty sound foundation of what SOA is in terms of the technologies that form its basis, and the relative importance of introducing a service abstraction layer between the business and IS domains.

However, this book (Service Orient or Be Doomed!) caught my attention for two fundamental reasons:

1. It has a strong Amazon rating, and
2. It provides a business (vice technical) perspective on the importance of SOA

I started reading the book late last week and quickly found it to be very well written and absolutely compelling with respect to the message that it conveys. The book's message looks something like this:

* Companies need to be more agile than ever in order to compete in today's economy
* Existing technical solutions are inflexible and prevent business agility
* Service-Oriented Architecture can result in increased business agility, more flexible technical solutions and significant ROI over time
* To make SOA viable, the business itself must become Service-Oriented, which means the technical concepts of abstraction, encapsulation and design-by-contract are now important business constructs that result in a more loosely coupled relationship between business activities (e.g. processes) and automation technologies
* SOA requires the "business" and "technology" domains to converge around a new business organizational construct referred to as service domains
* IS must rethink its organization and technology strategies to better align with the Service-Oriented business
* Resistance to Service-Orientation and SOA is expected because of the level of requisite change
* To overcome the expected resistance and create business agility, SOA must be championed by a senior person or group
* SOA must be planned for, and must begin with small, targeted pilot implementations
* SOA (a discipline) is not equal to Web Services (a technology)

As one editorial review put it:

"Jason and Ron are experts on Service-Oriented Architecture (SOA) and have written the first book that is aimed at helping a nontechnical businessperson understand why the SOA computing revolution is critical to business. Rather than provide a nerdy death via buzzword book, Jason and Ron take a humorous, clever, and insightful romp through this new technology and how it impacts business in general."

I couldn't agree more. The authors obviously understand the technical side of SOA, but they've gone the extra mile and actually provided a more business-side treatment of Service-Orientation that makes a very strong case for the need for most businesses to implement changes - and in many cases large, difficult changes - or ... in their words ... be doomed to inflexibility and failure.

The first five or six chapters of the book focus almost entirely on building a case for the need for Service-Orientation by providing historical perspectives on such things as the dot-com bubble and even back as far as the Industrial Revolution. For non-technical readers (e.g. business folks), the first few chapters may be a little ho-hum, but for the technical reader, the content of these chapters lays a strong foundation upon which the remainder of the book is based. In particular, the authors demonstrate how existing technologies, including middleware, EAI and even standalone Web Services, handcuff the business by creating less-than-flexible solutions that are very resistant to changes ... changes that the business MUST make in order to remain efficient and competitive.

More than any other SOA book that I have read (and I've read most of them), this book effectively makes that case that new shared mental models need to be developed and advocated wherein business- and technical-concerns are integrated into a holistic view of the business that is centered on the notion of a business Service that depends on an array of equally important business resources, e.g. people, material, technology, time, money, etc. In effect, the existing walls between the business and IS domains need to be removed, and in their place a service layer abstraction created that allows the business to compose solutions from Services that conform to meta-data driven "contracts."
The net effect of this approach is a more loosely coupled continuum between business operations and the resources (including technology) that facilitate those operations.

However, this new Service-Orientation and overarching SOA landscape introduces new complexities and abstractions as payment for the increased levels of flexibility and business agility. To manage this new complexity, the business needs enterprise architects and enterprise architecture that drive the Service-Orientation perspective into the enterprise's SOA architecture, and manage the organizations "meta-requirement" for overall business agility.

The authors suggest, and I agree, that a new breed of "Service-Oriented Architect" is desperately needed by the business in order to champion the SOA principles and architectural mandates represented by the Service-Oriented approach.

As an example of the sort of quantum changes that need to be made by a company in order to embrace and adopt Service-Orientation and SOA, the authors note that Services are never really "complete", nor are their requirements ever stable. Instead, the business requirements that a Service may address are subject to frequent change as the business continues to adjust its goals and objectives to meet a continuously fluctuating business environment. Therefore, customary software development lifecycles (SDLC) (e.g., waterfall, spiral, iterative, etc.) are not applicable to Service development because SDLCs assume that a project is completed and a deliverable is promoted into a lifecycle that results in the deployed artifact eventually being retired. However, in the Service-Oriented paradigm, a Service is never completed in the sense that development work is done. Instead, the Service is constantly subjected to new requirements and ongoing refactoring activities in order to keep the service relevant and useful to the business.

Perhaps most importantly, the book puts the concept of a Service squarely in a business context and shows how loosely coupled Services can be composed into business solutions without any direct knowledge of (aka coupling to) underlying technical resources that ultimately implement the service. The authors go to great lengths to demonstrate how important the resulting "loosely coupled" relationship between business logic and program logic is to the business' overall agility.

Lastly, I thought that the authors did a fantastic job of demonstrating how current technologies and solution techniques are too narrowly scoped and result in overly tight coupling between business and technical resources, inconsistent with the requirements of Service-Orientation and SOA. Thus, they make a strong and logically based argument that major changes are needed in order to successfully bridge the business and technology concerns into a cohesive enterprise model that exhibits the necessary quality attributes needed to make the business more agile.

Without reservation, I would highly recommend this book to any company stakeholder and all managers, technicians, architects, analysts and executives interested in and/or concerned about business agility, Service-Orientation, SOA, risk management, process control or corporate compliance (just to name a few).

Strengths

Overall, I thought the book's greatest strength was its underlying "business side" emphasis relative to the whole Service-Orientation issue. The authors set out to convince businesspeople of the need to adopt Service-Orientation and SOA, and I believe they did a great job of doing just that.

While some of the historical background material may be old hat for some readers, I thought the authors did a good job of comparative analysis and in doing so provided a larger referential foundation that was effectively reused throughout the book.

Also, I found the authors' treatment of the concept of loose coupling to be one of the best non-technical examples that I've seen in quite some time. I expect that all readers, especially business managers and executives, will grasp the otherwise heavy-weight concept of coupling in such a way that the virtues of SOA will become more apparent from a business operations perspective, rather than a purely technical (e.g. encapsulation and data hiding) one.

I thought the authors did a great job of describing the role of an architect, and in particular the unique idiosyncrasies of the Service-Oriented Architect role. Additionally, they made a very strong case for the need for an Enterprise Architecture group and went so far as to suggest that EA may need to "own" the company's SOA effort and be properly budgeted to do so.

Finally, I think one of the book's most compelling arguments is that major changes are needed vis-à-vis the status quo in order to realize the business benefits manifest in the Service-Oriented paradigm. Implementing Web Services is not enough (it's actually an anti-pattern (read: bad)). Rather, the business needs to incorporate IT into the business planning process, and IT needs to prepare for that role by rethinking its integration strategies (in particular) and probably implementing a non-trivial reorganization in order to eliminate silos and embrace service domains.

Weaknesses

Overall, I didn't find many weaknesses with the book.

However, if I had to finger one aspect of the book with a critical eye (which doesn't necessarily imply that it is a "weakness"), I would perhaps suggest that the books content is very poignant in its assessment of the current state of IT practices, and clearly suggests that more than one legacy IT role may be on the chopping block when a well-formed SOA practice is finally implemented. I expect that some readers may quake in their boots when they read some of the harder-hitting assertions made by the authors. However, I tend to agree with most (if not all) of the author's points.

On second thought, there is one observation that I made which I am comfortable noting as a weakness. Throughout the book, the authors note that a Service is exposed as a Contracted Interface that defines the relationship between the service consumer and the service provider. Given the critical role of the Contract and the central role that it plays in the whole SOA service abstraction layer, I found it noteworthy that the authors never really provide an example of what a contacted interface would look like (format) or consist of (content model).
Otherwise, no other weaknesses noted.

Recommendations

I would highly recommend this book to all interested parties of SOA or Service-Oriented business architecture and analysis.

Perhaps more importantly, I would encourage the book's widest dissemination among business and IS leadership teams. Ultimately, the book's message is intended for them.

1 of 1 people found the following review helpful:

5.0 out of 5 stars Ignore its hyperbolic title., July 10, 2006

By	Howard Baldwin (San Francisco) - See all my reviews (REAL NAME)

It's really a book that helps businesspeople understand the importance of SOAs. Thankfully--and intentionally, according to the preface--it's the kind of book CIOs can safely hand over to business counterparts to help them understand why SOAs are important. In fact, surprisingly for a couple of self-described nerds, the authors speak more about how emotions and human nature trip companies up than technology does but argue for the merging of IT and business and using SOAs as the territory in which to plant the flag of neutrality first. Certainly this book goes a long way toward being the manual that business and IT can use.

Granted, there may be times when Bloomberg and Schmelzer step too far back into recent history to explain whatever happened to enterprise application integration (EAI) tools and submit too frequently to wordiness in their attempts to be congenial. But the overall end result is a highly accessible book that even explains the difference--clearly, mind you--between SOAs and Web services, along with clear definitions of loose coupling, metadata, and services, but always with a slant toward how they relate to business, not technology.

We need more books like this one, volumes that can help bridge the gap of communication--so much so that your business counterparts may even say these magic words: "Now I understand what you're talking about."

5 of 7 people found the following review helpful:

3.0 out of 5 stars Basic SOA info available elsewhere, May 13, 2006

By	SHMD (Chicago) - See all my reviews

I bought this book with great anticipation, but was left empty. Much of the material in here can be gleamed from other books (Thomas Erl's which has worked examples) and websites (notably IBM's).

For a gentle intro to Services this is good.