The time to introduce how Enterprise BI Architecture can impact your BI and Analytics couldn’t be better. Last week, Gartner rolled out its annual magic quadrant and 2016 has been anointed as the turning-point for the idea of the modern BI platform. While many emerging analytics vendors are still fist pumping, and sending out complimentary reports, a number of eyebrows were raised as well – ours included. The commentary that followed is a highlight reel of recommendations that span front-end development, business input, iteration, and data governance. We tend to agree to all of these points.
A great story is only as good as the data behind it. We believe in empowering the business to collaborate with IT to create an efficient and effective BI and Analytics system that will guide the adoption of the ideal modern BI. Over the next few months, Pandata Group will address 4 key ways to implement a data architecture that will best serve your company’s analytics needs. It will outline foundational approaches to let business understand their data; work in a lean, iterative fashion; and ensure that governance leads to cutting out bad data:
The Business Model
Current and Future Data Flows
BI Standards and Governance
Scope and Level of Effort
If there is more about this topic you’d like to discuss, we’d love to hear from you…
Defining the Enterprise Approach
The development and implementation of business intelligence in any organization requires an enterprise approach. The “enterprise approach” is defined here as that which serves the organization’s strategic and commercial objectives and contributes to the success of that organization. Those objectives must be clearly defined and communicated before any BI initiative is expected to enhance the value of said objectives.
This series of blog entries will provide a basis for the business intelligence development lifecycle (BIDLC) for data warehouse and business intelligence (BI) initiatives in the enterprise environment. It calls for an enterprise-driven architecture that serves the strategic objectives of the organization. It is intended to allow for rapid, agile and transparent BI development.
Part One will cover the business model and how it is defined by the enterprise objectives. Part Two focuses on data flows and the transition from current to optimized. Part Three will discuss BI standards and data governance, and Part Four examines how to define the scope and level of effort required. In the end, the organization will have implemented a scalable, sustainable and maintainable BI architecture that will meet the organization’s current and future enterprise BI requirements.
Identifying Business Objectives
The business objectives of the enterprise should already have been clearly defined as part of strategic initiatives outside any BI implementation projects. Business objectives are the goals an organization hopes to achieve and maintain as it continues to operate and expand. The following are examples of high-level business objectives:
Increase Profitability
Increase Productivity
Increase Growth
Decrease Costs
Improve Quality
Drive Efficiency
Expose Risks
These objectives can now be used the drive the design of the business model. This is often referred to as the logical model in that it is a structural representation of the business requirements that does not necessarily reflect the actual physical data that will be used. The intent is to create a high level visual model of the requirements that have come out of the business objectives. This work is largely done through close collaboration between the data modelers and the business users. The business model will lead the data architect to an understanding of the business functionality and data required.
The business model should reflect what is being measured, and in what context it is being measured. In dimensional modeling, this is the distinction between measures and dimensions. At their most granular level, measures are business transactions. Their value comes when viewed in aggregate, as in sales, costs, inventory, customer ratings, quality ratings, etc. Dimensions are the “point of view” of those measures: dates, customers, locations, products, etc. Dimensions are often hierarchical in nature, arranged from broadest to narrowest in scope.
The business requirements should be represented as an intersection between measures and dimensions, and how those relationships are defined and arranged becomes the business model. More importantly, these relationships provide a 360 view of all the major elements of the business. The design allows end-users to see, for example, what products are going to what locations or what customers, outside of transactions. Conversely, users can also analyze what products are not going to certain locations or customers, which may provide more value to business decisions.
With the business model now complete, the data architect and the business now have a working map of the requirements that are of value to the enterprise. The next step is to compare that model to the method in which data flows through the enterprise to determine how to transition those flows to best serve the model. Part 2 will cover the analysis of current data flows and how the business model drives their optimization.
