In-Depth
How Better Prototyping Can Improve BI
BI projects are expensive, time-consuming, and risky. Advanced prototyping can bring IT and business users together.
By Matt Warden, Product Manager, Balanced Insight
It's ironic that business intelligence -- the most modern approach to information delivery -- is a laggard when it comes to its own prototyping capabilities. Sectors such as manufacturing use prototypes and computer models to zero in on the right solution before any production investment is made. Architects realized long ago that blueprints poorly communicated to non-technical customers what was about to be built. Years of "This isn't how I imagined it" and "I thought this room was going to be different" led architects to embrace three-dimensional modeling that depicted the future structure in terms the customer could better understand.
Incredibly, BI development teams do not as a rule have the means to generate prototypes, modify them efficiently, and develop them into final solutions. Instead, teams are forced to develop and deliver "made-to-order" products blindly. It should be no surprise, then, that most seasoned BI project managers bake in time for inevitable (but expensive) rework.
The time has come for BI practitioners to adopt next-generation prototyping capabilities. The radical value proposition of advanced prototyping means BI projects can be delivered much faster, at significantly lower cost, and with dramatically higher user satisfaction.
The Root of All Evil in BI: The Business-IT Communications Gap
Why do BI projects continue to struggle, and how can prototyping help? Many in the BI community are reluctant to acknowledge a recurring issue: true requirements for nearly all BI projects are not fully understood until user acceptance testing (UAT) or, even worse, after a project is put into production. When changes are needed at these late stages, modifications must be made to every layer of the architecture -- database designs, data movement mappings, data quality routines, BI metadata, reports, dashboards, and so on. That results in more money and time being spent and a higher risk of error. Plus, IT's credibility in the organization can be seriously compromised each time business stakeholders perceive IT gets it wrong.
Because they do not speak the same language as BI developers, business users find it difficult to articulate their needs in a way that is meaningful to IT. Because BI developers are not business experts (or mind readers), they struggle to divine what users really need from BI tools and what questions users need to ask of the data.
Even when business stakeholders articulate their needs perfectly for IT, and even when the BI group understands the acronyms and jargon of the business, requirements are often still described based on theoretical needs and intangible designs. Quite often, it is only once end users get their hands on an iteration of the solution that they realize what they really need. The question is only whether this "first user touch" that leads to true requirements will happen in the first week of the project (when adjustments are simple and inexpensive) or much later.
Prototypes provide a way for stakeholders to "kick the tires" of a solution early in the development process. Done right, they can avoid the costly rework that surprises the BI development team after UAT and a solution is moved to production. The problem is that BI prototypes are difficult and expensive to create because of their architectural complexity. A report needs a semantic layer in the BI tool. A BI semantic layer needs a database. A database needs data moved into it. That's a large portion of the full solution, and changes to the prototype ripple through all architectural layers. Prototyping in BI is so costly that very few teams do it, despite the desperate need.
Some BI platforms are beginning to recognize the need to resolve the underlying cost and efficiency issues of BI prototyping. In a recent release, MicroStrategy incorporated JumpStart, which is aimed at quickly prototyping MicroStrategy projects. While this is a move in the right direction, JumpStart takes a "cookie cutter" approach to allow you to prototype only those BI projects that fit certain strict parameters regarding metrics, dimensions, and dates. If your BI project does not fit the mold, JumpStart won't be able to help much. JumpStart depends upon a rigid Access database model with generic names (for example, "DIM1" and "DIM2"). JumpStart is typical of "throwaway prototyping" tools -- the products they create likely can't be developed into final solutions.
Better Prototyping Means Better BI
How should next-generation prototyping work? In my experience, effective BI prototypes can address the underlying cause of so many BI delivery problems -- the business-IT communication gap that results in costly rework, blown budgets, and missed timelines. To get there:
Prototypes must be easy to modify and leverage automation: The value of a prototype is directly proportional to how easy it is to modify. If it takes effort to change a prototype in response to user feedback, then fewer prototyping iterations will be undertaken and the value of the prototyping effort diminishes. Prototype generation must leverage automation so that only a few clicks and a few minutes are required to make complex changes and valuable business-user input can be incorporated in new prototypes with little effort. Ideally, prototype iterations can be generated in near-real time. Users can see their input in action and confirm results within minutes of providing feedback.
Prototypes must generate into the target BI platform and not be thrown away: Prototypes are most useful when they accurately represent end solutions and relieve users of the necessity of imagining how functionality will work in their standard tool. The key is to develop prototypes in the existing platforms users know, giving users an opportunity to interact with prototypes in the same way they will interact with the end solution. Users will be able to give focused feedback on what works and what needs improvement. If your users tell you they are happy with the prototype in one platform, both you and your business stakeholders can be confident users will be happy with the end solution in that same environment.
Prototypes must engage users to bridge the communications gap: A prototype is only as valuable as the new insights it brings through interactions with business stakeholders. Prototypes allow delivery teams to gain a new perspective and keener understanding on requirements, and provide business users an opportunity to share their critical business concerns and highlight their most important analytical needs. This engagement bridges the communication gap and builds confidence that the investment of time, money, and resources will deliver results.
Solving the Delivery Challenges
Let's face it: BI needs a breakthrough in its value proposition because most projects continue to struggle. In the eyes of our stakeholders, BI projects are expensive, time-consuming, and risky. There is an increasing sense that business stakeholders and IT leaders are running out of patience -- as evidenced by the increased reliance on external consultants and the outright outsourcing of business intelligence to cloud-based providers.
Fortunately, advanced prototyping is technically feasible and a potential game changer for IT executives and BI leaders seeking to fully deliver on the promise of BI and transform their relationship with the business from adversarial to strategic partner.
Matt Warden is a product manager at Balanced Insight, a company specializing in building software that enables BI teams to avoid the costly pitfalls that have become staples in the development lifecycle. You can read more about advanced prototyping and Balanced Insight Consensus at http://www.balancedinsight.com/blog. You can contact the author at matt.warden@balancedinsight.com