The Illusion of Pre-Built Adapters

Why do people continue to fall for the idea of "pre-built" adapters? I guess that's pretty obvious. Anything you really want to believe in, you can. Unfortunately, it doesn’t follow that believing in something makes it so.

Dick: Ok, guys, have you figured out how we're going to get this Salesforce/SAP integration done in time for me to meet the VP's deadline?

Harry: I've been online all week studying the possibilities. I saw Adapters from three companies that look really good.

Dick: Come on, we've been down this road before.

Harry: Right, but things have changed! The latest Adapters work immediately off the shelf! Let me show you the videos on the one that looks like it has the most customers… (beep .. "Hello - Welcome to Something SOA Great's web site. I am about to show you the latest thing since…")

 Harry and Dick watch, enthralled. Tom stands behind them with a frown, rolling his eyes.

Dick: If I hadn't seen it, I wouldn't believe it.

 Tom: Hmm. I've seen it and I don’t believe it.

 Harry: Don’t be obstructionist. You just saw that SSG's Adapter automatically connected to both Salesforce and SAP. All the mapping is already built in, so we don't have to even know what the data fields are. You know what that means - we don’t have to deal with those know-it-all data analysts.

 Dick: We could just download it and be off to the races to make the deadline with time to spare. 

Tom: And what if we need to use custom field in Salesforce?

 Harry: Didn't you see that they have 10,000 Adapters in their library? And fifty different versions of this one, so we can look for the closest fit. Then we can tweak it just a little bit to fit what we need. They said they have tools for that.

 Dick: Let's do it!
 

Tom: I need a vacation. Have fun.

So Harry downloaded the Adapter to his desktop.

Harry: Here we go! I'll install here and get it up and running.

 Adapter: /very faint chuckle/

 Harry doesn’t hear. He’s reading the on-screen instructions.

Harry: OK, I'm connecting to SAP

 Two weeks later

Harry: Now I'm connecting to Salesforce…

 Two weeks later

Harry: I think I'm going crazy. I keep hearing this noise that's getting louder every day. But I digress. Here we go - let me try running this beast.

 Adapter: BANG! CRASH ! HA! HA! HA! /hysterical laughter that can be heard all the way to the VP's office/
 
Tom is back from a month’s vacation overseas; He runs to Harry’s cube to see what's going on.

Tom: AARGH! What's going on here? .. Oh, no! The Adapter is squirting SAP data out the port all over the desk!

Dick: /loudly/ Not again! Everyone to their stations! Call 911! Call the auditors! Call OSHA!


Tom: Unplug something before someone drowns in this big pile of SAP Data.

 As the VP arrives at the scene, a cloud forms near the ceiling, creeping out to the hallway. A final Guffaw from Adapter, and the light mist of Salesforce data turns into a terrible storm

------------ End of Same Story, 23rd time around ---------------

What is it that we all want so very badly from Adapters?

• Off-the-shelf solution
• Effortless integration between two endpoints
• No need to program complex mapping and business rules
• No need to know the technical aspects of connecting with either endpoint
• No need to have domain or business knowledge in either endpoint application.
• No need for a data analysts to be involved
• A perfect fit with both endpoints

What makes that impossible?

• Almost every implementation of an endpoint is customized or changes over time
• Your selection of source data is different from what is in the adapter
• Your other endpoint also has been customized
• Your business rules don’t match what's there already

What do you have to do to accommodate?

• Write code to be able to feed the data to the adapter the way it expects to see it ( a full integration in itself!)
• Write code to adjust the manipulation and fit to the customized endpoint
• Open up the adapter, if possible, and add code to modify the business and mapping rules. 

 What do pre-built adapters offer?

• Working at most once off the shelf
• Good experience in re-working code
• Opportunity to practice emotion control
• Incentive to find an alternative.

The alternative:

Connectivity must be designed in such a way that the re-usable parts are solid, and reusable for every instance of a source or destination. Decoupling the business rules from the technical business rules and the connectivity improves reusability. This is the model used by agile integration software. AppComms Removing Splints from Octopus



     

B2B : Brain-to-Brain

