3 More Antiquated Ideas About Data Integration



Its really amazing today, everybody is writing blog articles highlighting the 8 signs your system sucks, or the 4 questions the CIO needs to ask, or the 6 things you should do to improve your blah, blah, blah. Multiples of two seem to be magic numbers for the online punters. Now I’m not into numerology so maybe I am overlooking something, but it strikes me that people are no longer thinking. Rather what are being produced are bursts of inspirational nonsense.  Verbal diarrhea. The punters are producing and we are digesting pieces of information largely without context and without much thought to real world application. Of course there are exceptions.

Ok, so I know I am about to get slammed and flamed so hear me out. Think about it for a moment.  How many blog articles have you skimmed, I won’t use the word read as that implies thought, recently that really told you nothing. They were words with random ideas thrown together? It’s almost as if people are producing content for the sake of content and not much more. Got to be social.

In my mind, content should be provocative, force one to think, leaving you feeling like you need and want to know more. It’s similar to what Joni Mitchell says if you can’t feel something from the music and the lyrics you aren’t really listening. The same goes for content, if you don’t understand the subject and the baggage you carry (your interpretation) clouds your view then why write about it? So you are probably wondering what in the name of pink flamingoes and plastic garden gnomes does this have to do with integration, e-commerce and the cloud?

Well, the exact same lack of understanding exists when it comes to integration. This lack of understanding is both holding companies back and impacting the way they interact with their customers and their trading partners in their supply chain.  What do I mean?

Nathan Camp of Liaison Technologies, in our last blog article, highlighted three antiquated ideas about integration; ideas from another world that persist, so here are three more to add fuel to the summer campfire.

I don’t need your data translator or your middleware solution because my web/cloud based EDI service provider will do the translation for me.

What? Wrong, wrong and wrong. Your service provider might provide you with a file in a standardized format but the data won’t be in the format that your internal system wants to see. So guess what? You will have to do data translation and guess what, you will need a translator. They will also offer to do the translation for you and before you know it…. Ka-ching, ka-ching.  Yes, you’ll be spending big time.  You may also find out they only do certain types of document translation. Now what do you do? Far simpler, buy a data translation and data routing tool, aka middleware. Do it yourself rather than relying on an outside service that only partially does the job. But peel back the onion because your service provider may not handle multiple file types. They may just handle EDI. Don’t fall for the single silo solution, the world has moved beyond silos.

My Application Provider has an EDI system already built in.

OK, so this one is similar to Nathan’s One Vendor – One Solution, but with a twist. Yes, sure your Application Provider can do EDI, but do they do all transactions you need to support? Dig a little deeper and does their solution use the data dictionaries of the ANSIX12 or UN/EDIFACT Standards or do they just code the resemblance of an EDI transaction? Ok so I am being a little technical here but if you are going to do standards based EDI then you have to do it properly and that means respecting the standards.  But the irony of this type of old school approach is that they have locked you into their level of expertise, which may be rather slim. Not sure I would want to place my trading partner connections in the hands of people with limited expertise. Best to look for an application that has an API or a standardized way of getting data in and out. Now that’s New School. Is it time for the Old School to graduate?

We don’t have an EDI implementation guide or an XML document send us your specifications and we’ll code to them.

Say what? Can you please repeat. Yes, send us your specs and we’ll code to those. OK, this is a company trying to be super flexible but with out realizing that this approach is adding costs and time delays to their customer onboarding process. This is pretty much standard operating procedure with lot of 3PL/Logistics companies and is great if every company that comes along has specs, but I will put a wager on the table that most don’t.  Logistics companies are far better off defining how they want to handle data from their customers and have that data format identified and laid out. Nothing against being flexible and customer focused but don’t limit your approach.  I am also going to put another wager on the table, how many 3PLs can quantify how many customers they have lost because of that super flexible approach? Wow, I know I was in Vegas in April but this is getting a little much for me, the non-gambler. But seriously by not having specs means you might have lost as much as you did the last time you played the craps table at Vegas. Give it some thought.

So that’s it, that’s all for the summer campfire discussion on antiquated integration ideas. Between Nathan Camp and myself we have come up with six antiquated ideas. Hey, that number is divisible by two, and yes they are random ideas thrown together. I hope we have given you some things to chew on and think about. The six ideas reflect real world situations that consumers of integration products and services face on a daily basis

Need more inspirational summer reading? Check out our ebooks.