So you need to connect an application to an external system. Developers and IT architects know how to cover the technical side, with for example SOAP web services, REST APIs, or stored procedures. But there is more to integration than just a choice in technology. You also face a functional challenge: the relevant functionalities of multiple applications must seamlessly fit into each other.
In most application landscapes services tend to pop up like mushrooms, with little to no attention being devoted to decent service design or decent service-oriented architecture (SOA). Frankly put, this means you’re doing it wrong.
The world around us is moving at an ever faster pace and disrupting forces for your market are lurking around the corner.
Does the term "rewrite" scare the bejeezus out of you? Good. It should. A rewrite is not something to be taken lightly and should be your very last resort. There are less painful routes you can take, but what if there really is no valid alternative to "The Big R"?
In the last 5 years of my career as an enterprise architect, whenever the word "integration" came up, discussions started about the choice of an ESB (Enterprise Service Bus), SOA (Service Oriented Architecture), FTP or web services, SOAP or REST, XML or JSON, etc.
In short, when involved in discussions about "integration", one most likely finds himself drowning in a multitude of technical acronyms and technological standards.
I compare the technological side of integration to the "Dr. Jekyll" personality : it is the side well-known to everyone, stable, under control and increasingly complying to uniform standards.