{"id":658,"date":"2016-04-19T19:39:19","date_gmt":"2016-04-19T19:39:19","guid":{"rendered":"http:\/\/adriangrigoras.com\/blog\/?p=658"},"modified":"2016-04-19T19:39:19","modified_gmt":"2016-04-19T19:39:19","slug":"esb-esb","status":"publish","type":"post","link":"https:\/\/adriangrigoras.com\/blog\/esb-esb\/","title":{"rendered":"To ESB or not to ESB"},"content":{"rendered":"

Many of us have had to ponder this question. Technology selection is notoriously difficult in the enterprise space since the criteria and complexity of the problem is often not fully understood until later in the development process.<\/span>
\nThere is an interesting post from ThoughtWorker Erik D\u00f6rnenburg with the unfortunate title \u201cMaking the ESB pain Visible<\/a>\u201d. Erik provides a real-world example of when not to use an ESB<\/a> citing that \u2013<\/p>\n

\u201cBased on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced \u201cnothing but pain.\u201d But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect\u2019s dream, developer\u2019s nightmare?\u201d<\/p><\/blockquote>\n

Later, Erik quite rightly points out that an ESB<\/a> architecture\u00a0should not have been used in this scenario. This is a fairly common problem for ESBs and enterprise technology like BPM\/BPEL where the technology is not chosen for the right reasons and then the technology gets blamed when the project struggles. Given that much of the enterprise software disillusionment today stems from the incorrect usage of the technology I thought I\u2019d offer some rough guidelines for selecting an ESB architecture.<\/p>\n

ESB selection checklist<\/h3>\n

Mule and other ESBs offer real value in scenarios where there are at least a few integration points or at least 3 applications to integrate. They are also well suited to scenarios where loose coupling, scalability and robustness are required.
\nHere is a quick ESB selection checklist \u2013<\/p>\n

    \n
  1. Are you integrating 3 or more applications\/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.<\/li>\n
  2. Will you really need to plug in more applications in the future? Try and avoid YNNI in your architecture. It\u2019s better to keep things simple re-architect later if needed.<\/li>\n
  3. Do you need to use more than one type of communication protocol? If you are just using HTTP\/Web Services or just JMS, you\u2019re not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.<\/li>\n
  4. Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? Many applications do not need these capabilities.<\/li>\n
  5. Do you need to publish services for consumption by other applications? This is a good fit for Mule as it provides a robust and scalable service container, but in Erik\u2019s use case all they needed was an HTTP client from their front-end Struts application.<\/li>\n
  6. Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down in to smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.<\/li>\n
  7. Do you really need the scalability of an ESB? It\u2019s very easy to over-architect scalability requirements of an application. Mule scales down as well as up making it a popular choice for \u2018building in\u2019 scalability. However, there is a price to be paid for this since you are adding a new technology to the architecture.<\/li>\n
  8. Do you understand exactly what you want to achieve with your architecture? Vendors often draw an ESB as a box in the middle with lots of applications hanging off it. In reality, it does not work like that. There is a lot details that need to be understood first around the integration points, protocols, data formats, IT infrastructure, security etc. Starting small helps to keep the scope of the problem manageable and keep the fuckupery to a minimum. Until you understand your architecture and scope it properly you can\u2019t really make a decision as to whether an ESB is right for you.<\/li>\n
  9. Generally, always validate a product solution for your needs. Don\u2019t choose an ESB or any other technology because \u2013\n