Net-Centricity, SOA, and Web 2.0

Top Heavy SOA

I recently read a CIO Magazine article called, "SOA’s True Challenge—It Ain’t Technology." This is a good SOA article (it is surprising how few there are). I would be more specific than stating "SOA: It ain't technology" but more like "SOA: It ain't about products/vendors." I think this is what they mean. The article leans heavy on architecture which is right-on but designing SOA without knowledge of technology is like designing a skyscraper without knowledge of materials. I say this because I'm afraid those building SOA will downplay knowledge of technology, fail to bring in the right skills, and then build a very poor SOA architecture because "hey, it's all about the business right, we don't need those technology people."

That said, I think it does capture the need for bigger picture business alignment (i.e., the consumer design piece) but also gives some credence, although not enough in my opinion, to the transformation of select current systems functionality into leverage-able services (i.e., the provider design piece). These need to be done in parallel with the latter delivering value in the very short term. From all I've seen in the past 8 years of doing SOA and EAI, leaders rarely have the inclination/endurance to sit through a 12 to 18 month design phase before even starting development and implementation that won't deliver value for another six months or more. I run into this issue with my current SOA projects where people are saying, "We don't have time for this fantasy [SOA] that may deliver value who knows when, we need to solve problems today."   

The article states "But it also introduces new challenges for CIOs—challenges that stretch IT's abilities in areas that have been chronically underdeveloped: process and architectural planning. Their staffs will also be stretched. In short, CIOs who expect that they can do SOA the same way they've always done technology implementations risk being blindsided."

You may already be tired of me harping on the importance of the bottom-up (i.e., provider side) aspect of SOA design and development. I hope not because I'm sure there is more to come. I'm worried that the industry is placing too much emphasis on the heavy top-down design effort. Over emphasizing it is a sure way to slow down SOA adoption and create a great deal of unnecessary pain. Organizational change is always been an inhibitor to new technology and it is no different for SOA. Don't get too caught up on top-down reengineering of business and/or IT or you risk the wrath of change management beast which has killed more IT efforts than bad technology and poor business alignment combined.

I'll say it again, start small and build momentum.

Grady Booch is Mistaken

I recently read an unfortunate interview with Grady Booch (the famed modeling language guru) entitle "Grady Booch | Avoid the ‘stupid’ SOA approach." In this interview Mr. Booch espouses a top-down approach to SOA and labels a bottom-up approach as "stupid."  This is a very surprising position for a technologist who has made his career in top-down systems design modeling. Not! What is surprising is that he seems unable to see SOA from other perspectives. Mr. Booch exposes his ignorance of SOA. This ignorance probably stems from his ivory tower position with IBM where he must have lost touch with those, like me, who build SOA systems.

To state that top-down is the only way to approach SOA and that bottom up is "stupid" is simplistic and shortsighted. More unfortunate is that it perpetuates the perception that SOA is a top heavy, drawn out process that doesn't deliver results for years and only after prodigious investment. This is counter to the desires of CIOs to solve the problems they face today. Too many people think of SOA only as an enterprise architecture play tied to the "big picture." SOA is best implemented at a systems level or a controlled system-of-systems level. Let it evolve into an enterprise architecture.

My experience is that SOA must be both a top-down and a bottom-up effort. Top-down to ensure it moves towards longer term objectives but bottom-up to solve today's problems and remain grounded to the systems that provide the services in the near term. A bottom-up approach enables a migration path from the existing systems to the objective systems. Few organizations have the luxury of scrapping all they have to start building a pure SOA.

He misses the critical division of labor between consumer and provider treating SOA systems just as any other traditional systems development effort rather than approaching SOA from a market driven perspective where exchanges can be created by organizations "exposing" valuable data and functionality to the marketplace. Think of the top-down approach as the service consumer perspective and the bottom-up approach as the service provider perspective. Using market vernacular, think of top-down as the customer perspective and bottom-up as the merchant perspective (notice I avoided the term "vendor" so not to confuse).

He also goes so far as to state that "The idea of services is not a means of abstraction. It is simply a mechanism for reaching into systems." I am stunned. I am hoping the interviewer just simply got this quote wrong. First of all, what does "the idea of services" mean. I can't remember the last time I implemented "the idea of services." I suppose you could implement a service without the web services means of abstraction - but you would be wrong! Creating a service is all about delivering leverage. How can you really deliver leverage without an abstraction layer? SOA is all about leverage. It is all about abstraction. It is far more than simply a mechanism for reaching into systems. We have been reaching into systems with non-abstracted, tightly-coupled mechanisms for years and where has that gotten us? Without the loosely-coupled abstraction, SOA would not be experiencing the hype it now enjoys. In fact, this blog wouldn't even exist (believe it or not).

I may be a little hard on him but he should realize that his cavalier remarks make it more difficult for us to make SOA success a wide spread reality.

As far as his "hype" comment goes; name a significant technology that didn't go through the hype stage. Hype is a natural reaction to something with great potential. Hype is simply the time lag between our imaginings and the world's realities. SOA will catch up to the hype regardless of Mr. Booch's careless comments.

I just ran spell-check on this blog entry and the dictionary wanted to replace Booch with Botch. It also wanted to change SOA to soar. Coincidence, I think not.