Showing posts with label EAI. Show all posts
Showing posts with label EAI. Show all posts

Monday, June 20, 2016

The Dirty "Little" Secrets of Legacy Integration


The more I learn about integration products on the market, the more astounded I become.  Fortune XXX companies buy politically “safe” products from IBM, Informatica, SAP, and Oracle and launch into tens of millions of dollars’ worth of services to implement them. Egad!   They’d be better off with holes in their collective heads!

Remember the childrens’ story, The Emperor’s New Clothes? Isn’t it time for someone to come out and tell the real story?

Shouldn’t an enterprise grade integration solution simplify data integration instead of creating Rube Goldberg projects?  Does it really make sense to have to send personnel to intense training classes that take months?

Nine things that astound me about other enterprise grade integration products, along with how Enterprise Enabler makes it easier, ultimately reducing the time-to-value by 60% to 80%.

1.     Robust transformation engines are mostly non-existent. This means that anything beyond the simplest relationships and formulas must be hand coded. That’s a huge impediment to fast time-to-value. Enterprise Enabler has a powerful transformation engine that captures mapping, validation, federation, and business rules as metadata instructions through a single GUI without requiring programming. 

2.      Transformation engines cannot interact with the endpoints in their native state. This means there has to be a complete integration to get each source’s data into a compatible format before transformation. Enterprise Enabler's transformation engine receives data from multiple sources in their native formats, combines (federates) them live, and delivers results in any form, or by query.  

3.       Data federation is not applied to ETL, DV, or other modes directly from the sources. Each source is handled individually, and posted to a staging area in memory or database. Enterprise Enabler brings the data together logically "on-the-fly" without storing it in memory or anywhere, and passes it through the transformation engine to the destination or the virtual model. Sometimes for performance select data is cached and refreshed as required. 
  
4.       Many, if not most, endpoints are accessed via some standard like ODBC as opposed to using their native mode. This means that it is not possible to leverage special features of the native application, and negates the possibility of being a strong player in IoT. Enterprise Enabler accesses each source in its native format, enabling the execution to leverage various features specific to the endpoints at execution. Because of the robust proprietary endpoint connectors, called AppComms, Enterprise Enabler easily incorporates legacy ERPs with electronic instrumentation in a single integration step.

