Business Architecture is not for Dummies
Spirit on the water
Darkness on the face of the deep
I keep thinking about you baby
I can't hardly sleep
I'm traveling by land
Traveling through the dawn of day
You're always on my mind
I can't stay away
- Bob Dylan, Spirit On The Water (from Modern Times)
I can't seem to get this post out of my head. Steve Hamm of Business Week writes about a forthcoming book called Service Oriented Architecture for Dummies. This book is written by an IBM'er who is, no doubt, touting the company line that the road to the business runs straight through the ESB. Normally I'd just think the PR person did a fine job of getting some ink in Business Week and move on.
But, "SOA for Dummies." It just sticks in my craw. The web site says a "related article" is about "building web services."
My mind drifts over to other types of architecture and I wonder, for example, what Frank Lloyd Wright would think about a book called Organic Architecture for Dummies. What would he think of distilling the notions of architecture down into a simplistic book so that masses of people might buy into some generic, commercially-driven set of building blocks, like the T-Square as the basis for architecture, for example. (Commercialism isn't the problem, FLW charged a small fortune for his services... but who would be the more-likely author of "Architecture for Dummies": Ellsworth Toohey or Howard Roark?).
This strikes me as just another way we start with a technology viewpoint, and try to shove it onto the business, as opposed to understanding the business and pushing it more into the technology. Many business leaders have abrogated the management of technology and left key technology decisions to be made in a vacuum that doesn't include enough business context. It's a world-view that the stack vendors have a vested interest in maintaining, but it's the wrong come-from, as we used to say in Oklahoma.
Business needs to drive technology... there needs to be a "business architecture" before a "service-oriented architecture" makes sense. Some SOA-advocates work like this, but all too often there are those who wear only the sheep's clothing of business orientation, when, in fact, they quickly focus on the technology assets as opposed to the business goals. For example, they may say that web services are a key part of SOA when, in fact, they are an implementation choice not an architecture. Other implementation choices masquerade as architecture, and serve to obscure the real changes that can occur today. Most people don't really want change, they just want to get their funding based on it...
The "business" will not be won over by SOA because SOA does not provide the direct connection to the business strategy that business people are looking for. It is too coarsely-grained; too opaque. We do need a new way to manage technology consumed inside the business.... it must get closer to the business... but SOA is not that thing.
We need serious thinking about what the modern organization desires and how it should accomplish those desires. We need top-down understanding of the linkage between business strategy and the tasks performed to implement that strategy, and then we need to build a business architecture to support it.
Starting with SOA is akin to starting by designing the foundation, before you design the building. It proliferates the mistakes of the past: a bottom-up or middle-out approach to a problem that is, at heart, as fundamental to the future of the business as the decision about products and go-to-market strategies. The usage of technology is now one of the two or three fundamental decisions that an organization makes that "matter." Decisions about how it is used will affect your company's future. SOA should be a reflection of those decisions, not the reverse.
As Frank Lloyd Wright said: "Form and function should be one, joined in a spiritual union." SOA is the form to the business function. And today, the closest thing we have to being able to define business function is called "BPM."
So my problem with notions like "SOA for Dummies" is that, once again, we are spreading a technology-led message to less and less technical people, in an effort to help them "get it" when what we should be doing is spreading business-led messaging to more and more technical people so business understanding is shared. AND we should simultaneously be telling senior business leadership about how technology must become embedded into the fabric of the business, driven every day by the business and not sluffed off on IT. This has management, incentive, personnel and organizational implications not yet dealt with by most large organizations... these are the key factors, not the basics of a Service Oriented Architecture but, rather, the basics of an information business driven by technology as a first class citizen along with the people.
Technology defines our ability to compete in a world where more differentiating costs are incurred by the complexity in our value chains than by the product and selling costs in those chains.
Instead of buying the book and smoking the Dummy, how about every company start publishing your own "Our Balanced Scorecard for Dummies" and giving it to every employee? And then, ask each of them to measure how much they contribute to the scorecard, and which areas they most affect? If they can't answer those questions with clarity, then solving that problem is probably worth a lot more than a whole stack of books on Service Oriented Architecture...
Subscribe
Hi Phil - Irony of ironies, I think when you actually lay eyes on SOA For Dummies you’ll find we’re in violent agreement. You say “If the new abstractions that SOA strives to depict are to be useful in the way I think they can, then implementations are to be considered second, and the business understanding must come first.” I completely concur and helping business people understand what you’re saying is exactly what we set out to do. SOA For Dummies is not about implementation tactics. It is about making the basic power and concepts of Service Oriented Architecture accessible and comprehensible to both business people and to the hoards of technical people who have yet to come in contact with the ideas.
Taking a quote from page one “The promise of service-oriented architecture is to liberate business from the constraints of technology.
“From our perspective, one of the most important aspects of SOA is that it is a business approach and methodology as much as it is a technological approach and methodology. SOA enables business to make business decisions supported by technology instead of making business decisions determined by or constrained by technology.”
We stress the criticality of business process management and SOA governance. We talk about the nature of organizational and cultural change that will be required to effectively implement SOA. In short, the book is not at all what you suppose it to be. IBM has run out of the 10,000 copies they ordered of the minibook - a 66 page business-oriented introduction excerpted from the 384 page comprehensive book. However the full-length version will be available October 19th and can be ordered on Amazon.com now. I look forward to your feedback on the actual book.
Carol Baroudi (Co-author Service Oriented Architecture for Dummies)
Posted by: Carol Baroudi | September 09, 2006 at 09:15 AM
Hello, Robin... sorry for the incorrect depiction of your employer... I actually did assume you worked for IBM since it was IBM that distributed the book to Steve.
However, the point of the post was to say that SOA is a different beast, to me, than, say, C++. For example, a book called "architecture for dummies" would gain my scorn whereas a book called "bricklaying for dummies" wouldn't. The issue is whether SOA is about architecture, abstraction and alignment vs. implementation. It's the difference between architecture and construction.
Don't get me wrong, making things easier for people to understand isn't the issue; simplifying is a good thing. But too often, in an effort to simplify something, we lose the power of the original idea. This is more often the case when the powerful idea is abstract (eg. in the case of SOA) than when the idea is an implementation (as in the case of C++). It can be done - I am thinking of the first half of Stephen Hawking's 'A Brief History of Time', for example - but it's rare.
If the new abstractions that SOA strives to depict are to be useful in the way I think they can, then implementations are to be considered second, and the business understanding must come first. Poliies of governance must be understood and agreed. The company's balanced scorecard - or whatever set of metrics is used - needs to be considered. Etc.
To reduce SOA to a set of implementation tactis is simply the wrong way to think about SOA, in my opinion.
Posted by: Phil Gilbert | September 06, 2006 at 05:08 AM
You state that "This book is written by an IBM'er who is, no doubt, touting the company line that the road to the business runs straight through the ESB."
Awesome! Where do you get your unreliable information from? As one of the authors of the "SOA for Dummies" book (the others are Judith Hurwitz, Carol Baroudi and Marcia Kaufman) I can confirm that none of us has ever worked for IBM.
The book doesn't advocate ESBs particularly either, but hell, why bother to gather any information about the book or even read it before you condemn it?
You seem remarkably snobbish about the production of a book that is aimed at explaining something that is actually quite difficult to understand. Do you have the same objection to, for example, "C++ for Dummies"? Is that also guilty of "the sin" of spreading a technology-led message to less and less technical people, in an effort to help them "get it"?
Perhaps you should organize a "book burning" event or [PG:removed]. (We'd prefer the book burning event ourselves, because of the royalties).
Yours sincerely
Robin Bloor
Posted by: Robin Bloor | September 05, 2006 at 12:27 PM