Codejockeys won’t drink the SODA
- By Stephen Swoyer
The service-oriented development approach (SODA) describes a programming model
in which key application features or functions are exposed as well-defined interfaces
that can easily be called as services.
Service enablement is often a reactive discipline, in that it’s largely concerned
with existing applications that haven’t been designed for a serviceoriented
architecture. SODA, on the other hand, is a proactive discipline. It results
in applications that are, by definition, service-enabled. To the extent that
SOA—or some pragmatic variation thereof—is inevitable, SODA should drive the
creation of applications that are good SOA citizens. Sounds great, right?
Yes, it does, many codejockeys say. In fact, some argue, it’s a no-brainer.
For this reason, some skeptics question whether SODA is a design approach that
needs to be explicitly identified— much less acronym-atized. If you’re pursuing
service-enablement, they say—and even if you aren’t—exposing an application’s
features or functionality in the context of well-defined interfaces just makes
good design sense. Call it SODA. Call it Proactive Enlightened Propitious Service
Instantiation (PEPSI)— call it what you want, it’s a good idea, and it’s a major
part of what goes into building future-tolerant systems and applications.
“[T]he promises of SOA—autonomy, explicit boundaries, schema and contract,
those are sort of the same things that we’ve been trying to get to for years,”
says Chris Wheeler, an eXtreme Programming coach and technical team lead with
a prominent manufacturer of analytical instruments for the life sciences and
pharmaceutical industries. “Nice little silos of functionality that are completely
separate from other silos and have narrow interfaces that are well described.
Sounds a lot like good design principles—low coupling, high cohesion.”
That’s the approach Wheeler and his colleagues use—although they don’t call
it SODA. “We don’t want to lock into a vendor to provide us with one standard
for orchestration and application integration, and find out down the road it
was the wrong tool. For now, creating architectures that are SOA-ready seems
to be the way to go,” he concludes.
Matthew Fleming, an enterprise architect and freelance consultant, agrees.
“I think Web services [or] SOAs are marketing terms used to describe good ways
to share data across the public Internet, nothing more,” he says. Far from embracing
an explicit services-ready design approach such as SODA, says Fleming, developers
would do better to focus on the basics. “What I’ve found is that many developers
and shops hop onto the technology bandwagon while a technology is still maturing,
and through lack of experience, deploy applications that are less than ideal,”
he comments, citing the preponderance of “bad COM code” as a case in point.
“With all that in mind, if programmers can focus on clean, simple design, and
not rush headlong into SOA, then I think that people will find service-enabling
architectures to be advantageous in their solutions.”
Ken Auer is an agile programming enthusiast and a principal with agile development
house Role Model Software. He isn’t a knee-jerk skeptic of service-enablement,
but Auer is critical of service-enablement for service-enablement’s sake, which
he says is an engine for needless complexity and confusion. And in the case
of SODA—which requires business analysts and programmers to make guesses about
which features or functions should be exposed as services, as well as about
how coarse or finegrained these services should be— there’s plenty of room for
“People are taking existing applications and putting a new interface on it
to provide a boxy service that works for some things and has to have the rough
edges shaved off by some more programming for others. Others are building new
applications and imagining the interfaces others will want to use. They guess
at some well, and others need a lot of work,” says Auer. “What we often end
up with are problems that still need to be solved. The services offer a starting
point. Often, they are merely the equivalent of the first two lines of a complicated
solution to a calculus problem, where the rest of the proof is left to the student.
There is still a lot more work to do, and often what’s left is the hardest part
of the problem.”
Alex Cullen, an analyst with Forrester Research, doesn’t disagree with Auer,
or with most other SOA realists, for that matter.
At the same time, he respectfully suggests, SODA makes sense, both on an intuitive
level (as “good” design) and also when understood as an explicit design approach.
The problem, Cullen says, is that the great blue-collar mass of programmers
isn’t accustomed to coding in terms of clean or elegant design. They need some
help. And SODA provides an explicit framework to guide them. And as far as many
rock-star programmers are concerned, SOAs aren’t a slam dunk, either: they assume
an unprecedented alignment of business and IT, with the latter taking a backseat
to the requirements of the former. To the extent that many programming rock
stars aren’t the savviest of business analysts, they’ll undoubtedly need help,
Back to Feature: Services
Stephen Swoyer is a contributing editor for Enterprise Systems. He can be reached at firstname.lastname@example.org.