5.   Data Virtualization does not support “Write-Back” to the sources. (probably because of #4) Enterprise Enabler supports authorized end-user aware CRUD (Create, Read, Update, and Delete) write-back to source or sources when data is changed or entered from the calling application or dashboard. 

6.     Implementing an integration solution is a matter of working with a number of mostly stand-alone, disconnected tools each of which imposes rules for interaction. Enterprise Enabler is a single platform where everything is configured, tested, deployed, and monitored, with design-time validation, and embedded C# and VB code editors and compilers for outlier situations. A developer of DBA never needs to leave the Integrated Development Environment. 

7.      Various data integration modes (e.g., ETL, EAI, DV, SOA) are delivered by separate tools and do not offer reusability across those modes. With Enterprise Enabler, all modes, including complex integration patterns are configured within the same tool, leveraging and re-using metadata across modes. This means that an enterprise master virtual model can be easily re-purposed, with all the same logic, as an ETL. 

8.     Further, Enterprise Enabler has a data workflow engine, that serves as a composite application builder, with full visibility to the active state and process variables defined throughout the execution. 

9.   Finally, Enterprise Enabler's Integration Integrity Manager monitors endpopints for schema changes at integration touchpoints. When found, IIM traverses the metadata to determine the impact and notifies the owners of those objects.  

In short, none of the legacy integration platforms can hold up to the demands for agility that are essential for maintaining competitive advantage.

Friday, April 11, 2014

Agile Big Data is Coming

Agility with Big Data?
Shiny but not Agile, perhaps destined to never be Agile.
Just look at ETL. Never, never agile.
So Clunky. After all these years, why is it so Clunky? So Clunky it’s fragile.

Big Data follows in the footsteps.
Big feet. Big hype, Big opportunity
for discoveries otherwise unfathomed.

Great programmers performing great feats,
Coding, coding new horizons… Open Source assist.
No hope for Agility.
Where are the trailblazers of Agility?

Ah, yes!
They’ve conquered ETL, EAI.
They’ve conquered Data Virtualization.
Agile Big Data is coming.

Are great programmers actually an impediment to Agility in complex software problems?  I‘m not talking about Agile development, but rather Agile solutions. Great programmers like to be on the leading edge of the latest new shiny trend. I remember the rush of programmers to work on the Y2K-driven Enterprise Application Integration and ERP rage. Now we’re all over Big Data.

It takes time for the market, business, and technologists to evolve the thinking about what the Shiny thing really is for, what it means, and what the technology requirements are. So, who jumps in first? The really good programmers who want to blaze the trails and solve the problems first-hand. Unfortunately, the early players can’t benefit from the evolution and maturing of the Shiny and what the requirements will really be. By the time it’s clear what it takes to genericize the problem, the Great programmers have moved on to the next trend, and are certainly not going to step back and solve the problem again in a tool or platform that hides all the repetitive work behind the scenes. 

Product companies then step in to harvest the rest of the hype curve. Leveraging their Big Name, they make plenty of revenues on hard-coded, specialized solutions where custom coding is accepted as the only way to solve the problem. In my view, a timeless benchmark for Agility is the minimization of custom code. The more coding involved in generating a solution, the farther away that solution is from Agile.

The growing love affair with Open Source code is a huge step backward for the cause of Agility. Programmers love coding. I, for one, love coding, too. But I HATE having to code essentially the same thing over and over, with just a couple of tweaks difference each time. This is exactly what integration is all about: lots of small (very important) tweaks to the same code over and over.

That is why Enterprise Enabler exists. That is why we hide all the technical details behind the scenes of our agile integration software. Any time a programmer has to do essentially the same thing more than a handful of times, it is automated with tweaks configurable in a UI. Programmers should be programming exciting, innovative new things, not laboring over repetitive, boring scripts and code changes, and maintenance.

We’re applying the same philosophy to automate Big Data integration and analysis.

Tuesday, December 28, 2010

Agile Integration Serving End Users Directly

Social media is beyond ubiquitous, putting the power of communication and availability of information in the hands of everyone individually and collectively. It has moved from being a thrill for the eager to being a fact of life even for the reluctant. Social sharing of unstructured data is proliferating, and its management is the subject of much conversation, posting, tweeting, and blogging.

But what does this mean and how does it relate to individuals who need structured data? Isn't it time for an end user to be able to access data without calling the boss, who calls the IT department, who calls the consultant, who plans the project, that gets a team, that does an analysis, that includes everything but the kitchen sink, that has a garbage disposer, that's the only thing that works, with which the project finally gets euthanized?

It's time to think about what this means to data integration: lean, mean, or otherwise. These days end users are empowered by SharePoint and BI tools and such to determine for themselves what information they need in order to do their job and make decisions. If an end user can sign in to SAP and to Salesforce and to JD Edwards, why can't they use their SharePoint portal or a dashboard to access the same data from those applications? Of course, one of the key reasons is the issues around security. Historically integration has been behind the scenes, working with no visibility to the actual end user. ETL, of course, has none, and EAI is also not end-user aware. Dashboards are designed for specific users who have permission to see the data displayed. Although the dashboard app may have its own login for security, the integration behind the scenes does what it's told without knowing anything about the user.

Agile Integration Software http://tinyurl.com/3yv85bw supports SSS and other layers of security so that an end user of SharePoint, for example, can see live data with updates passing back to the applications, only if the user has privileges to do so. That same security is available out of box in AIS for any vendor software, BPM, or BI that is designed to read and write data to an ADO.Net entity via an ADO.Net driver, or alternatively by web service calls.

For example, Enterprise Enabler® http://www.enterpriseenabler.com/ is an AIS that can be configured in minutes to merge and align data from multiple applications and generate the entity definition and custom connector for SharePoint (BDC) or generate the entity for the ADO.Net driver that is called from WSS or any other ADO.Net Application. If preferred, it can generate a web service just as easily. The SSS end user security is honored in all these models.

So, in response to the expectations of the "me and everybody else now" surge, integration needs to step up to the plate.