Delivering Cloud Transformation Excellence: Envisioning Current and Future State Project Requirements - Part 3

By:   |   Updated: 2022-08-01   |   Comments   |   Related: 1 | 2 | 3 | > Cloud Strategy


Please do not scroll away - stay informed.
Dear Database Professional,

Did you know that MSSQLTips.com publishes new SQL Server content on a daily basis as well as offers free webinars and tutorials?

We know your day is hectic and you don't necessarily have time to research new topics and solutions every day, but we can keep you informed.

Take 30 seconds to register for our newsletter and look for free educational content to help you grow your career. >> REGISTER HERE <<

Thank you,
Greg Robidoux and Jeremy Kadlec (MSSQLTips.com Co-Founders)
Problem

A project can fail to deliver on its commitment of 'Delivery Excellence' for several reasons including poor project management, lack of data strategy and business use cases, limited customer participation and lack of top management support, poor planning, poor change management and quality controls, along with ineffective team structure and skills. Project failure is oftentimes more attributed to poor project management than poor engineering, poor monitoring, control and risk management, change control and governance. Both customers and vendors are interested to learn about ways to ensure that excellence is consistently delivered on transformational cloud innovation projects and programs through the Envisioning Phase.

Solution

A data strategy that is comprised of its goals and business objectives would transition into a defined roadmap that focuses on envisioning the necessary requirements through a phased approach which includes 'Current State Assessments in Phase 1' and 'Future State Design in Phase 2'. This is sometimes called 'The Envisioning Phase'. Envisioning requires thinking outside the box to tailor the solution to the needs, with the understanding that the expected business value-generating outcomes are clearer, however, the requirements to get there are often ambiguous and evolve through the course of an MVP transformational project. The Agile methodology supports this scenario by evolving the requirements to fit the business needs through the course of the project through consistent socialized feedback loops. Agile must commit to delivering an MVP, within a set budget and timeline, with structured updates that are provided at set intervals. During the Envisioning Phase, a thorough analysis and understanding of the current state can pave the way to devising a future state design that delivers an MVP that adds business value and delivers ROI, all within a set budget and timeline. This article will deep dive into the specifics of the Envisioning Requirements by focusing on the 'Current State Assessments' and 'Future State Design'.

Current State Assessments – Phase 1

After the higher-level business objectives and goals have been established as part of an overall Data Strategy, spending the time to envision the requirements needed to deliver business outcomes and ROI through focused workshops would be a valuable investment. Completing an assessment of the current state of the organization would be the first phase for completing the required envisioning deliverables. This typically begins with questions and answers that are directed toward various business and technical stakeholders through interview workshops. Once this has been completed, it will lead to a better understanding of the current landscape, data quality, gaps, and vulnerabilities. Typically, this phase lasts anywhere from between 2-4 weeks, or longer as needed.

Interview Workshops

The following section outlines a variety of questions that can be raised to both business and technology stakeholders during the requirements envisioning process to set the stage, deep dive into user context questions, and then hone in on data-centric questions. Answers to all these questions will help with identifying the current data platform landscape, assess data quality, gaps, and vulnerabilities. Finally, it will also help with determining the proposed solution and anticipated deliverables.

Setting the stage

  • Expand on how you measure and consume metrics in each of the critical categories:
  • Which data sources are used?
    • How are the calculations configured?
    • What critical grouping attributes exist (e.g., Business Unit, Region, Partner) and is the Operations team responsible for managing all groupings?
    • Are metrics standard across projects, business units and functions?
    • Are there additional categories not covered in our current understanding?
  • How are reports distributed and consumed? Do security permissions exist?
  • What pain points do you encounter in creating, distributing and consuming current reporting?
  • What is the current and desired refresh cadence? How does this differ by level of detail (e.g., project-level vs. portfolio vs. organizational tracking)
  • What is your wish list of reports to create in the future state? What challenges do you see in creating these reports?

User Context Questions

  • Primary goals for reporting. What metrics/elements need to be prominently featured?
  • Do we have a defined KPI list?
  • Should we have KPIs on one dashboard or several dashboards?
  • Who will use this product? (roles)
  • Do we need to grant different types of access and/or visibility level for these roles?
  • What are business expectations for each role? (admin, end user, etc.)
  • Who will validate the end look and feel for this dashboard?
  • What are the key elements in the current data flow from the data generation until the data publishing? (Modules, steps)
  • What are current pain points and how do you solve them? (current reports can be used as examples).

Data Related Questions

  • Which source data systems do you interact with to run your business?
  • How do you currently extract, transform and analyze data?
  • What data quality issues exist, and where is data quality high?
  • Do you regularly run validations or reconciliations within or between data sources? How are control totals generated and used?
  • What procedures are in place to update data source systems? Are they manual or automated? (e.g., change in project target dates, etc.)

Current Landscape

After the interview workshops have been completed, they will lead to an assessment of the current organizational landscape which might be comprised of various source systems. The assessment could include observations, risks, and obstacles to integration with the future state platform. As an example, the following figure illustrates details that might be captured around the current state source systems to help with determining whether it would be in-scope for integrating with the future state cloud platform.

CurrentState Assessment summary of current sources

Data Quality, Gaps & Vulnerabilities Assessment

