Quick! Need a faster way to prototype and deploy analytics?
If you're in IT, and are struggling to get analytics deployed in a timely fashion, then you know it's driving costs up and your business analyst partners are disengaging and getting discouraged. The project backlog expands, and impatience can trigger unauthorized, unregulated "shadow analytics" efforts from analysts. Does this sound familiar? Unfortunately, shadow analytics activities usually involve inadequate data security controls and non-standard technology, data, and processes, but you've got to admire the "do-it-yourself" resolve from those analysts.
What if you could refocus their efforts into a faster, more effective process, while maintaining control and scoring some "quick wins"? It turns out that you can, but you've got to give the shadow analytics process a better environment in which to operate and create a path.
ENTER: THE DATA DISCOVERY ZONE
That improved environment is called a Data Discovery Zone, or "DZ", an analytical "sandbox" in which to experiment with analytical use cases and prototype solutions. The DZ houses all of the data necessary for business units to iterate through use cases. As a sandbox environment, it provides analysts adequate flexibility to assess data relevance, define initial and ongoing skill sets, process transformations and determine supporting technology needs, before pushing a use case into production.
The steps below show how a DZ operationalizes an analytics process:
1. Initially, feed raw data into a data lake or other repository where it's staged and lightly processed to provide basic cleansing. This lightly cleansed data is pushed to the DZ, a structure that reflects the previous repository, but enables business analysts to conduct the needed analysis.
2. The analysts, with moderate IT support, use corporate data management tools to analyze the data with the sole purpose of understanding the data, refining business requirements and building prototype data integration and analytics components (e.g., data feeds, transformation structures, and data discovery tools).
3. Upon business approval, the prototyped solution(s) is turned over to IT to implement in Production.
THE DZ PATH TO BETTER REQUIREMENTS, RAPID PROTOTYPING, AND QUICKER WINS HAS SIGNIFICANT ADVANTAGES:
The process empowers more autonomous and self-supporting business analysts to iterate through analytics prototypes, thus speeding up the process.
The business use cases are validated by non-IT resources, thereby increasing the acceptance and ownership of the analytic solution.
Costs/benefits and risks are more quickly understood, and lessons learned can be communicated through subjecting use cases to more rigorous validation.
BEFORE YOU START, A FEW BEST PRACTICES
Correctly planning and constructing a DZ process takes time and effort. While we can't possibly cover all the related "how-tos", here are some of the most critical principles:
Who owns what?- IT should be responsible for owning DZ data and the data platform, while the business analysts own the data management tools. Make sure both IT and business analysts are engaged together within common management frameworks.
Security over privacy– Because it houses valuable data assets, the DZ is subject to the same data security policy used to protect data privacy.
Test, but don't experiment- Prototype testing in the DZ should be sufficient to prove out use cases; however, industrial-strength solution testing should precede Production deployment. Also, testing out new ideas using significant data manipulation can be performed in the DZ; however, this should be done carefully to avoid calling data integrity into question.
Business approval and signoff- Once solution details from DZ work are validated, there should be an official business approval and sign-off as part of the transition to IT for build and deploy in production.
Use the DZ for Production?– Some DZ processing results may be valid enough for business usage; however, resist the desire to run Production out of the DZ full-time. To prevent this, many implementations of DZs "time bomb" the dataset(s) to prevent this scenario from occurring.
Disruptive change- How operationally disruptive is implementing a DZ? It will depend on several things like the relationship and communication between business analysts and IT, how much effort it takes to get analysts trained up on tools, strength of sponsorship, and other situational characteristics. Involving a formal change management effort will help the implementation go more quickly and effectively.
It gets better over time- As more and more data is loaded into the data lake over time, the breadth of enterprise use cases that can be addressed grows, while the time lag between DZ prototyping and the Production solution will decrease.
WANT TO TALK SOME DZ?
Maybe a DZ won't take you instantaneously to "Analytics Nirvana", but it can significantly increase the speed-to-value and quality of deploying analytics. If you have any questions, or would like to discuss best practices in standing up DZs / or other components of an effective data supply chain, please connect with Mark Novak at firstname.lastname@example.org or Babu Mathew at email@example.com