The last word on EA and ESB. I’m getting a number of e-mails about this whole ESB/Architecture thing, and a number of good responding posts. Just backing up a bit, there are two issues here really. First, that there is a lack of architectural forethought within most enterprises. Second, that ESBs are perhaps overused, overhyped, and are in many cases not a good fit for an SOA. Let’s take these in reverse order. The ESB thing I think most of those responding to me get the fact that ESB are perhaps overused, and thus could lead to bad architecture (the next issue). Just as a follow-up to my last post, Joe McKendrick posted a poll around this issue. The poll was entitled: “Are ESBs an effective platform for SOA?” At the time of this blog post, Joe had 51 responses distributed as follows: It doesn’t really matter — SOA should be oblivious to underlying technology (43 percent) No, they create costly messes (29 percent) Yes, they provide a ready solution (24 percent) Other — add your comments to TalkBack (4 percent) Total Votes: 51 I expected that most would agree that “SOA should be oblivious to the underlying technology.” However, I was very surprised by the number of people who responded that “No, they create a costly mess.” Perhaps things are worse than I thought. Again, ESBs are not evil. I think they make sense in certain circumstances. What I am saying is that they have a tendency to be found within components of the architecture where they don’t belong. Although all ESBs are not the same, generally speaking they have a tendency to be too information-oriented, and they are typically repurposed messaging systems with services interfaces built on top of them. Thus, some ESBs have issues with how they deal with true service behavior, and really are just service-oriented message brokers when you get right down to it. However, in some instance, your architecture may need a service-oriented message broker, or an ESB. That needs to be within the context of a much larger architectural plan, though. Which is my next point. The enterprise architecture thing I did get some cogent pushback from some thought leaders out there including Neil Ward-Dutton’s resent post, accusing me of “link baiting.” Putting that aside, he made some good points. “The most charitable explanation I can come up with for David’s position is that he believes passionately in the transformational power of enterprise architecture. The problem with this perspective is that even where EA is highly effective (and in many places it isn’t), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector.” I think I agree with most of this. In essence what Neil is saying is that generally speaking, EA is not highly effective, typically, thus dream on if you’re looking for centralized and effective leadership around getting in front of these IT architecture issues because the forces against that are overwhelming. My take, perhaps not Neil’s. The core issue here is leadership, within enterprise architecture and beyond. The entire executive team should be involved in making sure that a core plan is both created and followed, and that you don’t end up with a situation where you have to keep hacking and patching, which is what most enterprises are doing today. Stop the wasted motion and get a plan in place that works for the business, and execute the plan. It will not be perfect, but we have to get better at leveraging our IT assets in support of the business. For now, it seems that many are dealing with messes, and consider that behavior “just fine.” I don’t accept that. Software Development