Customer Reviews

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

5 star:		(12)
4 star:		(3)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

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.

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."

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.

This is amazing book. It's a practical approach to both understanding the strategic nature of SOA, but how things actually get done. The authors both have a good grasp on the issues here, including technology, and people. If you're interested in implementing SOA in your enterprise, this book is a must read!

Well, I waited anxiously for this book to come out, since I'm a frequent, fervent, and favorite reader of ZapThink's ZapFlash newsletter, their biweekly free email guide on all things SOA and Web Services.

Well, when I heard they had a book coming out, I'm sure that I was the first one to order! Well, the book is now hot off the press and in my hands, and let me tell you, I devoured it in about 3 days. First, let me say that it is a remarkably easy read. The topics are presented in a logical order with the assumption that the audience knows little about SOA. But let me say that even if you consider yourself to be an SOA guru, as I do, you will find this book to be an absolute necessity.

Why? For a few reasons. First, this book positions Service Orientation as a BUSINESS movement that focuses on shifting IT investment from what is today's patchwork of middleware-infested, tightly-coupled, brittle systems to the approach of flexible, loosely-coupled, composable Services. This topic is addressed not from a purely techno-babble perspective, but rather from the perspective of a business person who has to deal with the IT mess they have.

My favorite sections are the discussion of the IT Rats' nest, the explanation of the economics of integration, a detailed insight into all the fundamentals of Service-Orientation, including loose coupling, composition, service contracts and abstraction, policy and process-driven Services, and other details on making SOA work.

But even more relevant are the discussions on how the ORGANIZATION must change in order to properly adopt SOA. While this book won't replace the technical manuals on how to build SOA, this book is an absolute necessity to anyone who wants to actually IMPLEMENT SOA in a way that will actually stick. Use this book as a guide to help make sure your SOA implementation will be a success, or just throw it at your boss to show him that what you're doing is indeed important. Either way, it's worth a read, and one of the best $30 investments I've made this year!

Echoing the other positive comments made.

Personally, I picked this book up because 1) I wanted to gain a non-technical understanding of SOA 2) I wanted to determine for myself whether SOA is mostly hype or if it's a promising new paradigm in software development/ business process engineering. After reading this book, I believe it's the latter (it's a promising new paradigm in software development/ business process engineering).

Authors are good with explaining SOA for a non-technical audience. I especially liked the description of loose coupling.

One sentence near the end of the book struck me as important: "Just as the Industrial Revolution limited the days if the village blacksmith, so too are the days of the artisan craft if IT quickly coming to an end. Indeed, the movement to Service Orientation introduces such significant change to the way people make, consume and purchase IT that it will have as dramatic and irreversible impact on the IT industry as a whole as the Industrial Revolution had on blacksmithing".

Service Orient or be Doomed is an excellent approach to SOA for non-technical people who wants to make IT based businesses flexible enough to match markets evolution.
This is my sixth purchase of the book. I bought it for my personal reading during 2006, and after that I decided to buy additional copies to give as a gift to some of my business colleagues here in Buenos Aires, Argentina.
Great book, easy reading and full of concepts and new ideas. I strongly recommend it.
Javier Bazo
Buenos Aires
Argentina

First the disclaimer. I know Ron and Jason professionally and have been reading and admiring their visionary research for a long time. While I might disagree with them on rare occasion (see my upcoming blog on webservices.org), I only bring this up now so that hopefully the wise reader can take me at my word when I say that that this book is simply a necessity for any person who wants to understand, prepare, and successfully leverage SOA, which will initiate profound challenges and changes that will affect both the IT organization and the business itself.

Senior IT and LOB management will especially benefit from the practical suggestions and really easy-to-understand business-centric perspective that Ron and Jason apply to even the most difficult issues.

This book goes beyond the mere mechanics of construction and examines the more difficult and subtle issues of how to make a SOA initiative successful in the enterprise. There really is not another source for this vital information or perspective that even comes close. These guys have a tremendous amount of real-world wisdom and experience to share. Ignore at your own peril.

I truly would have given this book more than 5 stars if I could have, but Amazon allows only a maximum of 5. This is the only book that I know of that treats the notion of service orientation from a "business first" perspective, portraying technology as an enabling factor rather than a primary factor. And that is exactly the way it should be.

The authors also provide very valuable historical information regarding "how we got here" (e.g. history of the World Wide Web, etc.) which is a necessary part of understanding and applying the concept of service orientation. I highly recommend this book to both business and technical audiences. For business folks, it will provide them with a deep understanding and appreciation for service orientation and - as the title says - how it can truly change your business; and for technical folks, it will enable them to "stretch their mind" to see the true potential of technology when it is applied and viewed in the manner conveyed in this book.

A must-read...the only book of its kind. Bravo Jason and Ron!!!

Joseph Chiusano

Having known these guys for years through their Zapthink Consulting practice, I expected this book to be rich with practical, real-world experience garnered from their direct involvement in not only helping large enterprises with SOA roadmapping, but in truly defining the SOA space. What I read was that and more - the most interesting aspect being the way that they have described the business and organizational implications which are critical to understand before heading down the SOA trail.

While techies will get a ton of value from reading this one, their sr. business counterparts may get even more. A great read, peppered with enough wit to keep the topic fresh and interesting. Nice job guys!