The spiral staircase of SOA

Back in the 1980s, object-oriented programming was a state of mind, not the state of the art. Sure, there were OO languages, tools, and frameworks -- such as Lisp and Smalltalk -- but mainstream developers didn’t use them. Mainstream developers worked mostly in C.

The best of those developers, however, figured out how to apply an OO mindset to their use of C. I was lucky enough to have worked with a few of these wizards. From them I learned everything I know about interfaces, abstraction, composition, and dynamic behavior.

These days, the Java and .Net environments embody the kinds of best programming practices the mastery of which formerly required superhuman discipline. Wizards with long memories can’t help but wonder why it’s taken so long. In forums and blogs devoted to programming technologies, they’re always pointing out -- correctly -- that much of what seems to be modern innovation is, in fact, rediscovery of those ur-languages, Lisp and Smalltalk. But progress in the art and science of software development isn’t a stepladder, it’s a spiral staircase.

Today, service-oriented software development is likewise a state of mind, rather than the state of the art. Now that our object-oriented kits give us the power to model data and behavior in the realm of IT, the higher goal is swimming into view. We envision service-oriented kits that we’ll use to model the business processes supported by -- or more accurately, embodied in -- our IT infrastructure.

If history is a useful guide, there are a couple of important questions we ought to be asking. First, who are the modern counterparts to the OO do-it-yourselfers of yesteryear? Jim Culbert is one example. As CTO of MetraTech, he modeled that company’s billing services using SGML because XML hadn’t yet arrived on the scene, never mind SOAP, WSDL, and WS-*.

Harvard Medical School CIO John Halamka  is another example. His software model of the financial and clinical processes enacted by New England physicians, hospitals, and insurers also predates our current SOA technologies.

These two pragmatic visionaries prove that SOA is above all an intellectual style, a way of thinking about IT services as the direct expression of business services. This is a rare talent, but one that doubtless exists to some degree in your enterprise. I suggest that you seek it out, nurture it, and reward it. The technical skill that matters most, going forward, may not reside in the most obvious places.

The right mindset won’t easily scale, of course, until you latch onto the languages, tools, and frameworks to support it. True, extraordinary things can be accomplished with extraordinary vision, foresight, and discipline. But most of us require some extra leverage to routinely achieve what’s possible.

So here’s the second question: In the realm of service-oriented design and business-process modeling, what are the modern counterparts to Lisp and Smalltalk? Maybe when we look back on the present moment, we’ll wish that we’d paid closer attention to rules engines, workflow designers, and business-process modelers. Maybe the graybeards of 2020 will heave collective sighs as we rediscover what they always knew.

If existing tools can do more than we realize, we could spare ourselves a bit of grief. But probably not a lot. Translating ways of thinking into ways of doing always takes longer than we predict.