I’ve seen a lot of procedural code written in an object-oriented language. Particularly, I’ve seen this done with C++ in the days when object-oriented design was first gaining familiarity in industry. I attribute this to the fact that most of us C++ programmers were first C programmers. We wedged our old design approach (procedural programming) into a new programming model (object-orientation).

I suspect we’ll see an analogous situation with service-oriented architectures. In fact, I’m beginning to see it already. It is possible to construct a service-oriented system with currently available technology. But technology isn’t our biggest roadblock, our experience is. We must design differently if we expect our SOA to work.

As a software engineer who was once inexperienced with object-oriented design, I could still understand encapsulation. But until I’d built a non-trivial system that made good use of object-oriented principles, I could not appreciate encapsulation. There is an indescribable pleasure that comes from being able to modify part of your software while having the rest of it go on working beautifully. It’s the result of encapsulation and it’s also a bit of a high. And the pursuit of my next fix is what drives me to apply object-oriented principles with all the more rigor.

In the short-term, it’s usually more work to do the right thing. It’s not easy to find the right abstraction or to make the right design trade-off. It’s faster and easier to just write some code that solves the problem at hand. But I work hard at finding that abstraction because I know in six or twelve months, I’ll be glad I did. I know this from my own experience. Without this experience, I might say, “Why bother?”

As practitioners, we’re at a point with SOA where many of us were with OO about 10-15 years ago. We understand the tenets of SOA, but we don’t yet appreciate the benefits. And until we do, we won’t choose to incur the cost.