Monday, I shared an excellent column by Paige Roberts that asks whether business needs or architecture should drive business intelligence projects. Roberts clearly thinks it should be both, but she wonders how to resolve the push from the business for solutions and IT's desire for a well-designed architecture.
In Roberts' piece, she talks about a BI team that tried to please two business divisions that needed different sets of data. Given their limited resources, what happened is that neither division was pleased with the results. In retrospect, the head of the team, Claudia Imhoff, said if she could do it over, she would pick one business need and focus more on the architecture, rather than push to solve solve both business needs. Roberts wondered if there was an approach that would accommodate both without compromising architecture.
It sounds like a catch-22, but as I wrote yesterday, I think it's actually a red herring. I think the real issue for BI and similar initiatives is that they often don't start with the data.
In fact, my initial reaction when I read Robert's article column was, "This is precisely why IT needs to treat data and integration as strategic issues."
The tech community throws that word - strategic - around a lot. So let's look at what it means. Merriam-Webster dictionary defines "strategic" as "necessary to or important in the initiation, conduct, or completion of a strategic plan."
Too often, data and integration are treated as tactical components in a project. There are two things wrong with this approach.
First, if you're only approaching BI as a project, you're missing the opportunity to think and act broadly. As ZapThink's Ronald Schmelzer explained back in 2008, project-focused thinking isn't working anymore:
Companies that have no plans to do any sort of heterogeneous application development or composition, or who have the time and budget they need to deal with constantly expanding projects in the face of continuously expanding complexity can afford to do discrete IT project management. But for the rest of us, any movement we make to try to bring the organization's systems together into a predictable, composable, governed, loosely-coupled, and potentially reusable set of assets, or in other words, to apply any real Enterprise Architecture, will require that we stop doing IT project management in a discrete fashion and treat IT as a continuously evolving asset.
Second, if part of your strategic plan is to make better business decisions by using analytics and BI tools, then, without a doubt, integrated data is necessary and important to the initiation and completion of that plan.
In a world where 70 percent say their BI requirements changes on a monthly, daily, even hourly basis, data needs to be handled as a strategic asset, which means decoupling it from projects and applications.
"Clearly, if businesses are to benefit from BI, the underlying data integration process needs to be optimized wherever possible," Informatica Director of Product Marketing Ash Parikh recently told Enterprise Systems. "We need to let the business own the data and define the rules while IT somehow retains control. We must also look for ways deliver better business-IT collaboration in order to reduce waste and minimize delays throughout the process."
Parikh argues that data virtualization is the key to solving this problem. Increasingly, he and other experts in the industry are pushing for a separate data services layer that makes data available in much the same way SOA makes application functions available services.
The demands on data are too great to continue to deal with it in silos. It's becoming clear to those who deal with master data management, data quality, data governance, BI and other enterprise-wide efforts that treating data as a one-off component in other projects isn't working.