Introduction to BA4BI
Books on management and information technology have a half-life of maximum six months. Fads and fashions follow each other in rapid waves and leave few impressions-just like real waves...
So why bother? Why go through the trouble of spending more time to write a book than it will remain on the shelve in the book store?
Maybe it is because I hope to have unveiled a few universal truths about translating strategy into business intelligence architectures and certainly because I haven't met with any course, book or consultant who really pays in depth attention to this crucial aspect of successful BI projects.
Sure there are the obligatory check lists and the people “going through the motions” but as soon as possible, discussions focus on data models, processing capacity and tools. Even the more tenacious who try to push the business analysis issues to the limit often miss the point behind the questions as these are abstractions missing the organisation’s context and its impact on strategy formulation and implementation.
Few business analysts demonstrate deep knowledge of the strategy process and its interaction with information management. There you have the value proposition of this book: to open up the potential of understanding this interaction.
My Agile BI Enterprise Architecture Manifesto
I have waited almost a quarter of a century to state these principles, because I kept looking for falsification of the agile paradigm in Business Intelligence architecture. The early gurus in data warehousing all talked about scoping and building the entire data warehouse before delivering any report or analysis to the customer. But I soon found out that this wasn’t the way to successful BI projects. “Successful” meaning accepted and used by the customers even if the deliverables weren’t complete or 100 % accurate: as soon as the users experienced significant improvement in the speed and accuracy of the analytics and the reports, they were willing to go along with the BI solutions and applications. So there I learned my first lesson: perfection is the enemy of the good. Later, when I absorbed the theories and practice of Ralph Kimball and his approach with conformed dimensions I learned a second lesson: if you can see the entire picture, you know where to start the first iteration. And you don’t have to worry about costly rework while delivering rapid answers to your customers’ questions. That was one of the reasons why I wrote the book Business Analysis for Business Intelligence: I was sure that BI analysts were not capable of seeing the entire picture: from strategy formation and formulation to a BI system that delivered value in all layers and corners of the organisation.
Later in my career, I worked together with agile software developers and it all became clear: I had grown up into an agile believer without knowing it. Agile Enterprise Architecture is about individuals and interactions, not tools and processes, not 3NF and multidimensional models but ball point sketches and pencil drawings that communicate, convince, align and present a vision for all parties concerned.
So without further ado, here is my agile BI Enterprise Architecture (BI EA) manifesto.
1. Focus on people, not on technology:
Quality and speed of decision making is the BI EA driver, together with the strategic directions from the Board of Directors. The first argument is a persistent intrinsic motivator, the latter an exogenous hygienic factor, urging management and associates to comply with the strategic vision. Whenever you can use the mission and vision statement to promote BI EA you increase the success rate of your BI EA initiative. Why? Because Business Intelligence Enterprise Architecture is a social construct that can only survive if 80 % of the organisation adopts the construct.
2. Perfection is the enemy of the good:
Do you throw away the menu if a starter or a main course is no longer available? Of course not. He who wants to wait for a complete picture will have to wait until the cows come home. An enterprise is a living body, adapting and responding to internal and external impulses. No doubt enterprise architecture will follow these movements in a structured and manageable way. It is better to adapt fast to changing technologies via high level design principles and structures to realign with reality than elaborate the finest details of the architecture. That would be as absurd as an Enterprise Architect writing code. Trust your designers and builders to fill in the details where and when necessary.
3. Iterative and incremental:
The BI EA grows at the rhythm of acceptance and implementation possibilities. If BI EA remains PowerPoint ware, disconnected from everyday practice, its impact will dwindle before the last PPT is projected on the screen. This is also where I apply the 3x over 1/3x rule: for every piece of information you ask somebody, return him three times the value of his input. Demonstrating increased reliability and accuracy of reports and analytics will convince even the staunchest adversary to collaborate with the BI EA initiative. It is all about motivation and acceptance.
4. Build it first, then talk about it:
“I can only respond when I see the picture” is a common remark in BI EA exercises. This is my story of the Inuit and the palm tree. You can describe how a palm tree looks to an Inuit but you will never create a correct image of a palm tree in his mind until you have shown him a few photos of palm trees. If possible, bring along a small palm tree and he will be convinced there are such funny things as palm trees. That’s why we need the dialectic approach, in small increments as the next principle states.
​
​
​
The clearer you can convey the concept, the more chance of initiating a meaningful dialogue about enterprise architecture.
5. See the entire picture but use small increments:
There is no excuse for creating chaos through wrongly interpreted Agile principles. You have to overview the entire canvass before picking the right increment and working it out in detail. Coherence/Consistency and Agile are two sides of the same coin. It is no coincidence that the Kimball method of conformed dimensions works perfect in all situations. Whether you need to deliver a point solution or an enterprise data warehouse, if you can do it right the first time because you know what is ahead, beyond the point solution, the BI initiative is in good hands.
Margy Ross from the Kimball Group makes a strong plea for the bus matrix as support for agile data warehouse and BI development which you can read here.
​
​
​
Example of a Bus Matrix, an architectural view on all dimensions and facts needed for analysis and reporting (Reprint from Business Analysis for Business Intelligence, CRC Press 2012)
6. Make it attractive: user centric and practical, no academic geek gymnastics:
This is the elevator pitch: better, faster and cheaper decision making because of:
-
Consistent data definitions that enable enterprise wide communication
-
Manageable architecture of process and related data, process and related decision making and timeliness, accuracy and relevance of the available information
So the first use interview will start with “in an ideal world, what would be the perfect information available for your decision making tasks/processes/bottlenecks?”
Deconstruction of the answers will lead to a user centric approach.
7.Agile BI Enterprise Architecture has three goals:
-
Customer support for the enterprise architecture:
Some professionals ague it can take time before you have convinced the key stakeholders but the alternative can be a lot worse. Think of the energy, time and cost of errors to reduce skunk works, outright dissidence and chaos leading to underperforming and unmanageable BI infrastructure. -
A vision and plan to achieve that vision:
Management is about offering perspective and goals that lead people in their everyday actions. But it is also about embedding an ideology, a corporate culture that provides guidance when unforeseen situations occur. That is the value of a BI EA vision, supported by the CEO and his strategic vision as expressed in meetings, documents and publications. -
A collection of models and documentation describing the architecture:
This is the physical deliverable and its value is determined by the previous two goals and their level of user acceptance.
Better a simple sketch that is understood and accepted by the BI stakeholders than a fancy and comprehensive model and documentation with a sophisticated tool.
Tools like ARIS, Enterprise Architect or MEGA will provide maximum added value when the BI stakeholders have contributed to the pencil drawings and accepted the consequences of the drawing.
Be advised that 90% of the work is people management, not just modelling and documentation. Only in extreme cases of dissidence may enforcement work, but “a man convinced against his will is of the same opinion still”.
The ultimate goal is to improve the quality and speed of the decision making process in the organisation allowing for optimum return on investment because alignment between business and information management will tear down the BU walls and departmental silos where local optimization may result in suboptimal group results.
Data Analytics in Project Management
Here we contributed a chapter on Data Analytics and Scrum:
This chapter is probably the most exotic one in this book. It deals with reconciling two totally different worlds, each with their own rules and cultures and yet, it may also be one of the most valuable endeavours if you can bridge the gap between these two worlds.
The agile world is about facing the client and responding to his requirements with pragmatism to produce practical solutions delivered rapidly in short cycles of stories that yield a concrete functional aspect of the total solution. Estimating these stories is a joint effort of analysts and developers together with the product owner and each project has its own ecosystem where the complexity if the development may produce internal consistency but this will by no means imply conformity with external, objective standards.
In other words, the maturity of the team members, the group dynamics, the intrinsic motivation of key members, the hygienic factors like a nice office space, flexible working hours and last but not least… the client and the product owner may greatly influence the productivity of the team.
And then there is what I like to call “estimatiophobia” : the deeply engrained fear of developers to address the project with an entrepreneurial spirit, that sense of “I don’t control every aspect of this project but I have the will to succeed. Therefore I stick my neck out and estimate this work at € xyz”. Instead, developers tend to reduce risk as much as possible, act cautiously when the PM asks for commitments of time, quality, cost and all these other tedious metrics that only PMs can be interested in. ”Me, I just want to build a perfect solution!”
Getting Practical with Data Analytics for Project Management
Managerial business intelligence is all about creating your own benchmarks, test them for quality, predictive value, and reiterating the process until it becomes a stable framework for predicting operations and steering teams in projects and processes. Most of the time it is about basic analytic techniques like variance analysis and simple descriptive statistics using histograms making use of quality data.
For data analytics you will use simple tools like KNIME Analytics Platform. It has an intuitive interface and enables all the necessary steps in the process: connect to data, clean and transform the data and analyse the sprint data to link the sprint points estimated and completed to the real cost of a story point per team and per project.
Here’s an example of developing story point levels in an OLAP project, from the book Data Analytics in Project Management:
As you notice, higher order stories are simple unavoidable. The more story points involved, the more difficulties to establish a standard cast for these stories. You will learn by doing to build a solid analytics foundation for agile project management.
This is just one of the many business applications of data analytics. For more use cases, don’t hesitate to contact us.