Monday, April 6, 2009

Why Services Are Hard...

...or at least one reason why... :-)

I ran across a quote from "Who Says Elephants Can't Dance?", Lou Gerstner's book about how he changed IBM:

“I came to see, in my time at IBM, that culture isn't just one aspect of the game—it is the game. In the end, an organization is nothing more than the collective capacity of its people to create value....I have a theory about how culture emerges and evolves in large institutions: Successful institutions almost always develop strong cultures that reinforce those elements that make the institution great. They reflect the environment from which they emerged. When that environment shifts, it is very hard for the culture to change. In fact, it becomes an enormous impediment to the institution’s ability to adapt.”

I suppose this has always been true, but was less noticeable when organizations were smaller and the world changed more slowly.

Today, most large organizations are fundamentally complex transaction-oriented information ecosystems, or they specialize in the design, development, or maintenance of systems within such ecosystems.

Service orientation (not technology per se) transforms a transaction-oriented information ecosystem into a hybrid that both (a) maintains its transaction processing capabilities and characteristics, and (b) exposes services, enables the relatively unstructured bottom-up/middle-out wiring together of services, and creates innovative new information transformation capabilities (along with new management capabilities).

The culture that produces transaction-processing excellence tends to focus on such qualities as predictability, reliability, and lack of deviance from a standard, and tends toward a bureaucratic organization with well-defined roles, rights, responsibilities, and processes to create and maintain that excellence.

Such a culture is in most ways poorly suited to thrive in a service-oriented ecosystem with its dynamic, emergent, and relatively unstructured exploration of potential information transformation capabilities...many of which are also potentially disruptive.

If you work in a large organization, you may have seen a "deer in the headlights" response to this new "dance" challenge, which seems to be nearly universal these days for elephants since large organizations today are usually information-intensive.

If it's hard for the elephants, it seems even harder for the elephant keepers...who don't know how to do anything but design, develop, and maintain elephants.

And, what makes this especially difficult is that it seems to be as much about turning elephants into composable "ropes, spears, fans, etc." as it is about getting the elephant to move learn new steps.

Seems like more than a minor identity crisis is emerging...

2 comments:

-ko said...

I would comment that there may be a need to break services into groups like Mike Rosen does. From my own experiences, the most important (most used) services are nearly always "data services". Further, it seems to me that we are, with SOA, reinventing "database management at an enterprise level".

Ken Orr

WalterRSmith said...

You highlight a contrast that seems pervasive...should we focus on the activities that transform data/state or on the structure of data/state in light of the potential transformations? Since we're sequential/narrative in how we think, it's more natural to do the former...but we're likely to end up with a mess once we move beyond a relatively constrained scope...one reason why SOA governance is important (and challenging). I'm also reminded of the difference between functional and imperative programming...