The question to ask in these situations is whether they are providing
redundant capabilities or not. It's a challenge inside the
enterprise to:
1) Actually take a capability-driven approach to infrastructure
selection.
2) Have the necessary communication, collaboration, and timing to
understand the set of capabilities that are right for the enterprise
versus one particular team.
The easiest scenario I can think of is security gateways versus XML
gateways/ESB/Serivce Network/Service Fabric/etc.. While there are
many products out there that do both, and do it well, if the security
team isn't talking to the integration team, you'll wind up with two
separate products. This may sound like a best-of-breed versus best-
fit discussion, but there are differences. This is more about buying
a product for a particular task, and then not leveraging the other
90% of its capabilities because it crosses into someone else's
domain, and the two groups don't communicate/collaborate well.
I don't want to make it sound like groups just need to start talking
(even though that's very true), because it is very difficult. There
are typically many things stacked against making these strategic
decisions, usually funding models and timing. If the security group
has money and the integration team doesn't, the deck is stacked
against the integration team. Likewise, if there's a project that is
under pressure to be completed in the next 6 months that has security
needs but could care less about the integration capabilities, again,
the deck is stacked against doing the right thing.
-tb
On Apr 5, 2007, at 8:59 PM, Anne Thomas Manes wrote:
Actually, from what I've seen, most organizations will have
multiple "ESBs". They use PI/XI for SAP integration. They use
BizTalk or webMethods for BPM. They might use Tibco or 29West for
high-performance requirements. And then they might get one of those
new-fangled ESB products for the simpler stuff.
On 05 Apr 2007 07:12:05 -0700, Todd Biske <[EMAIL PROTECTED]>
wrote:
I'll bite, but I won't call them DSBs. :) This all feels a lot
like Software Fortresses to me. In his book by that name, Roger
Sessions defined it as "a conglomerate of software systems serving
a common purpose and typically owned by a cohesive group of
individuals. These software systems work together in a tight trust
relationship to provide consistent and meaningful functionality to
a hostile outside world." While the term "hostile" may be a bit
strong, it is essentially about establishing ownership domains.
He goes on: "The walls of the fortress has are designed to prevent
any communications from coming into the fortress except through
approved channels. The approved channels are the drawbridges."
So, if you subscribe to this construct, you could easily have
several fortresses within an enterprise, such as along lines of
business. These fortresses thus become domains. If each domain
has the authority to do whatever they want inside their walls
(which, by the purist view of fortresses would be the case), then
you could have several ESBs that exist. An ESB clearly could be
the drawbridge for a fortress, and for a fortress that has many
services inside, you could even have internal ESB usage as well.
Certainly, a common pattern seen in enterprises is to have one
(logical) gateway (whether it's an ESB, XML appliance, whatever)
for external consumers, and another (logical) gateway for internal
consumers.
While I'll admit that there are cases where multiple internal
fortresses may make sense (for example, where compliance law
mandates a separation), I tend to prefer more centralized or
minimally, federated approaches. This doesn't prevent an
enterprise from having multiple domains, however, they are not
fortresses in the purist sense. There would still only be a
single, logical service bus/fabric/network, but implemented in a
federated fashion. What's interesting, though, is that the
infrastructure to do this federation is not implemented by ESB
technology, it's implemented by TCP/IP and DNS. If you have
multiple domains within your enterprise, each one of those is going
to have its own IPs, such as services.hr.foobar.com and
services.sales.foobar.com. It's the hostname that will get it to
the right "drawbridge." If you're doing registry/repository
lookups to get that endpoint hostname, you may have registry/
repository federation (just as we have with DNS), but not ESB
federation.
Pointing to the telco comment, my thoughts when I saw that quote
were simply that whoever that companies was needs some governance
around their technology spending. It doesn't make sense for a
company to have 5 different ESBs, and I assume that they meant 5
ESBs from 5 different vendors. Depending on their operational
structure, they could have 5 installations of one ESB based upon
operational management domains or deployment architecture. Unless
they recently purchased 5 smaller companies, each of which brought
their own ESB with them, someone in IT should have been stepping up
and saying, "we're all looking for the same capabilities, let's buy
one rather than five."
-tb
On Apr 5, 2007, at 7:59 AM, Gervas Douglas wrote:
No, it is not necessarily the favourite acronym of a dyslexic Aston
Martin owner. Here is an extract from an e-mail Miko kindly sent me:
"I'm seeing increased sophistication around lifecycle and federation
issues in Governance and some interesting insights about whether the
Enterprise Service Bus is truly a ubiquitous pattern or whether we
are
seeing the "Domain Service Bus" (DSB anyone?) winning the day. I
visited one telco that said, "we like ESBs so much that we have five
different ones!" This of course begs the question — which one is
actually the " Enterprise " Service Bus. The answer? None of them!!!
Five ESB products and no ESB. This is much more common than you would
think. I'm happy to chat about this observation if you're curious."
I guess there is a natural hierarchy of confusion with these buses.
Would someone like to take up Miko´s invitation to chat about DSBs in
this forum?
Gervas
Yahoo! Groups Links
(Yahoo! ID required)
[EMAIL PROTECTED]
