Management
introduction
Service
(or Services) Oriented Architecture(s) (SOAs) are a fashionable subject
these days. There is much talk, but not
necessarily as much action as many would have you believe.
In
this analysis, Amy Wohl examines where SOAs are currently placed, and what
may happen next. A key question is whether they really are a step on the
long road to a ‘User Specified Software’ environment.
Setting
the scene
Sometimes
it feels as if the history of the information processing industry
could be divided into periods demarcated
by which scheme was currently being promoted for developing software.
Always we seem to be an industry in search of ways to make software easier
to create, and much faster to develop.
That
is because we are seeking to achieve three important goals:
-
Being
able to react quickly and flexibly to changes
within a business organization, with
supporting changes in an IT organization
-
Enabling business organizations to drive both
what
software does and also how much of an organization’s
IT resources will be allocated to solving
each business problem, preferably in an
automated way
-
Permitting user participation in the software
specification
process (perhaps even in the software
creation)
by providing tools that exploit
business
knowledge yet do not require programming
skills.
Think
of those goals as a Holy Grail that the IT industry has
been
in search of for years. By definition, that means we have
not found it yet.
But
we have been looking. Sometimes the emphasis is on
assisting
professional programmers, with easier to use programming tools
and schemes to architect software in a formal
way
and re-use code. You will remember Object Oriented (OO) Programming. I remember not only the rise
of
OO (the coding concepts and methods survive, of course),
but also any number of failed schemes to manage
and
re-use a diverse selection of objects — and even elaborate schemes
to create markets on which to sell those objects.
Integrating
business
knowledge
with programming skills
At
other times, the emphasis is on trying to figure out how
to
integrate the skills and knowledge of:
-
Business professionals (who know everything about
the business but nothing about programming)
- With the skills and knowledge of programmers
(who
know quite a bit about how to write
good
software, but nearly nothing about the
businesses
they work in).
This
problem has bred an amazing variety of solutions.
Some
emphasize tools for capturing business knowledge
and passing it on to professional programmers, who will
then
write the software. Many business process modeling
schemes
fall into this category, together with methods for providing definitions for the tasks being modeled.
Others try to provide tools which enable the business professional
have one view of the problem (a non-programming
view,
to be sure) and then send that view, perhaps
augmented
or filtered in some suitable fashion, to a programmer
who
can then use high level tools (lots of dialogue
interfaces
and pick lists) to create the software. New
versions
of tools from most sophisticated development tools
providers, such as IBM’s Rational, seek to provide the
means
for every member of a team so that, with suitable integration
among the inputs and outflows, productivity
can
be maximized.
Still
others focus on the business professional as the user
and
attempt to provide tools which will allow him or her to
specify
a solution and pull previously written software elements
together
without writing code. Such ‘programmerless
programming’
is a worthy goal, but it has rarely
succeeded.
The resultant tools are:
-
Either limited in scope (they can do some
things,
but not all the things the business professional
might
need)
-
Or they require that the non-programmer
acquire
substantial understanding of programming-like
skills (if you do not believe me, I refer
you to 3rd and 4th GLs and Natural Language
Programming
— see also Figure 2.1).
Web
Services are a more recent candidate for creating
more
granular pieces of code (‘services’), together with
schemes
for storage, retrieval and re-use. These have been
interesting
mainly, so far, for their abilities to wrap legacy
applications
in XML wrappers, thereby allowing them to be
more
easily integrated with other software. In vertical
industries,
where services have been created that are specific
to
tasks in that industry (insurance, for example), user
organizations
have also been able to speed development
time
by adopting the Web Services model.
And
now there are SOAs
In
the meantime, along comes SOA, allegedly an improved
approach
to Web Services. I know that it is often poor form
to
quote from your own writings, but I am unable to resist
putting
in a short bit from my IBM DeveloperWorks blog
that
seems relevant here.
SOA
: one more step on the road to ‘User Specified Software’?
“At
any moment in time we have tools that reflect the
problems
we’re trying to solve and the technology that’s
currently
available to solve them. It’s important not to think of
this as a permanent situation. Both the problems and the technology
are changing all the time so, of course, the tools
are going to evolve, too. We have to keep up with all
this
and not get frozen in some prior solution state.” [Amy Wohl’s
Blog on IBM DeveloperWorks — http://www.128.ibm.com/developerworks/blogs/dw_blog.jspa?roll=-2&blog=455
May 26, 2005.]
You
will want some context. I wrote this during the Rational
Developer
Conference, which I was attending and blogging.
My
careful statement above is really a distillation of
what
Danny Sabbah, Rational’s new General Manager, said
at
a press conference after his keynote presentation. He
pointed
out that nothing, not even something as smart and
appealing
as SOA, would last forever but rather that it was
the
solution for now — to be succeeded five or more years
into
the future by something better.
The
trick here is to understand:
-
What any
‘new, new thing’ offers
-
Whether this
is likely to be of real value to
your
organization
-
Where it (the
‘new, new thing’) is in its cycle of
development
and adoption.
It
is the third point that is the killer. If it is too early, the
technology
is likely to be less than fully developed. You can
try
it out, but many of the pieces will be missing, or at least will
not yet be well refined. More to the point, the ecosystem
of
supporting tools, training and skilled professionals you
may require will not yet have appeared in the marketplace.
Conversely,
if it is too late, and you are unlikely to obtain
sufficient
from your investment before something else
comes
along and looks better.
A
study of IT perspectives on SOA
The
British research firm Quocirca Ltd. recently spoke with
1,356
IT professionals — worldwide — and asked them
about
their knowledge of, and plans and experiences with,
SOA
in a study called ‘SOA: Substance or Hype?’ About
35%
of those who responded had looked at SOA in a
detailed
way and nearly all of them (99%) believed there
were
significant benefits to be gained using an SOA. Some of
the benefits they cited (hoped for) included:
-
Faster
development
-
Improved
deployment and maintenance
-
Reduced
integration time and costs
-
Enabling IT
to be more responsive to the business.
Across
all of the 1,356 study participants, nearly 45% are
active
in SOA now (18%) or plan to be active within the
next
year (25%).
Study
participants also believe that:
-
The implementation of SOA for key commercial
software
applications benefits interfacing and
integration
-
Web Services facilitate the connection of user
organizations’
systems with partners, customers,
and/or
suppliers
-
Web Services and SOA together make it easier
to
integrate in-house and hosted applications.
Nevertheless,
adoption rates are still relatively modest,
especially
in Asia Pacific. Quocirca believes that most users
are
still only at the beginning of the SOA process. (You may
get
your own copy of the Quocirca study by going to
Quocirca
at: http://www.quocirca.com/reports_soa.htm)
Why
should every firm (in a regulated
industry)
create their own reports?
I
spoke with David Kelble, Vice President of Corporate Systems
at
American Business and Financial Systems of
Philadelphia,
PA — a mortgage company. Kelble noted
that
his personal knowledge of SOA was at the ‘reading’
level
these days, but he could see the use of Web Services and
componentized applications growing. He felt that a
company
like his would be interested in SOA over time.
For
example, he pointed out how — in his industry —
everyone
makes extensive use of government forms and
reports
to the government using these. There is no reason
why
each firm should do their own programming to create
these
reports. As examples he identified the IRS 1098 and
1099
forms for reporting payments to contractors and the
HMDA
reporting to the federal government (this provides
then
demographic statistics for mortgages, to ensure compliance
with
non-discrimination regulations).
How
open is open?
One
myth often associated with SOAs are that they are
entirely
based on ‘open standards’. While it is true that
underneath
an SOA are Web Services based on Open Standards,
building
composite applications out of the (hopefully) re-usable
services calls for someone’s specific
development
environment. The reality is that each major
offering
for this has its own eccentricities. It is possible to
do
integration across services developed in different development environments.
But it is definitely easier to work
with
services that were all developed within (or for) your
specific
development environment.
That
means you may want — or have — to choose a single
development
vendor for your organization, and trying to
take
everyone’s requirements into account. But it is impossible
to
dictate what everyone in an extended environment
(partners,
suppliers, customers) uses. If this is your reality,
you
will need to be prepared to spend much more time and
effort
in the integration process and on tools that are
designed
to support multiple platforms.
Management
Conclusions
That
said, SOAs are catching on. They are not the cure-all
for
everything — any more than any other technology can be
— but they are appealing. It is wise, however, to
remember
that SOAs are really only the latest offering in a
long
line of technologies, each of which hoped to make it
easier
for business users to communicate with application
developers
and, therefore, easier to develop good software.
Similarly,
it remains true that, in IT, major investments stay
around
a long time, often much too long. Such investments haunt
those who made the decisions — and those
who
have to live with those decisions — along with elusive thoughts
of better decisions that might have been made in
the
past.
This,
of course, can produce a fool’s game. Technology is
not
something with a beginning and an ending, but is
rather
a continuum. There are better times and worse ones
in
which to make investment decisions. But all of us must make
decisions nearly every day. What is important is to
learn
how to make the best decision for right now — and how
subsequently to change your mind gracefully and
transition
to a better alternative when it inevitably comes
along.
|
On
the Way to SOA
|
|
Name
|
Concept
|
Fate
|
| 3rd
and 4th GLs
|
Query Languages for Business
Professionals
|
Strict Syntax limited their
use to small numbers of frequent users.
|
| Natural
Language Programming
|
Users could write programs in
ordinary English (or French or German . . .)
|
Reality could never meet user
expectations. There are
always rules and limits, depending on how much AI is built into the
software and how much processing and memory is made available.
Of course, we’re getting better at it over time.
|
| Object
Oriented Programming (OO)
|
Separate Data and Program;
Reuse Code
|
OO Lives on.
Code reuse has always been sparse.
|
| Business
Process Modeling
|
Tools for modeling business
processes and/or work flows.
|
An important part of Web
Services and SOA
|
| Web
Services
|
Creating applications as more
granular services (or componentizing existing applications into
services)
|
In Progress -- Slowly
|
| Service
Oriented Architectures (SOA)
|
Combining componentization of
software with Web Services interfaces
|
In Progress
|
All
rights reserved; reproduction prohibited without prior written permission of
the Publisher.
©
2005 Spectrum Reports Limited
