Data Governance for SaaS - (Part 2 of 2)
In my last blog I mentioned about the importance of Data Governance and its evolution. I also tried to focus on the reasons behind the need and the opportunities that lie ahead. In this blog I would like to elaborate further on the challenges/needs mentioned and also try to outline ways to prevent/resolve them. I will focus on some seemingly obvious but mostly ignored concepts. Link to my previous blog Data Governance for SaaS (Part 1 of 2)
1. Firstly, the most obvious one... Involve all stakeholders and have expectations and solutions balanced and agreed upon at all times.
In IT Asset Management certain asset types carry confidential information (mobile sim PIN, User password, delegation rights control etc.). Managing security breach due to access of vital data via different screens or unforeseen entry points (i.e. via the reporting module or direct target url entry) is always a challenge.
To avoid this there can be data exchange agreements between the data provider and consumption teams. So by virtue of such agreements across the enterprise there can be a defined understanding for handling critical information across the various system records, archives etc. As the impact of these are fairly systemic its build should include expert advice & consent from Enterprise Architects, Information Security, Access & Risk Managers.
2. Follow the middle path... One should not relying on technology or tool alone to solve all their data problems.
Managing sensitive data (i.e. financial, health, legal data) in Incident, Problem, Change, Release, Service Catalog Management etc. often defy security rules. There are times when the business may need urgent solutions and ignorantly attach/share restricted information. This is unavoidable but nevertheless it is possible to have alerts based on the nature of the data that is being shared (A form of context driven help and support).
Sometimes, simple features and a little more thought goes a long way towards preventing inappropriate data sharing and mishandling. Process design, usability and training along with technology should be managed as a single piece to help achieve effective outcomes during implementation. Don't just focus on one aspect too much but rather focus on the whole (Ashwani's blog has some well compiled best practices around this).
3. Innovate... Have an integration framework in place and continuously weigh out options, consolidate and evolve.
Building interfaces, channeling data/triggers for Deployment provisioning, Product Catalog etc. and compliance could be the biggest security juggernaut. Having reliable interfaces to data sources and to be able to equally disperse information is priority for SaaS systems.
In one of our implementations we managed this via 'web services' as it was a strong capability of the platform we chose (Please refer to my earlier blog 'ITSM - Choice Matters'). With the right data structure we were able to have it exchange real-time updates across different tools (i.e. Scheduled jobs via inbound email rules is also effective but not preferred in all cases). The needs can be different but having a consolidate way of managing this maintains predictability and is more reliable & scalable option.
4. Think!... Getting a little more out of the tool by means of customization is tempting but it is important to first challenge the need and thoroughly evaluate the solution.
There will always be a need for new processes and modules (i.e. items which do not form a standard module in some tools). Most SaaS tools generally come with powerful admin configuration features. These are sometimes extendable to create one's own modules which can be integrated to leverage the combined benefits with existing modules (i.e. To avoid email overload to end users the need to build a subscription based project/release communication management module).
It's important to map and keep an alignment on the requirements, processes workflows and overall data architecture of the tool. Of course there is always a fine line between plain configuration and the need to customize (Please refer to Satsang's brilliant blog where he weighs out the options). Customizations are usually an overhead and this should be seriously weighed against priority and needs with the feedback from technical architecture and the vendor.
5. Celebrate... Dashboards are infact the most alive part of the system where the benefits of Data Governance become apparent. Groom and cherish it!
Graphical plans and charts (for incident, problem change reports, rollout plans, conflict detection, release schedules etc.) are no more nice-to-have's but rather a must. Data governance is not just about data security but also about combining data to create meaningful information for tracking, reporting, continuous improvement & business value. Reports were usually assumed to be basic and at best just data dumping capabilities.
Powerful visualization and report generation features are a valuable assets of SaaS tools today and some have taken a leap in redefining this. The concept of dashboards is a powerful one and this should be factored in early during requirements so that data structures can be defined with useful outcomes in mind.
Just to summarize... its common that project teams tend to ignore the most obvious. They sometimes push too hard in one direction and tend to deprioritize other important aspects. It's often a shame that innovation and brain power (or even gut feel and experience) has to give way to bureaucracy and heavy processes. The solutions are there and we obviously know them. It just takes a little more from all to appreciate and manage it instead of letting things go out of control...
It's critical that IT Departments are abreast with not only the current but also future needs of their business. This is easier said than done... but with SaaS in the picture, software development and deployment is not the same anymore. The ease of evaluation and adoption is quick and hence it's important for IT leaders to be ahead of the curve in knowing what's around and introducing these within the organization where they see fit. This should be done before the businesses start taking independent decisions without IT in the picture.It is important to understand and realize that rapid prototyping possibilities of SaaS does not necessarily reduce the expected time for analysis and testing. These are still critical and required. Cloud adoption is quick but this should not make it vulnerable to business pressure and prone to hasty signoffs or decisions. SaaS does not make Data Governance easier nor does it make it riskier. The paradigms are shifting, the possibilities are surely greater but dealing with it will require more focus on vision, innovation, creativity and most importantly leadership.
