Now as a result we have this ugly disconnect between business and IT and our customers. So what do we do about this? So luckily there are some answers. It’s not a magic silver bullet. We can’t just wave a magic wand and fix this, but there are some best practices for aligning BI support.
There are some lessons learned that we can leverage. All of these best practices and lessons learned are categorized and described in an agile BI framework. It has four components. It’s agile software development, agile organizational structure, agile processes and agile BI platforms and technologies.
Let’s go through them one by one. Agile BI software development is probably the most familiar to most of you. I think most of you on the phone I am sure are practicing agile software development in one way, shape or form. BI is a different animal where agile is infinitely more important and more relevant than any other software development for multiple reasons.
People don’t always mean what they say. They come to you in a requirements gathering meeting with politically correct statements, but then they go back and use their own spreadsheets because it’s the path of the least resistance. Equally and importantly true that is that correct requirements really only materialize after you see something in front of you.
To break through that cycle of I don’t know what I want until you show it to me, our own solution really shines. It really allows you to build directed prototypes and change them interactively not by writing requirements on a piece of paper and handing them off to an offshore solutions provider and months later seeing the result that may not be what you required, what you requested and maybe out of data by that time.
We highly recommend relying on directed prototypes, building proof of concepts, again not with freehand mockups, not with spreadsheets, but with a technology that we do have available today. That’s the good news that most modern BI technologies do have either desktop or cloud or other options available to you where you indeed within a few minutes, or a few hours.
You can lock yourself up in the room whether you are a business analyst and or an application developer or a data architect, and literally within minutes or hours you can come up with a working prototype, go through multiple iterations, deploy to your business users and change it as requirements change. So that’s definitely a best practice that we find today.
Now all this makes sense from an agile software development, but you can’t really do this well in BI. You can’t really execute on this unless you have the other pillars of the agile BI framework. The second pillar is agile BI organizations. Agile BI support and here definitely think in terms of that neither ends of the extreme work.
I am sorry but siloed BI organizations do not work for all these reasons. You cannot rationalize your resources. You overlap. You step on each other’s toes. You will never get that single version of the truth, but let’s not forget that silos are very agile, right. If I have my own team, and I call the shots, I can get things done quickly.