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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