My generation was not born with cell phones. While on vacation for a few days , I tried to disconnect from the digital world with only mild success. Not a good time to be reading Born Digital: Understanding the First Generation of Digital Natives, by John Palfrey http://www.amazon.com/Born-Digital-Understanding-Generation-Natives/dp/0465005152, if I didn't want to think about this stuff. When I was growing up, telephones were ultimately connected by oodles of wires all over the planet. We never even thought of wireless telephones.

We did, though, talk a lot about ESP (extra-sensory perception, for those of you too young to remember), and we debated about whether psychics were communicating, or whether they cheated. I wonder if ESP even seems ridiculous to a young person who has always known cell phones. You don't have to even be in the same room to hear what the other person is saying. No wires. I bet it's not such a stretch to believe that you could have direct brain-to-brain communications. After all, knowing what they know now, why not? Think about it - we wouldn't even need to talk, but just think about talking. Read just a little about all the new research on brain placticity, and you have to wonder if brain-to-brain communications is just a matter of practice.

Then you have to wonder what brain-to-brain (B2B) means in the integration space. We'll be transforming everything from Venus to Mars and back again.

Agile Integration Software Means New Best Practices

One of the most exciting benefits of Agile Integration Software is the ability to dramatically streamline the analysis and other processes around designing and implementing integration solutions. If RAD (Rapid Application Development) is fundamental to the essence of the software, then it is natural that a new genre of best practices will emerge leveraging the agility of the software.

Enterprise Enabler® has "fuzzied" the lines between the classic steps of analysis, design, development, testing, and deployment. I'd like to share a couple of ways that it is changing the way teams develop integrated solutions.

Analysis Workshops replace Specs. "What?!!!," you say. "That's heresy! No self-respecting IT department would eliminate writing specs!" Ok, so hear me out. Everyone knows that the most time consuming, messiest, most unpleasant part of the whole project is defining the specs, especially the mapping specs. Well, not just defining them, but documenting them, running them by everyone for approval, re-working them, running them by everyone for approval (and so on), and even worse, keeping them up to date over time. Wouldn't you love for that whole exercise to be history, and yet to be able to get the exact current definition any time? With Enterprise Enabler, the specs are synonymous with the solution.

Here we go. You're in a conference room (or web meeting) with three other people, Tom, Dick, and Jane. You are the project manager or an analyst, or even a programmer. You're on the keyboard with Enterprise Enabler's user interface projected on the screen. With you, remotely or in the room, are the three business analysts that really know their systems' data and how it is used. Think how many questions can be resolved in a very short time if these key people can discuss what they require while you build it!

Pass the doughnuts around while we define the big picture of the integration we are solving. Jane is the expert on the destination application, "D," so in my book, she's the boss. After all, the destination's the only the application that cares about the data in an integration. Tom owns source "A" and Dick owns source "B." You pull up the template builder to define the metadata for the appropriate data from "A." Tom points you to the instance of the system that you will be working with and you show him the schema as he indicates what is of interest from his app. Then you do the same with Dick, and then with Jane for the destination. She has indicated what needs to be populated. You go to the mapper and everyone can see on the left all the fields from both sources and on the right, the fields to be filled. First Dick and Tom help you define the cross-application relationship by identifying the appropriate key fields, while you drag and drop them to create the virtual relationship. Now you continue to work with these experts to build and test the data mapping en situ. Tom discovers he left out a couple of tables he need, so you bring up the template and add the tables, and you're back in business. You run the map through and let Tom, Dick, and Jane discuss the nuances of whichever data are not obvious until it is correct. You're done, maybe even before the doughnuts are finished. And the programmed mapping will always match exactly what you see on the screen. When Jane changes her mind or Dick's application has updates that change the schema, you simply go in an reflect it in a couple of minutes.

Integration will become a set of well defined and productive workshops with all the right people, wherever they are. You'll only reminisce about the old days and how difficult it was to get the specs from each expert, document them, and go from one to the other, changing and updating, and then not being able to find the specs document to be able to keep it up to date. Remember when the programmer would discover a problem with the specs and would fix the code, but the change never got back to the specs? Ah... for these headaches to be history!