Many people look to agile development methodologies as a structural way to involve the business in the design and development of business intelligence (BI) solutions. However, many times the design practices employed within the iterations aren’t actually business driven at all. We see this most often in the design of the data models and BI semantic layers, where data modelers take high-level user requirements and design the model based on their analysis of the data. A compelling alternative is “business driven” data model development, whereby the modeling process starts with the users, not the data. How is business-driven development different from its traditional counterpart, and how--if at all--is it better?

Generally speaking, both paradigms involve the business. In the data-driven model, however, the business's role in data model design is severely limited. The stakeholders generate their list of requirements, sometimes in the form of user stories, and the data modeler begins designing the data model, often creating a design based on how the data is modeled in the source systems, rather than how it supports the business processes. When the users begin working with the data, they soon identify new, specific requirements and/or business rules.

Because of its structure, a system-driven approach is highly susceptible to failures of communication and accuracy. Depending on an organization's culture or maturity level, these endemic problems can complicate--and sometimes sabotage--development. The system-driven model also has an absolute-latency feedback loop: potential issues are identified (or fixed) late in the project, which has a significant impact on downstream development. The result is that a data modeler must continually adjust the model as new rules and requirements are identified. Besides producing suboptimal data models, this disrupts ETL and analytics development causing projects to miss their target delivery date. In a business-driven approach, by contrast, the data modeler avoids making significant changes to the model because more requirements and business rules are fleshed out up front. Business-driven development addresses these and other issues.

Fit and Finish

With business-driven modeling, the initiative begins with and is driven by the business. Business subject matter experts work with the data modeler to refine and clarify their requirements via conceptual and logical data modeling, providing the opportunity to validate the business process and the business rules and nomenclature.

For this process to work, both business users and data modeler must understand the business in the same way. This is why business-driven development places so much emphasis on conceptual and/or logical modeling. A conceptual model is a high-level representation of the business process. However, in the real world, there isn't always enough time to perfect a conceptual model, so some may decide to start with a logical model, which can be abstracted to a higher level. What's important is that both business and IT see and understand the business, its key concepts, entities, rules, and relationships in the same way.

A business-driven approach promotes near-real-time feedback and correction and makes it possible for the business to more quickly identify what it actually needs versus what it thinks it wants. The data modeler plays a key role by facilitating discussion with business SMEs to flesh out concepts, entities, rules, and relationships. In a sense, business-driven development is dialectical: it's asking and answering questions, which leads to new questions and answers, along a discussion thread. In practice, this dialectical process helps mitigate common problems, such as what happens when the data modeler just misses something because of misunderstanding or imprecision.

Better Project Outcomes, Better Business/IT Relations

Business-driven data modeling is an effective strategy for aligning the perspectives and priorities of business and IT, ensuring that both share an understanding of the business. In business-driven data model design, stakeholders and subject matter experts work closely with the data modeler to identify and refine their analytic requirements. This collaborative process helps both groups clarify business rules and nomenclature and gain insight into business processes and operations. It involves asking and answering questions, which leads to new questions and answers. The result: business users can develop a better understanding of what’s actually needed and identify the potential value of the business problem they are trying to solve.

Most important, business-driven development leads to empirically better project outcomes. Problems can be proactively identified and corrected prior to development and testing, rather than late in the process. Finally, business-driven data modeling can be as valuable a tool for business self-awareness as for IT-business alignment.  By working with the BI group and data modeler, the business interrogates itself and its operations. Stakeholders discover how their business functions and where it excels, and where they might focus on improving operations. Business users receive better, usable data that addresses their actual needs--and they get it faster, building trust and respect between both groups and promoting more effective collaboration in future endeavors.