Data Architecture is *so* last decade!

Robin Bloor, Chief Analyst of the Bloor Group, addressed this topic in a recent Inside Analytics webinar.

I admit to putting words in Dr. Bloor’s mouth in the title of this post. For the record, he did not say that “Data Architecture is so last decade.”

The webinar centered around the idea of Big Data Information Architecture.

And that’s my point. The focus should be on Big Data. The focus should be on Information.

Big Data: whatever the current scale of your data may be, it’s likely to be coming at you faster than it once was (Velocity.) You have a web site? Mobile optimized? Location aware? Map-based interfaces? The tabs, the pads, the phones are all trafficking through your site and generating data at a higher rate than desktops and laptops ever did.

Or, if they’re not, you have a problem that’s not data architecture related.

Your data is likely coming at you in different forms than it used to (Variety.) The above-mentioned location data. Or how your customers tweet about you. Responses to that email ad, or mobile advertainment campaign. Or the Google Search Trends data your analysts are using.

If not, how is it you’re missing out on these data sources?

Or it’s coming to you in larger quantities than it did before (Volume.) If not, have you fewer customers? Fewer products?

Again, in that case data architecture isn’t the problem you need to tackle.

This is not to say that architecture is now passé. It isn’t. To coordinate the above, architecture is going to be required.

The focus needs to change from data architecture to how data, and information, flows into, through/around, and back out of an organization.

The concept of flow brings with it:

• the source and form of the data
• the operations performed on such data
• the destination and form of the data

The need to structure data in relational tables, or multi-dimensional stores, remains. There are now other structures that can augment the traditional rectangles or cubes. But structure remains as a need.

The need for ETL (Extract, Transform, Load) or ELT (Extract, Load, Transform-as-needed), or simply L (just load the data, we’ll dig for information later) remains.

Reports, dashboards, APIs for information delivery all remain.

But no one technology, or one set of tools, meets the need today of architecting and managing these information flows.

For some needs, delivering the answers NOW will require some form of streaming analysis/in-memory structures. It’s already too late when the data hits transaction tables.

At the other end of the spectrum, long-term trend analysis may require data that’s been sitting around for a decade or more.

And to get real information may require a blend of the two.

The task is to create an architecture that concentrates on and supports these flows of data; that concentrates on and supports the transformation of said data into information as and when the business needs it.

This task encompasses data architecture but goes beyond it to account for how the different streams of data flow through the business.

And what the business wants from it.