Like the current landscape, an assessment of the quality of data, any potential gaps, and vulnerabilities for the identified current landscape source systems will further detail and document the current state. It will also help with determining how it can be prioritized and integrated with the future state technical and strategic organizational roadmap to deliver value, outcomes, and ROI to the business and its stakeholders.

DataQualityGaps Data Quality, Gaps & Vulnerabilities Assessment Summary

Future State Design – Phase 2

After the details of the current landscape have been identified and documented, it will help with determining the plan for transition to a future state design on a Cloud Data Platform. The data architectural designs would be based on conversations with multiple employees about their reporting and data needs. It would include reviews of multiple options with regards to data storage, data security, and reporting ease. The final options are intended to bring the appropriate amount of storage, processing power, security and reporting capabilities, all at a competitive price.

Proposed Architecture

A solid data architectural future state framework is intended to design the foundational infrastructure platform which will be implemented. Through the detailed design discussions, the scalability and future-proofing of the architecture will be covered to ensure it can ingest multiple sources, save legacy data repositories for historical analysis, report on exceptions to identify issues with the source data, support best-in-class data warehouse functionality with the ability to quickly scale up or down as the company sees fit, and support dynamic enterprise-wide reporting capabilities. As an example, the following data architectural design has been designed to account for multiple source systems, data ingestion ELT pipelines, low-cost pay-as-you-go data processing and storage solutions, and multiple data serving and consumption options for a variety of personas and stakeholders. It is critical that the architectural designs account for the organization's overall strategic and business goals.

ArchitectureDesign Sample future state architecture design

Projected Cost Estimates

While preparing an architectural design, it is always wise to back up the design plans with an anticipated solution cost sheet which captures the monthly cost to maintain the solution split by each technology component of the architecture design. Making assumptions for certain variables in completely fine if these assumptions are documented in detail and can be referenced and fine-tuned when needed. A baseline summary cost estimate for the solution, as shown in the figure below, will go a long way in providing justification that the proposed solution will meet the strategic cost objectives that the organization has planned for.

MonthlyCosts Summary of the anticipated monthly costs

Anticipated Deliverables

As part of the Future State Design, a clear and crisp list of anticipated deliverables that support the vision of the data strategy would help with the Project Initiation, Planning, and Delivery Phase. As an example, the following list details the anticipated deliverables for a foundational modern cloud data platform. This list will help with formulating how best to initiate, plan, and deliver the project. The inputs from these anticipated deliverables will help with creating the details of the product backlog for the project.

  • An Audit, Balance, and Control (ABC) Framework to enable reusability of data pipelines that source data from both Oracle and SQL Server databases.
  • 1 Dynamic and parameterized ELT pipeline for ingesting a combination of 20 tables through 'Full' and 'Incremental' data ingestion patterns from source systems to the Bronze (Raw) zone in the Data Lake by using the ABC Framework.
  • 1 Dynamic and parameterized ELT pipeline to cleanse, mask, and de-duplicate data based on encryption and defined cleansing logic and insert, update, and delete into the Silver (Cleansed) zone in the Data Lake by using custom cleansing logic.
  • 5 ELT pipelines for aggregating, and transforming data from the Silver zone into the Gold zone.
  • 3 DevOps automated continuous integration deployment (CI / CD) processes for Data Transformation technology, Data ELT technology, and SQL database storage technology to deploy resources from DEV to UAT to PROD.
  • 5 BI Reports consisting of dashboards and visualizations which will be deployed onto a consumable web-based workspace.

Projected Timelines and Milestones

The final component of a well-put-together 'Requirements Envisioning' deliverable is the projected timeline and milestones for the project. Notice that this milestone roadmap illustration, shown in the figure below, bifurcates the roadmap into 'Envisioning' and 'Implementation' streams. Phase 1 captures the Current State Assessment and Phase 2 captures the Future State Design of the Envisioning Phase. This is also sometimes referred to as Sprint 0. Once the Envisioning phases are completed, the Implementation commences in Phase 3 from Sprint 1 through Sprint 4. Notice that there are activities such as QA testing that can occur in parallel with the major sprint development activities. It is always a good idea to incorporate a final Sprint for stabilization and quality checks in the form of a 'buffer'.  This level of detail will ensure that the organization's strategic plans are on track, with progress being granularly tracked at any point in time. The duration of this timeline can vary by project and organization. While this sample timeline shows a 12-week end-to-end roadmap for a foundational Modern Cloud Data Platform as an MVP state, it may be quite aggressive and may progress from 6 months to 1 year. Having visibility into the granularities of such a long-term roadmap and timeline might be tough which is why it is a good idea to focus on the short-term, immediate value that a foundational MVP can deliver quick ROI and business outcomes.

ProjectTimelines Sample illustration of project milestones and deliverables
Next Steps





get scripts

next tip button



About the author
MSSQLTips author Ron L'Esteve Ron L'Esteve is a seasoned Data Architect who holds an MBA and MSF. Ron has over 15 years of consulting experience with Microsoft Business Intelligence, data engineering, emerging cloud and big data technologies.

View all my tips


Article Last Updated: 2022-08-01

Comments For This Article





download














get free sql tips
agree to terms