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 –
- 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.
- 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 Salesforce.com (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.
- 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.
- 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.
- 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!!