The following question comes from many of our clients: what are some of the advantages and risks of implementing a vendor provided analytical logical data model at the start of any Business Intelligence, Data Warehousing or other Information Management initiatives? Some quick thoughts on pros and cons:
Leverage vendor knowledge from prior experience and other customers
May fill in the gaps in enterprise domain knowledge
Best if your IT dept does not have experienced data modelers
May sometimes serve as a project, initiative, solution accelerator
May sometimes break through a stalemate between stakeholders failing to agree on metrics, definitions
May sometimes require more customization effort, than building a model from scratch
May create difference of opinion arguments and potential road blocks from your own experienced data modelers
May reduce competitive advantage of business intelligence and analytics (since competitors may be using the same model)
Goes against “agile” BI principles that call for small, quick, tangible deliverables
Goes against top down performance management design and modeling best practices, where one does not start with a logical data model but rather
Defines departmental, line of business strategies
Links goals and objectives needed to fulfill these strategies
Defines metrics needed to measure the progress against goals and objectives
Defines strategic, tactical and operational decisions that need to be made based on metrics
You never know what’s coming at you next, which is why process agility is so important. Your organization must have a ready response for anything. And you must make sure that every process participant can identify, at their level, what that response might be, so they can take appropriate action.
I recently came across a trade-press article with the headline “Mining the Cloud.” The cynic in me immediately issued a silent scoff: How is that different from “crawling the Web”? Are we just mapping old wine to shinier new bottles? Or is there something different here?
But, seeing as how I too like to proliferate discussions of mining this or that information type, I was willing to cut the reporter some slack. The article was from Redmond Developer, and concerns “Project Dallas” under Microsoft’s Azure cloud initiative. Essentially, “Project Dallas” (still in beta) supports discovery, manipulation, visualization, and analysis of data retrieved from multiple public, commercial, and private data sources via the Azure cloud. “Dallas” allows enterprises to provide users (via REST, Excel PowerPivot, and/or Visual Basic applications) with online access to aggregated feeds via Azure, which essentially operates as an online information marketplace. Also, “Dallas” allows customers to have Azure host their data for them, or simply continue to host it on their own premises while the cloud service connects securely to it.
Price-performance is everything in data warehousing (DW), and it’s become the leading battleground for competitive differentiation.
As I noted in a blog post last month, the price of a fully configured DW appliance solution has dropped by an order of magnitude over the past 2-3 years, and it’s likely to continue declining. In 2010, many DW vendors will lower the price of their basic appliance products to less than $20,000 per usable terabyte (TB), which constitutes the new industry threshold pioneered by Oracle, Netezza, and other leading DW vendors.
But that’s just a metric of price, not price-performance. Ideally, each DW appliance vendor should be able to provide you with a metric that tells you exactly how much performance “bang” you’re getting for all those bucks. In a perfect world, all vendors would use the same price-performance metric and you would be able to compare their solutions side by side.
But, as I noted a year ago in another blog post, truly comparable cross-vendor DW benchmarks have never existed and are unlikely to emerge in today’s intensively competitive arena. No two DW vendors provide performance numbers that are based on the same configurations, workloads, and benchmark metrics. And considering how sensitive these performance claims are to so many variables in the vendors’ solutions and in customers’ production environments, it can be quite difficult to verify every vendor performance claim in your specific environment.
Business processes can be incredibly hard to fathom. The more complex they are, the more difficult it is to find the magic blend of tasks, roles, flows, and other factors that distinguish a well-tuned process from a miserable flop. Even the people who’ve been part of the process for years may have little clue. It’s not just that they refuse to look beyond their job-specific perspectives, for fear of jeopardizing their careers. It’s often an issue of them being too close to the problem to see it clearly, even if they try very hard.
Process analytics is all about identifying what works and doesn’t work. It’s a key focus for us here at Forrester, and I’m collaborating with one of our leading business process management (BPM) analysts, Clay Richardson, on research into this important topic. The first order of business for us is to identify the full range of enabling infrastructure and tools for tracking, exploring, and analyzing a wide range of workflows. It’s clear that this must include, at the very least, business activity monitoring (BAM) tools, which roll up key process metrics into visual business intelligence (BI)-style dashboards for operational process managers. Likewise, historical process metrics should be available to the business analysts who design and optimize workflows. And each user should have access to whatever current key performance indicators are relevant to the roles they perform within one or more processes.
Social networks have always been with us, of course, but now they’ve gained concrete reality in the online fabric of modern life.
Social network analysis has, in a real sense, been with us almost as long as we’ve been doing predictive analytics. Customer churn analysis is the killer app for predictive analytics, and it is inherently social. It’s long been known that individual customers don’t always churn themselves—i.e., decide to renew and/or bolt to the competition—in isolation. As they run the continual calculus called loyalty in their heads and hearts, they’re receiving fresh feeds of opinion from their friends and families, following the leads of peers and influencers, and keeping their fingers to the cultural breeze. You could also make a strong case for social networking—i.e., individual behaviors spurred, shaped, and encouraged within communities—as a key independent variable driving cross-sell, up-sell, fraud, and other phenomena for which we’ve long built predictive models.
The other day, a Forrester client was asking me for educated guesses on how fast the average enterprise data warehouse (EDW) is likely to grow over the next several years, and as I was working through the analysis, I couldn’t avoid the conclusion that social network analysis—for predictive and other uses—will be an important growth driver (though not the entire story). I’d like to lay out my key points.
People often use the end of a decade to say goodbye to trends that have played themselves out, or good riddance to things that have long since passed their cultural expiration dates. I like to use the beginnings of decades for that same purpose. What, we should ask ourselves, is not likely to last beyond the close of this new ten-year cycle?
In data warehousing, the most likely casualty of the Teens will be the very notion of a data warehouse. You can tell that a concept is on its last legs when its proponents spend more time on the defense, fighting definitional trench wars, than evolving it in useful new directions. Here’s a perfect case in point:a recent article by Bill Inmon, self-described “father of the data warehouse,” where he takes pains to specify what is not a data warehouse. Apparently, many of the approaches that we normally implement in our data warehousing architectures—such as subject-specific data marts, dimensional data structures, federated architectures, and real-time data integration—don’t pass muster in Inmon’s way of looking at things. Though he didn’t mention hybrid row-columnar and in-memory databases by name, one suspects that Inmon has a similarly jaundiced view of these leading-edge data warehousing technologies.