Why Automating access to your critical Data is Important to you.

When we talk about data accessibility in terms of critical thinking, a question we often ask our clients is: Why do you think access to your critical data is important?  The answer is rarely obvious and most often that the client typically doesn’t even have access to critical data, or else doesn’t have access to it in time to take action.

At this point, many solution providers will immediately jump to the “How” of their solution, and dive into all the cool features and bells and whistles, all without fully understanding why accessing data efficiently is important to their client, much less what decision the Client needs it for.   Eliciting this answer informs your Client’s most important and relevant use cases around which a new approach makes perfect sense.  So let’s give it some context before we dive into the “how.”

Accessing your data efficiently is about more than just finding and manipulating data from a single source or even heterogeneous platforms. Decision makers need to access the data to develop and deploy business strategies.  Even more importantly, we need to access critical data in time to take tactical action when warranted. The ability to see your business data in real-time also lets you check on the progress of a decision.

Data Virtualization is one solution to get at your critical data in real-time, even if it is scattered across multiple sources and platforms.

The first thing you need to know as a Client is that you won’t have to recreate the wheel and replace one cumbersome approach with different cumbersome approaches. 

Connectors, connectors, connectors.

Typical elements of a useful Data Virtualization paradigm are up-to-date “Out of the Box” data connectors, platform specific protocols, useful API protocols and API-specific coding languages and thought to whether modified data would be written back to a source or new data-set. 

An example of the latter would be updating your balance in a Customer Care web application after making a payment online. In this example, the following is assumed:

• There are 5 offices across the world. They all speak different languages and have different platform protocols
• Currently data is scattered in various sources (i.e. cloud, excel, and data marts)
• It takes too much time to combine the scattered data sources into one report. Transformation is a long process (with many steps) that turn raw data into end-user-ready data (report-ready for short).

With the right Data Virtualization tool, or Data Integration platform, you can consume data in real time.  Without waiting for IT, without making copies, and without physically moving the copied data.

Since Data Virtualization reduces complexity, reduces spend on getting at and using your data, reduces the lag from requesting data to using data, reduces risk from moving and using stale data, and increases your efficiency as a decision maker, data virtualization is almost certainly the path to take here.






This is a guest blog post and the author is annonymous.

Convergence is, at Best, Asymptotic

No, not asymptomatic. Asymptotic. “Convergence” is a term we hear these days in IT. The convergence of Data Integration, in particular, is the one I care about. In the analysts’ vernacular, converged integration seems to mean a product, company, or platform that handles all modes of data integration – ETL, EAI, ESB, DV et al.

By definition, “convergence” means a coming together, which clearly implies the parts started from other places and came voluntarily or were coerced into coming together. Just looking at history, companies like IBM, Oracle, and Informatica absorbed outside companies and products to nominally have a product suite with all the modes. Here’s how it works: Need ETL? Buy Ascential, rename it, give it a massage with hot towels, then say, “Voilà! Voilà! Voilà!” and your product now covers ETL, too! Or, take a Data Virtualization product, write a bunch of code, and again, “Voilà!” and your product covers ETL, too.

With all due respect to the analysts, the word convergence may describe the reality of most companies incorporating more and more integration modes, but keep in mind though, that in mathematics convergence means getting closer and closer but never quite getting there: asymptotic [translation: Close, but no cigar!].

I am certain that the analysts do not mean Convergence in the mathematical sense. The term is quite useful for establishing a powerful vision of dramatically reduced time-to-value, clean architectures, flexible integration patterns, and highly streamlined change management and maintenance over time.

If you read my last blog http://tinyurl.com/lmwtzth you probably recognize that there is a significant difference with Enterprise Enabler®. It was designed from the ground up with a powerful core that handles all the common functionality of the range of modes, with implicit data federation across disparate sources (databases, electronic instruments, spreadsheets, data warehouses, ERP systems, cloud services and so on). 

 That core is the common root of all data integration modes, a bit like the trunk of a tree that has any number of branches and leaves, instead of trying to converge a bunch of branches by stuffing them all in an opaque vase and pretending like they have a single trunk. That spells trouble, and doesn't even come close to asymptotic. Probably not asymptomatic, either. 

BPM's Nemesis : Clunky Data Integration

Back in the '90's, I jumped right in there with all the other consultants and IT operatives when Business Process Reengineering came along. Since I had been heavily involved in computer graphics before that, I even wrote a crude business process designer so we could abandon the yellow stickies on the walls and halls as well as all the tedious documentation (and re-documentation). BPR evolved to BP'X', and by the time mainstream BPM software came along, I was working on developing software to handle the data flows across all the systems involved in what I called at the time, "Decision Support Chains."

I lost touch for a while with what BPM in general was doing and realized later that most of the products probably actually began with the design and documenting of the processes. I opined that they were started contemporaneously with my similar effort, and were abandoned in favor of Y2K gold. Once that was over, maybe they picked up the old code, dusted it off, and went on from there. Most started with design and evolved to handle complex as well as practical of business process management, but the necessary and tough behind-the-scenes integration has been generally assumed to be outside the discipline. There still appears to be a missing layer or two.

With the great tools now available to design, model, optimize, and automate human workflow, it seems that the toughest part of a full implementation of new processes, or automating old ones, is the ability to get the data where it needs to be when it needs to be there. The necessary overhead and inherent inflexibility of data integration are very often so prohibitive that they kill projects before they even get started.

Agile Integration Software (AIS) working with BPM provides the complete "stack" of necessary functionality. AIS fills in with rapidly configured, adaptable data integration, along with the data logic layer that interacts with the BPM layer, triggering data flows as needed exactly when the process and participating decision support applications require it.

All the overhead of designing and maintaining staging databases goes away along with the resultant data latency. The cost of BPM implementation is greatly reduced, and the solution is able to respond as quickly "under the covers" to business change as it is on the BPM layer!

When BPM inherits all of the features and assets of AIS, BPM become agile, too.

ABPM - Agile Business Process Management? I like it!