Don't insist on strict discipline when it comes to your internal processes' protocols. Instead, try installing a thin support layer above all of your key IT/BI systems. If you allow this layer to become the natural workspace for all of the individuals participating in the processes, the protocols will be respected spontaneously.
Last week (blog) I wrote about the key problem facing the management of business requests: the fact that both the business user and his supplier have a common motivation to by-pass the internal processes for the handling of BI requirements. This leads to, not only, the creation of a mess in the documentation of data-structures and reports but also to chaos in the actual DWH and the company's reporting.
It's possible to try to be more disciplined and adopt strict guidelines about how BI requests have to be handled. However, this either doesn't work well or if it works at all, leads to (much) slower times in the delivery of solutions.
Fortunately, there's another way to avoid, or at least mitigate, the growth of entropy in a company's DWH and its reporting and I'm going to outline it today.
An Information Touchpoint for everyone
BI knowledge management systems come in all shapes and sizes. In previous blog's we've discussed extensively the characteristics and features that an ideal BI knowledge management system should possess. In the introduction, I mentioned a thin layer that touches all parts of a company's data processes. Our solution to the problem of entropy outlined above requires that this thin layer, or Information Touchpoint as we call it in Semanta, is a BI KM. But not just any BI knowledge management system, a particularly special and agile one. However, before we look into the specifics of this Touchpoint, let's remind ourselves about some of the key features identified in earlier blogs, that a good knowledge management System should have:
Documentation: the best Touchpoint should be able to provide descriptions of data-structures and reports, definitions of the company's business language (a business dictionary), as well as projects etc.
Communication: it also needs to be a place where you can ask the relevant experts your BI questions and store their answers for later re-use
Operation: it should also be a place that provides information about the current status of BI outputs (see blog), the workflow of tasks assigned to BI experts and the amount of time and effort spent on them etc.
OK. So if that's what the ideal KM or Information Touchpoint should look like and offer, how can this support the business requirement process? It's actually not that difficult. It's true that the ordinary KM can't support it. However, at Semanta we've found that just a few small but significant additions together with the broadening of certain features allows a surprising amount to be done. The "thin layer" that we at Semanta have developed, our Ency, allows the following to take place:
Business users can use the Touchpoint to find out whether BI has what he/she needs - and if they don't, they ask DIRECTLY IN the Touchpoint for what they're missing.
All the stakeholders who are needed to approve a request, also do so in the Touchpoint - after all, all the information about the request is already there.
When the analytical work that elaborates the requirement takes place, it's not only done using the Touchpoint for reference, but actually DIRECTLY IN IT (e.g. a new data-structure is needed. First, it's modelled in PowerDesigner but then the model is published in the Touchpoint and all the related reports and terms can be referenced and linked to it there. Not only that, the minutes from the analytical workshops are able to be stored there etc.).
Finally, all the related test-cases and bug-reports can be made available there too.
So how does this discourage the growth of entropy and provide a point of order in a potentially chaotic system? Well, enabling this layer to fulfill the tasks I've described above allows it to become a place for communication between the many users of, and participants in the requirement process. For example:
The requestor communicates there with the BI expert responsible for the initial analysis, the formalisation of test-cases and other issues.
The analyst is able to locate the owners of the affected data-structures and reports there and can discuss the planned changes with them there too.
The developer can interact with the BI analyst there, while he prepares the specification document, defining what will and won't be implemented and programmed.
The UAT group's test-cases are stored there and they also communicate their results there.
The IT operations expert will access the description of the necessary configuration changes there, as well as ask questions and clarify them etc.
As you can see, with this kind of broadening of features, our "upgraded" knowledge management system, or Touchpoint not only provides application support for requirement management but it also becomes an IT system where development, change management and other processes happen (the testing & verification process, project management process etc.).
If such a thin layer is in place, all the different individuals who participate in business requirement management can not only carry out the steps in their use-cases here, but also as they work, it, the Touchpoint, spontaneously gains all the information about what is new or has been changed in the DWH or the company's reporting. Like the TARDIS, though thin, the Touchpoint contains a vast volume, admittedly not of timelords and their assistants but of easily accessible data and information.
I'm not trying to say that such an Information Touchpoint should replace all the other IT systems being used. No, what's important is that it's integrated with them and provides a “thin layer” above them where all the participants in the various processes can find the information they need and communicate with others about it. Then it just becomes a question of monitoring the changes and good stewardship.
It's true that even this way of handling business requirement management and its consecutive processes can be by-passed. From our own experience, we at Semanta have found that this mainly happens when the data-governance process is too strict and doesn't allow enough flexibility at the data-marts layer that's used by business users. However, what I'm suggesting here is using our "thin layer", which I call an Information Touchpoint, in such a way that it becomes a natural work space for all the key individuals participating in the processes.
Doing this, we can create a system which naturally contains all the information about data-objects and reports that's needed. Whether that's information about their owners, the projects affecting them, the business users who required their creation or change, the efforts spent on their build etc, is not important - it'll naturally be inside our system . Of course, as the information is a “by-product” of or a "trail" left behind by work completed for an entirely different purpose, it's not and never will be a clean formalised documentation, that describes everything from all conceivable positions and aspects as many IT / BI traditionalists are striving to achieve. However, I fully agree with the "agilists" who say that perfect documentation is a risk because nobody has the energy (=time/budget) to maintain it.