Transcript: Identifying and Federating Today's SOA Power Centers Through Enterprise Service Buses
,
About this feature:
Participants in this Webinar include Joe McKendrick, author of
ebizQ's SOA in Action Blog, and Leif Davidsen, manager of WebSphere SOA
Marketing for IBM. This transcript has been edited in parts for clarity.
Joe McKendrick: Okay. Welcome everyone.
Today's ebizQ Webinar in which we explore the latest trends
in SOA integration. I'm Joe McKendrick, author of
ebizQ's SOA in Action blog and an independent industry
analyst. You can also find me over at the ZDNet SOA blog site. You may
have seen some of my stuff there. I'm pleased to be joined
for this Webcast by Leif Davidsen, manager of WebSphere SOA Marketing
for IBM. Welcome Leif.
Leif Davidsen: Hi, Joe and thank you.
JM: And Leif, you're over at the
Hursley Park Labs for IBM, is that right in UK?
LD: Yes, the Hursley Park Labs home of
products like MQ, Message Broker, and of course, for many, many years
CICS, CICS Transaction Processor.
JM: Fantastic, the home of CICS, yes. And
today's Webinar is titled Identifying and Federating Today's
SOA Power Centers through Enterprise Service Buses and we'll
be reviewing these results of a new survey commissioned by IBM and
conducted by the analysts at ebizQ. You'll see my name as well as that of
Beth Gold-Bernstein, who played a project management role in the
survey.
The survey covered adoption rates within the middleware space
of SOA and Leif and I will be discussing the survey and providing
examples of implementations that Leif has seen among IBM customers. And
I also want to remind everyone that all attendees to the live session
will receive a copy of the survey results. And as our way of adding
value by coupling independent research with IBM's deep
expertise in this subject.
Okay. We're going to start off by discussing what we
mean by “enterprise service bus”. The exact meaning
and purpose of ESBs has generated quite a bit of disagreement and
confusion, if you will, across the industry over the past few years
since the term and the concept first came on the scene a few years
back. Typically, if you ask 20 analysts what an ESB is,
you'll get 20 answers and vendors also have their own
interpretations of what ESB means.
Now to many, you can't even take the first steps into SOA
enablement without an ESB to integrate various messaging and data
formats. To others, however, ESBs have a questionable role in the
organization. I've heard it compared to the human appendix --
saying that it serves some kind of mysterious temporary purpose
that's there as a result of some evolutionary cycle, but in
the long rule it's just taking up space and its painful to
have removed. I had an appendectomy back when I was a kid so I know how
disruptive that kind of removal can be.
Many vendors don't even call their ESBs solutions
ESBs. Often, you hear them called message brokers, integration
platforms or application servers. Up to a couple of years ago, if you
went up to the campus of a certain large software company in Redmond,
an enterprise service bus was that vehicle that got you around the
campus. Now, for purposes of this survey, since these definitions are
so fluid and often debated, we didn't want to limit our
responses because of labels so we went with an expanded definition
merging enterprise service buses, message brokers and integration
platforms into a single category.
Replay this Entire Webinar -- Complete with Viewable Slides
We also addressed ESBs as a term straight on as well. But this
combined product category, ESB service intermediaries encompass
solutions that serve to enable and prioritize the convergence of
messages in various formats into a standardized format. They provide a
platform that enable enterprises to coordinate security policy, and
quality of service, and process integrity polices.
Now Leif, why do exactly would an enterprise need an ESB?
Let's get to the heart of this. Isn't it possible to get started with Web services and SOA without a mediator in the
middle?
LD: Well, that's obviously a
question that many people come to when they start. Here
you are, you're a developer, and you are looking to create an IT
infrastructure problem and so you go and you code a solution to that
problem. And that's to be fair, that's been how
developers have gone after solutions to the problems that
businesses have been asking them to do for many years.
And that's when you get the sort of same type of
solution architectures that we see on the left-hand side of the chart
off up on the screen in a moment. You get this rat's nest of
architectures because while connecting, there's never a
problem connecting up two points; it's a simple straight
line. The issue comes when you're looking to connect up more
and more points and then you make changes.
What we've seen in IBM is the layers of complexity
just grow over time as people make changes to their business
applications. And that complexity does keep adding problems to the
business not only when it wants to make future changes, but in just
trying to do any regular maintenance to that. And of course, it means
that that processes become very hard bound, very inflexible, very rigid
and you know rigidity is bad for businesses in today's
business economy.
Get a Full Copy of the Survey Results
Now, if we look a little bit deeper at the picture
underneath this sort of rat's nest of how we want to actually
implement that nice flexible process we see on the right-hand side, we
can actually see the connections between application interfaces is the
real problem here. You got all this business logic that, obviously,
sits in your applications, and the applications are what is trying to
get to grips with your corporate data so that's actually
driving your business.
And because you got so many interconnected applications in
your business that have grown up with individual linkages, you get this
mess and enterprise service buses is there to address that. Now, going
back to your original question, do you need an enterprise service bus?
If you're starting with two Web services, clearly an ESB can
be seen as an overhead.
However, what an ESB does at its very heart is it provides a
dedicated piece of infrastructure to allow you to actually create all
of the connectivity definitions in a very managed and controlled way so
that even if you did have just two applications, you might well say,
well, it might be overkill but I know that I'm going to have
more than two applications, or I know that things are going to change
and therefore it's going to be more of a best practice to do
it in -- define any interfaces and any connectivity in an ESB because
then I know where it'll be, it'll be easy to find,
manage and maintain.
In the same way that if on writing a piece of code, do I need
an application server? Well, you might not think you do but in fact,
it's a useful piece of technology to have as you start to
apply it across your business. So I think we see that enterprise
service buses certainly have a place. Perhaps the appendix
doesn't it in the human body, but until we discover something
better an ESB today acts as a really strong way to logically define,
managed, and run the conductivity between both your services and your
non-services part for the business so handing back to you.
JM: Okay. Great, thanks. Well, in
order to find out exactly what kind are rat's nest exist out
there in enterprises and what they're doing to address these
problems, and the role of ESBs and integration brokers, or mediators
play in helping to address the situation, the ebizQs analyst including myself teamed up with IBM to
conduct a survey on this very issue.
The survey was fairly recently conducted during the month of
January. We had a 21-question online survey instrument that queried
respondents about SOA and their related messaging strategies. The
survey was promoted through to ebizQ members through the website, and
newsletters, e-mail blasts, and as a prize the
participants were had their names placed in a drawing to win an Apple
iPhone.
And in addition, all survey participants were promised the
copy of the survey results which the listeners out there will also be
receiving. And we had a total of 244 companies responding to the
survey. And just to give you a picture of who or what those companies
were like, we had a fairly broad cross section in terms of company
sizes. As you see on the chart here, we had a large chunk of companies
with more than a billion dollars in annual revenues.
We also had a sizeable part of our survey base consisting of
what may be considered small companies with less than $100 million a
year in annual revenues. Looking at the industry profile, this is a
pretty comprehensive chart but just to let you know what's on
there, we had a lot of involvement from financial services companies,
computer services in the industry also participated as we as insurance
companies, and manufacturers. A total of 33 industries had
participated.
And I'd also like to point out that a large group of
respondents were either management, or they were enterprise, or
software architects. Eighteen percent were enterprise architects, 12% software
architects, and 17% were from the business side of the equation,
business managers. Now this is encouraging since you often hear that
SOA is still too focused or concentrated on the IT side of the house,
and that the business really doesn't get SOA yet.
Next Webinar With Leif Davidsen: Using SOA for Maximum Reuse and Increased Business Agility:
Date/Time: April 9 at noon ET
Join Leif and his IBM colleague Jim Douglas as they review why companies should invest in maximizing their reuse of IT assets, how they can benefit from this across their business and throughout the investment lifecycle and what solutions to consider.
Click here to learn more register
The fact that close to one out five respondents were
executives or line of business managers and users, as I said, is an
encouraging sign that SOA is entering the mainstream, the corporate
mainstream. As I said, one of the things we're focusing on in
the survey is determining the overall state of SOA. We found that most
SOA efforts at this time are scattered across multiple business units
are project-based developments and integration teams.
We're going to go into that in a few seconds. And we
also found that it's still in the early days for SOA rollout
in businesses. As we'll show you later on, there's
a fragmented approach and lack of control. This makes sense given that
many early SOA efforts start at small pilot projects and proofs of
concept and we're still in the early days of the SOA dynamic.
And as SOA evolves over the longer term, we expect to see more -- the
issues around lack of control, the fragmentation around across
enterprise to become more problematic.
To read the rest of this transcript, sign in with your free ebizQ Gold Club membership below.

You must log in before accessing this content.