In the early days of client/server adoption in the 1990s there were lots of articles lamenting the fact the client/server wasn’t living up to its promise. It was just another theory that didn’t really work all that well in practice.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But after a few years client/server was just the way application development was being done. It wasn’t a theory any more, and too some extent it ceased to be a hot topic for debate. It was old hat.
New technologies including XML, Web services and finally SOA became the hot topics. Of course, as a Gartner Inc. analyst pointed out in a talk a few years ago, SOA pretty much began in the mid-1990s as an extension of client/server.
“Customers were doing SOA then although they weren’t calling it that,” Massimo Pezzini, vice president and distinguished analyst Gartner Inc., said in a 2006 talk. They tended to use the terms of the 1990s for their projects, calling them client/server. Pezzini said that is the secret few SOA gurus want to let out of the bag: SOA is an update of classic client/server.
In a recent article about the problems with SOA adoption, Ron Schmelzer, senior analyst with ZapThink LLC., also credits Gartner with the transformation of client/server into SOA in 1996.
So it seems client/server, which didn’t live up to its promise, has morphed into SOA, which isn’t living up to its promise. But lots of organizations did client/server even if they did it imperfectly, and it appears organizations are now doing SOA albeit imperfectly.
The nature of things humans do is that they are generally not perfect and almost always could be better. With the exception of 4.0 students, most of us got educated imperfectly. The interstate highway system in the U.S. is far from perfect but we’ve been getting around on it for decades. City planning, which Schmelzer says may be the best analogy to SOA because both are always works in progress, does not produce perfect cities. But it could be argued that city planners in many cases help design more liveable and workable cities.
Interviews with CTOs, architects and developers who are actually doing SOA indicates that progress is being made despite the lack of perfection.
In a user story this week Manny Montejano, CTO at Cars.com explained how he is achieving the elusive SOA goal of getting business executives and managers to drive SOA initiatives. But at the same time, he pointed out that his SOA implementation is only about 30 percent of the way to achieving its ultimate goals. And there have been bumps in the road but he views them not as failures but as learning experiences.
“I’m not saying we’ve done everything perfectly every single time from the get-go, which is where our lessons come from,” Montejano said. “We’ve learned lots of lessons specifically that this is a business initiative not an IT/technical initiative.”
Most of the people who are actually doing SOA talk about it in turns of evolution, or to use Schmelzer’s city planning analogy, an on-going project that is always changing and evolving but is never complete.
Shibashis Mukherjee, lead enterprise architect at Con-Way Inc., the transportation company, actually began work in 1996 on what has become his company’s SOA implementation.
In his account of more that a decade of working on the evolution, Mukherjee recalled: “We started with the component-based development methodology. At that time SOA wasn’t the big thing yet. We realized it would help us develop faster if we had reusable components to build applications. As our development process matured and SOA came into play, we figured out how to compose the services.”
Perhaps if SOA is viewed as a process we would be less impatient with its lack of perfection.