Blog: Barry Devlin Subscribe to this blog's RSS feed!

Barry Devlin

As one of the founders of data warehousing back in the mid-1980s, a question I increasingly ask myself over 25 years later is: Are our prior architectural and design decisions still relevant in the light of today's business needs and technological advances? I'll pose this and related questions in this blog as I see industry announcements and changes in way businesses make decisions. I'd love to hear your answers and, indeed, questions in the same vein.

About the author >

Dr. Barry Devlin is among the foremost authorities in the world on business insight and data warehousing. He was responsible for the definition of IBM's data warehouse architecture in the mid '80s and authored the first paper on the topic in the IBM Systems Journal in 1988. He is a widely respected consultant and lecturer on this and related topics, and author of the comprehensive book Data Warehouse: From Architecture to Implementation.

Barry's interest today covers the wider field of a fully integrated business, covering informational, operational and collaborative environments and, in particular, how to present the end user with an holistic experience of the business through IT. These aims, and a growing conviction that the original data warehouse architecture struggles to meet modern business needs for near real-time business intelligence (BI) and support for big data, drove Barry’s latest book, Business unIntelligence: Insight and Innovation Beyond Analytics, now available in print and eBook editions.

Barry has worked in the IT industry for more than 30 years, mainly as a Distinguished Engineer for IBM in Dublin, Ireland. He is now founder and principal of 9sight Consulting, specializing in the human, organizational and IT implications and design of deep business insight solutions.

Editor's Note: Find more articles and resources in Barry's BeyeNETWORK Expert Channel and blog. Be sure to visit today!

December 2008 Archives

Back in July, I resolved to blog regularly, and I did manage to do so for more than two months, but then I got distracted, lazy or just busy (take your choice!), so this is my first blog since the end of September. It's a bit too early for new year resolutions, so I'm just going to take it one blog at a time. One of the things I got busy on was writing a white paper sponsored by Lyzasoft which they published recently. Speaking to the folks at Lyzasoft, and also to participants in conferences at which I was presenting over the same time period, I found myself looking again at the role and positioning of Business Intelligence tools vs. the people who use them. And I've deliberately phrased that as "versus" - because it's well accepted that many "analysts" who should use BI tools as part of their toolkit end up either fighting the prescribed tool or abandoning it altogether. Business Intelligence these days is a term that covers a multitude of sins, from executives defining and executing business strategies to automated processes identifying potential fraudulent transactions without any human intervention and everything in between. Depending on the particular business need, software vendor, consultant or industry analyst involved, the focus in different implementations can vary dramatically. All remain BI, but each requires very different thinking and architectural approaches. One set of users who often sit uncomfortably on the boundary of BI are often called business analysts within their organizations. They tend to use and combine data in new or unusual ways in order to gain new insights into what is going on in the business. They often obtain the data they need from beyond the data warehouse, because the warehouse doesn't hold the data they need or has cleansed it in a way they don't agree with or they simply don't know it's there. They often manipulate and combine data in different ways as an iterative part of their analyses. And many times their tool of choice is the spreadsheet. It's pretty clear that these business analysts should be supported by the BI community. Within their own organizations, the data they require should come increasingly through the data warehouse in order to ensure data integrity and consistency. The analyses they perform and the outputs of their work also need to be maintained and tracked for compliance and regulatory reasons. Overall, setting these people off to find, manipulate and analyze data in a haphazard way simply doesn't make sense. Fitting the needs of business analysts into the data warehouse architecture is, however, possible. I've coined the term "playmart" to represent the type of environment these users need. The aim is to balance agility (playing) with control (in a data mart). I've defined eight key characteristics of a playmart in the white paper (see also below) and would be very interested to hear your views on them.
Playmart characteristics 1. Comprehensive, integrated and user-friendly tooling (agility): a full and well-integrated set of data gathering, analysis and presentation tools, suitable for business analysts, is available 2. On-demand sourcing (agility): data is loaded into the playmart as required by the business ana-lyst, based on immediate needs. Data sources may be the data warehouse or marts, but also any other server-based or PC-based data sets 3. Closed-loop cycle (agility): the full analytics cycle from exploration to decision-making and back is supported, allowing the analyst to moves seamlessly between these working modes over multiple rounds of business planning 4. Collaborative working (agility): all levels of collaboration from simple presentation sharing to full collaborative editing of data are supported 5. Strong boundaries (control): to maintain auditability, export of editable data from the playmart is strictly limited and controlled. Analysis outputs such as reports and presentations are exported only in a non-editable format and with supporting descriptive and security information 6. Pervasive tracking (control): all activities performed in the playmart are recorded and tracked 7. Automation and production-enabling (both): ad hoc analyses can be rerun with updated data on an ongoing basis in the playmart. Furthermore, the IT department can promote particular analyses to an external production environment and embed them in the business flow on a for-mal basis and/or define preferred, pre-loaded sources of data for use in certain cases 8. All-inclusive metadata (both): a comprehensive set of metadata on all aspects of data quality and sourcing, usage and manipulation is the basis of almost all of the above points. Once stored, it is available for use by business analysts on an ongoing basis

Posted December 19, 2008 4:04 PM
Permalink | No Comments |