Stuck in the Middleware with you.

 

ARGH - now what is middleware?

Relax. This one is easy - middleware is software that is placed between two systems (ie. in the middle).

Ok so what is it doing there? The simple answer is Middleware is facilitating. Take the following analogy:

You seat yourself, along with your friends/family at a table in a restaurant. Your goal is to get food from the kitchen onto your table. You achieve this objective by speaking with a waitress. Her name: Middleware. As a customer, you look to Middleware for information on kitchen contents, capabilities and specialties.  Middleware can speak customer (smiles and prompt service) and can also speak 'kitchen' (clear, concise and demanding). Middleware will go to the kitchen to convey your orders and return the result (your food) and to the correct recipient. Should you require more food, have a complaint or even a compliment, middleware can pass on your message - That’s her job. 

Software is very similar, you have two (2) disparate groups (Customer/Cook or ERP/CRM) that need to 'talk'. You need a translator, facilitator, you need middleware! Middleware will speak both languages and communicate those messages to the other party (check out my post: "Psst! I have something to share...EAI"). The messages can be between related or unrelated systems - all that matters is a need to share some information.

Give me some - I'm sold

Ok so where do you get it? The answer: it depends. There are a lot of third party vendors that offer various middleware solutions such as those offered by Microsoft ( BizTalk ), IBM and SAP. Let talk about BizTalk for a second, "BizTalk enables your organization to seamlessly integrate disparate systems and connect business partners ".  In english, here’s a picture:

What this is showing is the waitress/middleware as BizTalk Server and the customers as, for example, Inventory Application. The middleware communicates with the inventory app and passes on the request to the kitchen (ERP). Ultimately this communication results in fulfillment :D

To sum it up - middleware provides a common platform where messages can be exchanged between two systems as to share information that would not have otherwise been possible.

Hope this helps and not hinders, Enjoy!

Psst! I have something to share….EAI

When two people have to share information there is a set of steps that need to be followed. For one, there needs to be a message and preferably worth hearing. This message is then sent to a another person who listens, filters out noise and interprets the message - if necessary, a response is sent.  This is the basis for simple communication. We all do it - daily. For those of us that don't - there is a picture, the 'Shannon Diagram' or 'Schematic Diagram of a General Communication System'.  The interaction between complex enterprise systems are no more difficult to understand as a simple conversation between two people.

EAI = Enterprise Application Integration

Enterprise systems are no different then people - in the case of the IBM Watson computer, they are people too!  They want to talk. In order for them to talk, they need to share messages/information. This information needs to be cleansed (see scrubbing and de-dup below) , transmitted (ODBC, Web services, CSV, XML etc.) and received by the destination system.

Click here for more on Watson

Sound Simple? Well it is - almost...

From a security, content and technical aspect,  make sure all parties are on side with the transmission of data  as this is where the project difficulties usually lie. Complications in expectations can and will occur. As the project manager, you will need to identify all shareholders that 'own' the data and systems involved in the transmission. This will assist in mitigating any risk that your team(s) will rely on incorrect definitions or encounter roadblocks (ie Legal).  Another complication arises in complexity of the discussion between systems - will the communication between two systems be Unidirectional or Bidirectional (round-trip). The difference?

Unidirectional is like a dictator forcing its data onto the other system (easier).

Bidirectional - this is a conversation between two systems - issues such as timing (real-time, nightly, weekly etc) and data ownership come into play. Both systems will be required to import and transmit the required shared data in the same way (ODBC, Web services, CSV, XML etc.).

Spend some time and get this process right the first time! And for the love of <Insert Deity Here>  don't skimp on testing.

Scrubbing / data cleanse

Before you send a message, take the time to ensure it makes sense. This is why we 'scrub' data. Cleansing is referring to identifying crucial records/data, duplicates, merging records, updating key data, and resolving data issues. We clean it up so where ever we send it, the information will make sense. Don't kid yourself - if you are undertaking a data scrubbing exercise, it'll be a manual boring and grueling job that only those most familiar to the data can really do well. Sure you can get the contractor to write a query, perform magic/voodoo; however, the data will not be a complete, thorough and accurate unless you have the right people taking the time to cleanse (not purge) the data.

De-dup it

I hate the term - hate it. But. It is actually widely used so you'll need to be familiar - it just means de-duplicate or to remove duplicates. I prefer the term: singularity-ify (thank-you Star Trek :P )- ok so "de-dup" is better - for now.

Booyah - you're knees deep into a EAI discussion now!

Ok let's review - you've identified the Enterprise Applications that require Integration, the data to be shared and all the parties that could be effected. Next, the team identifies what is to be shared and how. This step will determine how much scrubbing, cleansing and de-duping is required. Finally, the process of communication between two systems will it be Unidirectional or Bidirectional (round-trip).

The Checklist

1. Is there a real need?
2. For whom (get the parties in at ground zero)
3. What is to be transmitted (be thorough)
4. How - think this through
5. Prep - clean up the data
6. TEST TEST TEST
7. TRAIN - give your team a fair chance
8. How did it go? (post-mortem)

Hope this helps and not hinders, Enjoy!