Business Intelligence the old way
An incident last week served to remind me that not all business intelligence comes from technology giants like Microsoft or Oracle, and not all business intelligence is tracked by Gartner.
As part of the desgin of a software for a client we had to architect roles and permissions for different users of the system . The organization seemed to have a number of roles, some of which were permanent and some were temporary. In addition, some of these roles were distinct (they had permissions that no other role had), whereas some others had common permissions (plus some unique ones). Since the number of roles were less than 20, we decided not to have a “Role management” functionality, where the administrator would allocate permissions to roles in a dynamic fashion.
Our finest minds went to work on this problem, and we came up with a two category solution, where one set of roles were primary roles (the permanent roles) and some roles were secondary(the temporary roles ). Moreover, in the primary role category, most of the roles were hierarchical (moving up a chain of command), so every higher role encompassed the permissions of the lower role (along with a few new ones). We also gave the facility for users to have a primary and one or more secondary roles. Naturally, we were quite pleased with what we came up with.
However after we developed the solution and deployed it, the customer quickly became quite dissatisfied with the solution. What we missed out in our design was that there were two primary roles that were quite distinct and separate from the other heriarchically arranged roles. The customer was shocked to find that while he could choose one primary and any number of secondary roles, he was unable to choose two primary roles (one heirarchical and the other distinct). It had never occured to us that in the organization, there may be people who held two primary (??) roles simultaneously.
It taught us an important lesson. Business intelligence (the old fashion way) is not just about creating fancy reports, it is also about questioning every assumption and making sure that the software architecture maps are as close to the real business as possible.




