EXPERT ADVICE

E-Commerce Integration: What You Don’t See Can Hurt You

The year is 2025. You’re at the Detroit Auto Show. The internal combustion engine is on the decline, and alternative energy vehicles are no longer alternatives.

Walking the show floor, you’re captivated by two apparently identical vehicles, parked side by side. Both are ruby red. Both have classic lines that scream performance.

However, it’s the engineering and extreme performance under the hood that real car aficionados desire — and when you pop open both hoods, the differences are startling.

The first vehicle’s engine compartment is a mess of exposed machinery. Traditional in its design, every component is clearly custom fitted. Pipes, wires, belts and rods are visible everywhere. To replace a component requires a mechanic certified for the vehicle make and model.

The second car couldn’t be more different. Opening the hood reveals what appears to be a sealed black box. On closer inspection, you see each engine component is itself a sealed black box, but smaller. Each has a handle, a latch, and is labeled with a function: CPU, fuse block, motor controller, DC fan, tach and more.

A turn of the latch frees a component, which slides out easily for replacement or upgrade. Each component has a standardized connector that allows any compatibile device to be used. Components can be swapped in minutes by any mechanic, even trainees.

EAI: The Legacy Approach to Integration

Fantasy? Perhaps when it comes to automobiles — but not when it comes to e-commerce. The first vehicle — the one with the patchwork quilt of customized parts — represents how most e-commerce sites are built today, using a process known as “enterprise application integration” (EAI).

Every connection from the e-commerce site to existing business systems (such as inventory, order entry, ticketing, payables, receivables and marketing content) is cobbled together by hand. Every connection works only with the e-commerce system, and nowhere else in the organization. Connections often have to be “mended” when there’s a technical change in the back office.

EAI requires custom code, proprietary third-party tools, interfaces or middleware in order to work — sometimes all of the above. Only the handful of programmers who built the system actually understand how it works, or how to fix it when it breaks. Data moves through an EAI system slowly, typically not in real-time. Worse, the EAI learning curve for developers is steep, costly and time intensive.

SOA: A Better Business Model

The second vehicle — the one with the modular black box for an engine — represents a new way of thinking. It’s called a “SOA,” for “service-oriented architecture.” It’s a seismic departure from decades of EAI, and it’s transforming information technology. Instead of focusing on point-to-point technology patchworks, a SOA treats integration requirements as a documented set of open, plug-and-play business services.

Penciled onto a white board, these business services look like a model of your business. Each box represents business services, connection points and real-time data flows. For example, a box labeled “inventory” might offer clearly labeled services such as lookup, get price, add item, remove item, show photo, get cost and so on.

Industry-standard open technologies, such XML, XSD, WSDL, JAX-WS and BPEL, are used to connect services. Data flows in real-time, giving customers up-to-the-second insight into inventory, accounting and so on — giving management unprecendented visibility into business metrics.

For IT teams, all of the SOA interfaces are governed, stored and documented in a common corporate repository. This makes it easy for developers to find, understand and reuse services when they need to integrate or adapt business applications and features.

Better still, major business systems from Oracle, SAP, Microsoft and other leading vendors are now built with SOA in mind. Its internal workings are offered as services using the same open technologies, interfaces and documentation, making it easy for e-commerce teams to use them seamlessly.

Assembling Solutions

Indeed, from a developer’s standpoint, integrating an e-commerce application in a SOA is like connecting pieces of a puzzle. Modules come together with great speed and minimal coding. Applications are designed top down, as a business model, instead of bottom-up, as a point-to-point technology model.

In fact, some of the more advanced tools, such as Oracle’s BPM Suite, allow development teams to work in tandem with business leaders to physically model business processes, and then generate workflows and interfaces. It seems like science fiction, but it’s as real as the screen on your PC.

The efficient development cycles delivered by a SOA speed time to market and lower costs. More important, a SOA’s standardized, rational approach also makes the entire IT system more agile — that is, more reliable, resiliant, and adaptable to change. And nothing could be more important than agility to an electronic marketer today.

Below is a grid that highlights the advantages of a SOA over EAI. If you would like a deeper dive to share with your IT team, please feel free to download this vendor-neutral technical perspective.

EAI

SOA

CON: Bottom-up, project-based approach, driven by technology.

PRO: Top-down, business-wide approach, driven by the business model.

CON: Point-to-point, client-server style integration, usually requires proprietary tools and interfaces; might use some open standards. Access to data is typically no real-time.

PRO: Distributed computing model based on open standards, such as XML, SOAP, XSD, WSDL, JAX-WS, BPEL etc. Resulting applications are agile and aligned to the business, delivering real-time read/write of information.

CON: Might not work with all languages and platforms; often has language and/or driver dependencies.

PRO: Language independent, no drivers required. Allows multiple languages and platforms to work together, including Java, .Net, etc.

PRO: Works with a wide variety of legacy and contemporary software development methodologies, such as SDLC, SCRUM, Agile, etc.

CON: Needs new types of control mechanisms, such as Governance and Competency Centers, in addition to traditional methodologies. However, once invested in, this becomes a plus by ensuring consistent and rapid application development and maintenance.


Krish Khambadkone is client architect for Infogain, a global provider of enterprise IT solutions, system integration and custom application development.

Leave a Comment

Please sign in to post or reply to a comment. New users create a free account.

Related Stories

CRM Buyer Channels