Skip to content

Rationale & Advantages

Jump to bottom
assimbly edited this page Jul 3, 2018 · 29 revisions

Logic get you from A to B, imagination get you everywhere (Einstein)

Background

When you want to integrate two systems, you soon find out that integration was an afterthought. This is because applications are designed with one main function in mind. For example an application created for customer relation management is designed around managing customers.

The designer creates a datamodel that matches exactly the needed business functionality. All technological components like the database and code are derived from this main function. Mostly the focus is on one interface: The user interface.

This is all logical, but what if another application needs some customer related data as well?

When it's still easy...

A webshop has another function with other business needs. That's why its data model is completely different than that of the CRM system. Now both have no well defined data interface, so how do we exchange data?

What mostly is done that in one of the applications some custom module is created. This module acts as a bridge between two data models. Another aspect is that the data needs to be transported from one application to another. In this case the CRM could have a daily export to directory (a fileshare on the webshop server). The custom module of the webshop can now import the exported data into its database.

So one custom module needs to be created, so what the problem?

More posibillities

Now we have two systems and one type of message. What when there is another system that manage data like articles and prices. This data should also go to the webshop. But there is also a warehouse management system that needs this data. And the webshop orders should go to warehouse management system and update customer data should go back to the CRM system. All of these data should be sent to an analytics platform. With every messagetype, every system, more possibilities arrise. In the first example we have only one flow, but in second example we already have 11 flows.

More systems, more message types mean more possible flows. It's impossible (and just too much work) to create custom modules every time. Besides using file shares aren't safe and don't scale.

Middleware platform

To have one way of exchanging data we let all flows pass through a middleware platform. This platform can route the data and transform the data to the datamodel of the consuming application. Now we don't need

  1. custom code in the application

and

  1. we only need to connect to one middleware platform.

In practice

In practice a lot of applications have no or only one way to connect to the outside world. This can be SFTP, a database table, a webservice, a broker and so on. There also can be numerous way to connect to the middleware platform. If for example a broker used, it can be a MQTT broker, a JMS Broker, a Pub-Sub Broker, an AMQP broker and so on. The way to connect also depends on the specific implementation of that technology.

It's almost impossible to support all kind of protocols and technologies (that may not even exist). There are fortunately several projects which focus on connecting these technologies. In the Java world, most common are Sprint Integration and Apache Camel. They solve data integration problems one a data and on a infrastructural level.

Assimbly gateway

Ways to connect

Even when using these integration frameworks to bridge the gap between systems things can get out of control and you can still code a lot. And even when you have central middleware platform there are many way to get the data from and to the platform. For example:

 - A module directly into the application which handles integration
 - A service (webservice or ESB service)
 - A script
 - A programm (for example based on Apache Camel)
 - An adapter

Maybe some components support multiple ways of connecting, the end result are multiple ways to connect, spread over the entire application landscape. Each component is configured and managed separately.

Pain

  1. Multiple ways of connecting
  2. Integrating module can only be accessed from a server or a application
  3. No oversight of what integrating modules are running
  4. No oversight of what the version of the integration modules are running
  5. No statistics
  6. Connections are not fault tolerant
  7. Every new technology is customization
  8. Not accesable through the browser
  9. Works only with a specific technology (Application, middleware, OS)
  10. Is not open source
  11. Is outdated
  12. Is configured manually (=time consuming)
  13. Is configured manually (=error phrone)
  14. Doesn't work continuously (Scheduling hell)
  15. Can't access remote
  16. Doesn't have user management
  17. Who was stopping that flow (audit management)
  18. Doesn't scale (multiple modules for a few integrations).
  19. Isn't flexible (needs customization)
  20. Say no, because technology/protocol isn't supported
  21. Expert needs to configure the connection
  22. Connector only works with a few technologies.
  23. You need to go the server, to view and edit configuration
  24. You need to have access, to configure and manage connections
  25. You can't migrate to another integration platform (connector only works with this one).
  26. It brakes, because not based on proven technology.
  27. Can't support Business or Project (not extensible)
  28. Need to pay for licences
  29. Need to pay for hardware
  30. No browser support
  31. You need to code
  32. No central management
  33. You need to configure it in an IDE and then deploy it.
  34. Can't switch to another application
  35. Can't switch to another broker
  36. Can't switch to another ESB
  37. Migrations need to go in one big bang.
  38. Hard to add customization
  39. Dependent on supplier
  40. No transparancy in developement
  41. You need to per core / cpu
  42. No active community
  43. You need to choose between on premisse or cloud.
  44. It only works on Windows or Linux.
  45. Multiple ways to connect
  46. Connection load is on one server.
  47. Not modular.
  48. No API's available
  49. No separate of concerns
  50. No input validation (mistakes)
  51. Custom connector only the basic work, but what about scalability, fault tolerance, security and overview?
  52. This new technology isn't support by our integrtion module.
  53. This custom code is dependent on one guy.
  54. To many ways to connect
  55. Spaghetti of connections
  56. No central management
  57. No oversight
  58. Can only run one flow/ one connection
  59. No access/User Management/Audits (Who can do what)
  60. No support
  61. Not extensisble
  62. No business enablement, because connecting is everytime different, reinventing the wheel, multiple ways.
  63. Only works on machine in desktop software or console. Not from browser.
  64. Dependent on vendor/Works only with
  65. Dependent on platform/Works only with
Tables Are Cool
col 3 is right-aligned $1600
col 2 is centered $12
zebra stripes are neat $1
....

One way to connect

No matter how you're integration is setup, Assimbly acts as one way to connect application to the preferred integration in a reliable and easy way. You're not dependent on that way. For example when changing the broker you can change gateway to connect to that broker.

Gain

Well the opposite of the pain point :).

Clone this wiki locally