How to Get to Integrated Enterprise Systems Integration Valhalla [For Developers]


Are you a developer tasked with creating a complex integrated enterprise system? Overwhelmed? Wondering where to start? Read on.

 

The Mission:

It’s 3:30pm in a fluorescent-coated conference room, and you’ve just been asked by your manager to lead the integration of two complex management systems to meet a multitude of business processes dictated by the client. Congratulations! It shows a great deal of respect that you, merely a developer of code and pernicious Jolly Rancher addict, have been tasked with the responsibility of officiating the union between two systems so deeply in love that they have chosen to spend 24 hours a day, 7 days a week, and 365 days a year awake, sans sleep, constantly talking with one another. Like seriously, if they are prevented from missing even a millisecond of what the other one says, they’ll both whine incessantly and send you emails marked with high importance and titled with boring yet informative Subject Lines like “I’m down! Connection timed out! HELP!” until you re-establish their communication line with one another.

OK, so maybe the content management system and association management system don’t really feel attraction to one another (but who are we to judge?). And the ERP <-> web database connection might be devoid of passion save their titillating and incessant back and forth discussions. But that doesn’t diminish the importance of what you’ve been asked to do: Set up a lasting connection between two massive systems that keeps them passing information back and forth during the entire open hours of the Internet: All day, every day.

Despite the tremendous responsibility just deposited on your shoulders, you merely look up from your notes, catch eye contact with the Bossman, and confidently express your ability to get this integration completed within the scope and budget. Your boss nods, thanks you, passes down a document that describes the required timeline, and proceeds with the project description. You look down at your paper and return to note-taking.

What gave you the confidence to express with such insouciance that you would be able to get this integration done? You’ve barely looked into it and even your manager (he’s one of those guys that underquotes things to a dreadful degree) said it was complex. Even a couple of your colleagues are a bit stunned, but they eventually shrug and continue listening. If they were to look at your paper right now, they’d see a freshly-written phrase that denotes the reason behind your sense of tranquility: “The Intrepid Commandments of Integration Valhalla”. Overarching plan firmly in hand, you sit back, you’re your Cola, and keep listening to the presentation. The Commandments that you’ll follow in this integration are as follows:

 

1. Keep a log of all passed and returned parameters that occur in every transaction. Be thorough like Captain Picard, and never forget the Stardate in your Captain’s Log.

 

It’s vitally important to keep a record of all data passed back and forth between each of the systems involved in your integration. If something does not go as planned in a development or production environment, there must be a place where the situation in question can be revisited and analyzed. Store any data sent to a system and any data retrieved from a system. Store a record of what is done with retrieved data. If the data goes through particular checkpoints where data variables change, store data for those checkpoints as well. This will significantly decrease debugging time. One final tip here: Make sure to set up an automatic deletion of old logs. Good log data multiplies as quickly as well-fed Tribbles.

 

2. Resist the temptation to build from scratch – but don’t hesitate if these two systems have never met in a previous life.

We coders have all experienced this temptation. Excitement that arises from a new project manifests itself in a desire to begin coding whole sets of functions and classes immediately, with blatant disregard for other people’s previous work and how it might be usefully extended. Check around and see if similar integrations exist. If they do exist in the language of your choice, exclaim “Hooray!” and go from there. And even if one or more integrations exist in other languages, examine them for tips to see if they work as you think they would. And if no integration has been attempted (that you can find), then get out your map, plan a great route, put on your Safari Hat, and venture into the unknown to create a purposeful product for your client that’s never been done before.

 

3. Each API involved in the integration is not just a casual acquaintance, but an old and wise Sensei. Be the Danielsan to its Mr. Miyagi.

An API is extremely important to any integration project. It is the communication vessel for obtaining and retrieving data from a given system. At the beginning of any integration project, you should obtain the API documentation, WSDL, and example code. Then study it. Understand exactly how it is built and what it can do. Determine how it will be involved in each of your requirements, and what calls will need to be made. Make mental notes of the functions you aren’t using, at least one of them will come in handle later in the integration.

 

4. If no API or web service connection exists, seriously consider the possibility of migrating to a new system. Stodgy systems and modern web are oil and water. They don’t mix.

If one of the to-be-integrated systems has no API or no way to integrate with it through a web service, you have two tangible options:

  1. Talk to the system’s developer and discuss the web services that you need to complete the integration. Find out what it will take to build them and if the client accepts this.
  2. Talk to the client and discuss all possibilities for migration to a new, more web friendly system.

Any system integration is meant to simplify and streamline one or more processes. That is done by fostering communication between systems. If there is no way to conduct communication between systems, then you’re in quite a pickle. The best option here is to fight for an API at all costs.

(Some will rightly argue that other options exist that do not involve direct data transfer over a web service. One example would be setting up an export of data from system A’s end, SFTP’ing that data to a server, then consuming it into system B. While options like this do exist, they should be used as an utmost last resort. All data transfer should be web friendly. Don’t let your client get trapped by an antiquated system that will soon be gone, just like the DoDo’s Myspace account.)

 

5. Write a splendiferous plan.

After you have gathered all of your information, document it well. Write paragraphs, not sentences. Describe how you intend to implement each piece of the integration. Important pieces of data include the API calls to be used, how the calls meet each requirement, the data that will be passed back and forth, and expected results of every transaction. You’ll be so happy with “Past You” at about the 70% completion mark, when the memories of the beginning of the project are pretty hazy and you really need to remember exactly how you implemented a very important piece of functionality a couple months ago. Don’t be lazy. Write a splendiferous plan (it’s so important I used that awesome fake word twice!).

These five principles should drive any integration project. They ensure that the integration is built to last with a strong, well-planned foundation. Thanks to these five Intrepid Commandments, you are empowered with the ability to lead these two great systems into holy matrimony, into the promised land of Integration Valhalla. If you have questions or would like to share additional tips, contact Unleashed Technologies today, or leave a comment below.