Application Integration Strategy for 2013 and beyond

Hola! Happy New Year to all of you!! Have you made any new year resolutions? Not the personal types like doing a set of 100 push-ups or cleaning up your carpet or doing the latter while doing the former! I was thinking more of the corporate variety a la goals / objectives for 2013 for your organization. If you haven’t quite figured those out yet, I have just one that I would like to recommend.

In this day of high-speed growth and scale, organizations need to be prepared with a plan to keep up with such changes. In a matter of mere days, new hardware infrastructures are prescribed and acquired. Public and private clouds make it even easier to setup such infrastructures. CIOs are adding new SaaS applications by the dozens and retiring existing legacy applications. All these changes mean only one thing for the IT manager – Insomnia! But, it need not be. Here is my one key recommendation to plan for high-speed growth and scale in 2013 –

Build an application integration strategy TODAY, if you already don’t have one

Before I go on to explain how you build one, let me quickly tell you why this is important. Without an application integration strategy, you will keep on building point-to-point connections between systems. This only leads to more chaos and any change in this architecture only means high expenses for time and resources. The most successful and highly-performing organizations definitely have a good application integration strategy in place.

There are 5 basic things that you need to consider when thinking of an application integration strategy –

  1. Start with the fundamentals – Setup an ICC (Integration Competency Center). Some of you may groan at this suggestion but I have seen this as a highly productive investment of time and effort in building a company’s integration strategy. Without appropriate governance, anyone with an idea will adopt their own integration methodology and soon, you will end up with a similar situation of point-to-point connectivity or even worse, disconnected silos. Ken Vollmer from Forrester has written a fantastic article on how ICCs help solve integration complexity.
  2. The best way to connect systems is to disconnect – As silly as it may sound, the best advice you can get on this is to create a decoupled architecture. By tightly binding data and applications silos with one another, you are only complicating the architecture more. A decoupled architecture is one where one application is agnostic of another application’s presence or preference of connectivity. For example, if you have to send a piece of data from your ERP into Siebel, the ERP can fire the message onto an Enterprise Service Bus (ESB) and forget about it. Siebel will receive that message if it has subscribed to that message topic. This architecture is also known as pub-sub or Publish-Subscribe. This is immensely helpful because, tomorrow, if Siebel gets replaced with (SFDC), no code needs to be rewritten. The ERP will still fire the message the same way. However, SFDC will now subscribe to the message topic now. As is evident, this architecture allows for greater flexibility, scalability and higher developer productivity.
  3. If you are not re-using…that would be amusing – Definitely think SOA (Service-Oriented Architecture) when building upon an application integration strategy. SOA allows for maximum re-use when building your integration logic. This means less resources and more available time for other projects.
  4. Think canonicals – This is one of my pet peeves that developers or even architects do not think about using canonicals when building upon an integration strategy. Canonicals are fantastic models to be leveraged to create extensible integrations between two or more complex applications. When you are dealing with two or more complex or large data structures, you will see that you are spending a good chunk of time in mapping the same set of fields or writing custom logic to same field that is named in different ways in different data sets (e.g. FirstName, FName, Name, CustomerName etc). Canonical will act as the flat representation of the superset of all data fields in your integrations. Applications will then connect to the canonical instead of creating new data structures every time they need to be connected with a new system. System-level changes can be easily accommodated with this approach.
  5. Use design patterns – One solution does not fit all. If you are an architect, you probably already know what I am going to say in this section. I have seen companies with large IT development teams building integrations with absolutely no design pattern in mind. That is so wrong! Design patterns are established blueprints for success. If you have complex data exchange needs, you need to know for sure what design patterns you are going to use. Design patterns help in reducing complexity and in boosting performance of your integrations.

With that, I want to wish you all a healthy and happy new year!! As you read in my other post, 2013 is the year of application integration. So, be prepared and create an integration strategy. Go on! Connect the world now!! :-)

About Dinesh Chandrasekhar

Dinesh Chandrasekhar has written 27 posts in this blog.

Dinesh Chandrasekhar has more than 16+ years experience in Application Architecture, Integration and Implementation across multiple industry verticals. He has special interest in on-premise / cloud integration, iPaaS solutions, high-speed messaging and solving complex integration problems. He is currently a Sr. Manager of Global Product Marketing at Software AG, responsible for the Application Integration product line.


  • “…if Siebel gets replaced with (SFDC), no code needs to be rewritten…” Really?

    For starters, code will have to be written to take data out of and mapped to this “canonical.” Add to it the fact that SFDC may not have fields that Siebel used to have, validation changes, etc and you end up with making changes.

  • Hi Arpan, thanks for your comment. Let me add some clarity here. I do not deny that the changes you have suggested are necessary but they need not be code-level changes. It all depends on the efficiency of your ESB / Integration middleware. I speak from experience of having done this and demonstrated the ease of such plug-and-play type capability of an ESB. Getting data out of SFDC should be an adapter service, which is created with four mouse-clicks within a wizard. Mapping is very much a visual exercise and no code is needed there as well. As for fields not being available etc, that is where the canonical model should help. However, I do not deny that this will be the case with all such mappings. There may be cases where you may have to add some transformational logic. However, I again emphasize that if you had architected your decoupled architecture well with the correct level of service orientation, this should be far easier than having to code everything all over again…for a new endpoint!

  • “CIOs are adding new SaaS applications by the dozens” – exactly so Dinesh. And what I feel is, SaaS application’s ‘pay-as-you-go’ model is making applications and solutions much more affordable than ever. The trend of SaaS adoption that we see today would create a web of SaaS applications with in an organisation creating complete chaos in the Integration layer , similar to what we had for on-premise applications during early 90’s, if points mentioned by you are not taken care. I think this is would only make ‘Integration’ more and more meaningful and coveted. Integration still remains a perennial/continuous activity.

  • Hi Dinesh and everyone else – who within the organization should be responsible for developing and implementing an application strategy? Is this one in the same? Who are all the stakeholders?

    • This depends purely on the culture of the organization. Most commonly, it is driven by the Architecture group or an ICC body. In some organizations, a well informed CIO can also dictate this strategy. However, the stakeholders in this decision are way too many since it affects every one including members from the business units. So, typically, the stakeholders will include application owners, architects, IT managers, ICC members etc.

Leave a Reply