Gartner on Agile BI
Gartner recently weighed in on the increasingly mentioned and growing momentum around Agile BI.
Full disclosure: Balanced Insight was mentioned as:
one of an emerging group of vendors offering software tools … designed to manage the process of gathering BI requirements and automating the production of a functional spec, the building of database structures, online analytical processing cubes and reports, somewhat akin to computer- aided software engineering tools.
We appreciate the notice, of course. And Gartner’s take, as usual, is on target and illuminating. However, we wanted to offer a bit of extra perspective on a couple of key points.
- “Agile BI is not a panacea to all regular BI issues.” We couldn’t agree more. In our experience, metrics standardization, close working relationships between business and IT, and a culture that values transparency and objectivity are important complements.
- Because “Agile BI is concerned with iterative collaboration between cross-functional teams,” it can be “a useful addition to the management of the development aspects of BI … and can fit well within a business intelligence competency center.” Again, we agree with the overall point. Agile BI can be a driving force behind the creation of BI competency centers or centers of excellence. But we think Agile BI can and should be seen as an enabling force or defining best practice, not an “addition.” The future belongs to Agile BI and to technologies that enable and assist in Agile BI. That includes collaborative social media.
- “Agile is not a substitute for good BI requirements gathering.” We agree that requirements gathering is a critical element in successful BI projects. We also believe that the Agile BI does a much better job of requirements definition than traditional approaches. In fact, that may be Agile BI’s greatest strength. This is true mainly because of the constantly shifting nature of business requirements. Waterfall approaches may do a great job of capturing a fixed set of requirements at a fixed point in time. But the reality is that requirements are fluid, not fixed. As requirements shift, Agile BI gives developers the best chance to keep up, and deliver something that meets business needs at the time of delivery.
- “Agile BI can only be applied when IT is involved.” To some degree, the word “agile” highlights the lingering business-IT gap. Consider the relative definitions: when IT pros hear agile, they think about a specific development methodology; for business users, “agile” means a greater organizational nimbleness and increased responsiveness to changing business conditions. We think it’s both.
The bottom line? Agile BI describes both a proven development process as well as the overall benefit and end-user experience. That is, Agile BI helps organizations increase the value of their data assets, BI toolset and decision making process. The ability and confidence to make informed decisions quickly in response to shifting business conditions – that’s what Agile BI is all about.
Beye Network on BI Usability
The Beye Network recently published a research paper on “Ease of Use and Interface Appeal” in BI. Some IT types may not be focused on these concepts but we think they are critical considerations for enabling user-centric BI delivery and intuitive, easy-to-consume BI tools – a point we explored here.
Forget aesthetics, this is all about usability. As the report concludes, “When BI is easy to use, it is more widely adopted.”
We think this topic is important and so wanted to highlight what we saw as the most revealing findings:
- Ease of use rated higher than “specific tool capabilities and analytic power” which “makes it a critical aspect to making BI more pervasive”
- “Power users rate BI tools as more difficult to use than casual users” – this may seem counterintuitive, but power users are more likely to be frustrated by sub-par self-service tools or limited report-building capabilities, which often result from failure to architect the BI layer during implementation.
- Including Office-like interfaces can be a good way to make users comfortable engaging BI tools – handy tools (like data simulation worksheets) also help.
- Easy-to-use interfaces are increasingly valued by IT personnel – e.g, authoring tools for creating BI content, like reports and dashboards; however, the interfaces used to author reports are currently the least appealing.
- Users want more training on how to use tools.
Our experience confirms the findings. We believe user-friendly, attractive and intuitive interfaces can be strong drivers of BI growth generally and a boon to BI delivery, too. And they will be increasingly important criteria for buyers as they evaluate their many options.
The critical question then becomes, how do you get there? We believe real usability gains come from properly architecting the BI layer. Often, BI implementations skip consideration of usability during this step, which results in complaints from power users about poor authoring environments.
Data: Inventory vs. Insights
Many BI veterans and industry observers are mystified that lots of BI engagements start with data inventories, as we’re reminded here:
Having terabyte upon terabyte of information is irrelevant if that data is unrelated to current business issues. The problem with a data inventory activity is that identifying and counting data elements in different systems and applications won’t necessarily solve any problems. … The point of a data inventory isn’t to pick through data because it exists, but to inventory the data people actually need.
The key is to figure out a way to make the exercise worthwhile and useful. If the inventory results in answers to questions the business isn’t asking, then the cost and effort of an inventory will be difficult to justify. Business value arises when a team starts with an understanding of the type of questions the business is asking, and then investigates how data assets can be leveraged to get answers and actionable insights. That is, the inventory should be focused on ensuring the right data is available to answer important questions, and identifying additional data that may be needed.
As relevant data assets are investigated and profiled, they absolutely should be cataloged to avoid re-inventing the wheel on the next project and minimizing the effort required the next time an executive orders up an inventory. This “just-in-time inventorying” approach ensures that already-strained teams don’t waste effort on legacy data assets that are only of historical (and perhaps regulatory) interest and provide no answers or clarity to support current business decisions.
Consumerization, Apple & BI
Not too long ago, IT professionals usually referred to Apple products as consumer devices. There was a little contempt in that view. At best, Macs were viewed as tools for graphic designers and other “creatives” in the marketing department. At worst, they were viewed as toys. The serious business assets – PCs, software and infrastructure – were all Windows-based.
The iPhone started to change that view. It provided such an obviously superior user experience that many executives – including no-nonsense operations people and bottom-line finance types – naturally gravitated toward it. They started to ask IT leadership, “Why can’t I use my iPhone for work?”
Then came the iPad, another quantum leap forward. Because it does things traditional PCs, netbooks and first-generation tablets can’t do, the iPad created a new category. Yes, it’s being sold as an entertainment device, but is there any doubt that every other hardware vendor on the planet will scramble to imitate the iPad’s interface and form factor? It seems inevitable that business users will embrace it. In fact, it’s not too difficult to envision the day when the iPad and iPhone are as common in the enterprise as the network printer and the Exchange server.
The bottom line is that Apple’s superior user experience has won, and all types of users – including both consumers and professionals – will expect all their interactions with technology to be easier, more powerful and more intuitive.
Business Intelligence applications are no exception. User needs and expectations are becoming more important. Given the past struggles of BI developers and project teams to deliver user-friendly tools, this is a positive change. In the past, user needs were often lost in the shuffle of onerous documentation processes and long development cycles. As with the old “You can have any OS you like as long as it’s Windows” model, IT made decisions about the interface and semantics, and just gave users whatever BI tools could be developed.
Today, BI users expect a lot more. It is no longer enough to provide any set of tools; tools must work the way the users think and help them solve the problems that they need to solve. Agile Business Intelligence delivery, which starts with direct user inputs and offers faster prototyping, makes it easier for developers to meet user needs. Like the iPad, Agile BI is an entirely new category and will profoundly shift how BI applications are developed and consumed. Some in the industry will scramble to embrace the Agile BI concept, but if their software isn’t architected to be agile (e.g, able to extend existing assets and streamline prototyping), they will be perceived as knockoffs. They will be to Agile BI what the Zune was to the iPod and the Nexus One was to the iPhone.
In our view, the rise in user expectations is good news. User-centric BI development pays off for both business and IT. Lower costs and faster development. Increased productivity of project resources. Improved business user satisfaction and higher adoption rates. These benefits are good for everyone.
Now, when you hear IT execs refer to Apple as a consumer device manufacturer, there’s less disdain in their voice. In fact, with the rising tide of consumerization, popular devices like Apple’s may become a much bigger part of IT’s life. The user experience will become a central factor in evaluating all kind of software, especially internal BI applications that are used every day. Expectations for attractive, intuitive interfaces will continue to rise — and that’s another reason why we believe Agile BI’s day has arrived.
Recent papers from Forrester and Gartner on the topic of Agile BI highlight the BI market’s increased focus on this new approach to business intelligence. Many people are talking about Agile BI and everybody seems to think it’s appealing as a concept, even if there is less than complete consensus on the meaning of the phrase. TDWI recently interviewed Maureen Clarry of CONNECT about how organizations can get more agile through BI. It’s worth reading in its entirety, but we highlight a few intriguing insights below, and add our perspective
One of the critical factors for business success is the organization’s ability to scan the external environment to anticipate changes required for survival … By paying attention to the external environment and anticipating the future, the business can adapt its products and services to fit not just the current market but the future market.
Such big-picture thinking is a useful reminder of why BI is important. Too often, the BI community is so focused on technology and delivery concerns (which are important, of course) that it loses perspective. BI is critical because it helps business leaders make good decisions that improve performance, both immediately and over the long term.
In order to be agile, you actually need to … be both consistent and adaptable. That requires a balanced perspective on how to put appropriate standards and processes in place that can support speed, change and consistency.
It’s a nice counterintuitive point: standardized data definitions are especially valuable when the time comes for rapid decision making; you don’t have to waste time debating the meaning of “revenue” or “customer.” But organizations make a commitment upfront to nail down those meanings.
[One of the biggest mistakes organizations make is] confusing Agile with a capital A and organizational agility … we sometimes see BI organizations that use Agile methodology as an excuse so that they don’t have to define standards or document anything. This is another example of trading speed and adaptability for standardization and reuse. It does not need to be an either/or proposition.
The Agile methodology offers best practices that can help BI delivery succeed, but Maureen is right that being more agile is not about cutting corners on documentation and standardization. The challenge we have taken on at Balanced Insight is to provide a software platform that enables BI teams to be more agile while improving their level of cross-project standardization and the richness of their solution documentation. Balanced Insight Consensus facilitates business-focused Agile BI delivery, while at the same time providing a mechanism to generate rich documentation and organically converge projects toward enterprise standards.
Taken as a whole, Clarry’s remarks highlight the fundamental evolution now taking place in the BI space. There is widespread opportunity for BI projects to deliver more value, but also natural uncertainty about a profound shift to new approaches for development and delivery. In fact, the last part of the interview is focused on change management, which highlights the scale and potential impact of the shift toward Agile BI.
BI Architecture is not Data Architecture
BI delivery teams sometimes make the mistake of believing that business intelligence is mostly about architecture of the data mart and data warehouse, and once that has been done, “the BI part is easy”. After all, the only task left is to point the BI tool to the data mart and pull in the tables, right?
Let’s take a simple example. Our business users have given us the following requirements:
- I need the ability to start at the year, then drill down to the quarter, month, and day.
- I need the ability to include or exclude dates that fall on holidays, as they tend to disrupt analysis of “normal” operations
- I need the ability to analyze general data trends across quarters and months, regardless of year (e.g., do my sales tend to go up in the fourth quarter?)
In response to these requirements, we’ve built the following Date dimension in ERwin:
And here is what you get in the BI tool if you stop here and declare victory:
What’s Missing
In this case, the “BI part” was easy because we left it incomplete. The users are left wondering whether we fulfilled the requirements they gave us (it’s certainly not evident from what we have presented them).
Have we given the end users the functionality they need? Yes, but you’ll probably have to take my word for it, since it’s not obvious from the data model. The real problem is that users aren’t going to be able to understand how to use this functionality, even if we have been successful in providing it to them. For example, to drill down from 2003 to the first quarter of 2003, do I go from CALENDAR_YEAR to CALENDAR_QUARTER or CALENDAR_YEAR_QUARTER? This isn’t defined or documented anywhere (and will make a big difference in the results!). How do I trend across quarters? This is not evident in the BI tool, or even the data model diagram. The column names are technical, and there is nothing indicating their purpose or how they fit in with the other columns from a functional standpoint.
BI Architecture
In stark contrast to the data architecture effort, let’s now consider what it means to architect the BI layer itself. It is important to drive the modeling efforts at the technical level from the understanding of the business requirements. Let’s first model those three business requirements we’ve been given by the business in Consensus.
Here we have defined a user story diagram articulating how the users will interact with Date data. We have taken each of their requirements and modeled it in Consensus. The first requirement, “I need the ability to start at the year, then drill down to the quarter, month, and day” is represented in the first hierarchy on the left, named “By Calendar Year”. The hierarchy has four levels: year, year-quarter, year-month, and day. The second requirement, “I need the ability to exclude dates that fall on holidays”, is represented in the last hierarchy on the right, named “By Holiday Indicator”. The third requirement, “I need the ability to analyze general data trends across quarters and months, regardless of year”, is represented by the middle two hierarchies.
Creating the user story diagram in this way makes it clear that we have covered all three requirements, something that is not obvious when looking at either the data model diagram or the BI tool. Additionally, when looking at the hierarchical needs of the solution, new requirements become clear, like the need to populate Calendar Year-Quarter with not only the quarter but also the year. In the data model view, it is not obvious why this needs to be done, and we may even think we can re-use Calendar Month (we’d find out much later that we can’t). Finally, when generating a BI solution out of Consensus using this Calendar Day topic, Consensus will create the DDL for the data mart in the above ERwin diagram. But it will also create all the necessary hierarchical structures in the BI tool so that the users are presented with a solution that behaves the way they think, and does not have them wondering how to get a flat data model solution to give them the hierarchical answers they need:
There is no longer any question of how to navigate from year to quarter; it is built into the solution. The confusing technical column names are replaced with business names, and hovering over the name will provide a business definition (in case you’re wondering about the difference between Calendar Year-Quarter and Calendar Quarter, just check the definition of each). There’s no question about what columns to use to trend across quarters and months, as they are in their own hierarchies on the left.
Users are increasingly demanding solutions that work the way they think. Gone are the days where we can simply import technical database metadata into a BI tool and call it done. Understanding how the user needs to interact with the data is essential to creating a solution they can use effectively, and it is essential to obtaining a high level of business user satisfaction with your BI delivery.
Oil Spills & Bad Data
A couple of recent pieces about the oil spill in the WSJ highlight some common BI challenges. The first highlights the ongoing difficulty of getting accurate information.
Not every company needs to track such complicated and fluid phenomena as crude oil spewing from a failed well into a huge body of water. Not every company has to deal with literally burning platforms. But BP’s need to track accurate data that is broadly understood across organizational boundaries is fairly common. All types of organizations struggle to capture accurate data and further struggle to assure cross-functional understanding. Many organizations can’t even agree on standard definitions of basic metrics like “sales revenue” or “customers” across business units.
The second piece outlines what can happen when questionable data is integrated into widely used risk management models (registration/subscription required to access). Greater risk may result when an entity improperly interprets its data, or believes its data can answer questions that it can’t answer. In fact, bad or misunderstood data may have helped cause both the current oil spill crisis and the bank meltdowns of 2008-09:
… models that were supposed to predict bad outcomes failed—financial models didn’t correlate risks relating to a housing bubble, and drilling models didn’t predict what would happen if a rig blew far below sea level.
We live at a time when we expect access to good information, whether to assess financial risks or the impact of drilling accidents.
It’s an old saying, but it’s worth repeating: good decision making starts with good data. But, I’d go even further: in today’s more complex businesses, core data must not only be high quality, but must also be broadly understood across all the silos, platforms and “rigs,” of the organization.
What’s In a Name: BI vs. BA
Usually when people talk about semantics with BI, they’re talking about clear metrics definition, or lack thereof. But, this video from eWeek highlights the broader semantic issue around the whole category.
The video offers relative definitions of BI and BA, or Business Analytics. Basically, the premise is that BI is backward-looking, a technology or process that helps organizations understand what happened, while BA is forward-looking and predictive.
It’s a neat definition, but not 100% accurate. For one thing, different players in our industry have long used the terms interchangeably. SAS and SPSS were in the BA camp, while Business Objects, Cognos and Microstrategy called themselves BI providers.
In our view, the difference between BI and BA is basically how the data is processed and presented to the user – what I would characterize as features of the tool or platform. In other words, these are NOT market categories. And vendors such as Microstrategy and Microsoft have released this level of functionality in their BI platform or tool in a very integrated manner. You can see why there is plenty of semantic confusion among non-technical folks.
Whatever we call it, it’s important to remember the core goal – to help businesspeople make better decisions. And whether you say BI or BA, the problem has long been that too small a community of users had access to the tools and data sets. The fact is, everyone should have information at their fingertips (to borrow an old Bill Gates phrase), not just data analysts or a senior management elite. And the information and toolsets should be readily available and easy to use.
The point is, BI should be pervasive within an organization – not just one person’s job title or a standalone tool. At companies with effective BI platforms, everyone is oriented to the same important business metrics and information, instead of one guy with a dashboard ringing a bell when he sees a potential problem or red light.
Increased speed of delivery and broader, easier access to quality data are the two driving forces behind the rise of Agile BI, an emerging category we see as fundamentally different than traditional BI approaches. Certainly, it’s more than a name change. Agile BI is helping to migrate the dialog toward providing users with access to the information and tools they need to gain valuable insight into performance and start making fact-based decisions.
Podcast from the Boulder BI Brain Trust
The Boulder BI Brain Trust has posted the podcast of Claudia Imhoff’s interview with me about Consensus. We discuss the current state of the BI market, how Consensus brings the user back into the equation, and the future direction of IT-business collaboration. Enjoy!
Here is the MP3 version: BBBT Podcast with Tom Hammergren, CEO of Balanced Insight
Like a lot of people, I was into the NBA Finals this year. There’s no doubt that the old-school matchup of Celtics vs. Lakers boosted TV ratings.
Though these were two traditional franchises, it was interesting to me how each team mixed up old-school and new-school approaches. There was strong team defense and plenty of pick-and-roll (the oldest of old-school tactics), but also lots of three-point shooting and one-on-one isolation plays. Just looking at the teams, you could see how much the NBA has evolved over the last few decades. There were point guards who rebounded, big men who can shoot (hallmarks of the new-school game, ever since Larry Bird and Magic Johnson) and several foreign-born players.
BI works the same way. Tactically, companies need both traditional BI assets (like data warehouses) and newer toolsets (metadata-driven apps) to get the most out of their investments. And they must recognize emerging needs and evolving capabilities.
When it comes to BI project delivery, however, companies need to push fully into the new school. Because user demand is rising so rapidly, companies need to rethink and transform their approach to getting high-quality information and effective tools into the hands of users. When it comes to development, they need to replace the old highly controlled “stall” game and try to design an entirely new “fast break offense.” By speeding things up, companies will be able to press their advantages through superior insights.
Just compare typical delivery approaches and I think you’ll see what I mean.
| Old-School BI | New-School BI |
| IT develops in a vacuum, with little or no user input | Collaborative development, with regular and iterative user input |
| Onerous documentation, long cycles, paper-based processes and manual data entry | Rapid prototyping, test-driven development, automated outputs from business object definition to data modeling |
| Pre-defined reports, backward-looking views, IT-defined formats | Self-service and ad-hoc query capabilities for quick insights and reactions to changing business needs/requirements |
| Look-and-feel are secondary to technology working; interfaces only a coder could love | Intuitive interfaces, easy-to-consume BI apps, clean look-and-feel |
| Major milestone-driven release schedule, driven by code overhauls | Nimble, rapid, agile updates and iterations, thanks to reusable elements |
Old-school data warehouses and big BI software solutions aren’t going away. They just need to be enhanced and extended with the new school, like lighter-weight, metadata-driven BI apps that score with users.
