What are the different levels of platform maturity for providing innovation, and what does it entail in terms of business results and Data Analytics guardrails maturity?
Maturity Levels of Guardrails and Principles
The following table explains on how the maturity of an organisation to implement the guardrails is linked to the business and architectural outcomes.
Depending on the need and scope of the work, there can be different types of guardrails. The one below helps us understand the Maturity Levels of Principles and Guardrails within IT Architecture:
| Level | State | Description | Business Outcome |
|---|---|---|---|
| 1 | Not written | The guardrails are not written, as there is a lack of understanding of what “good” looks like. | Missing North Star. |
| 2 | Written but not referred | The guardrails are written but only in documents and are not put into practice. | This could potentially impact the business outcome and quality of the product. |
| 3 | Written, referred, but not assured | The guardrails are documented and referred but work on a 100% trust framework. This model can break when put under stress or if there are changes to the team, e.g. outsourcing, attrition, etc. | The business may invest thinking there is minimal risk, which can be a false image. This is similar to the blind spot and can lead to accidental spending, retrofitting costs and risk to business outcomes. |
| 4 | Written, referred, manually assured | The team understands the boundaries, and it is ensured that the boundaries are not crossed. However, this is monitored manually and will require a lot of hand-holding. | The quality of the product is guaranteed, but this state is not scalable. Because of manual interventions, the time to market will increase significantly, cause frustration to the product developers and owners, and delay the launch of new products. |
| 5 | Written, referred, automated assurance | The significance of the guardrails is well understood; they are implemented as part of the way of life and partially or fully automated depending on the risk, e.g. traffic lights govern traffic and are automated but are not at all the crossroads. | Enormous potential to not just bottom-line efficiency savings and unlock top-line use cases but also reduce regulatory risk exposure by amalgamating it with regulatory and compliance frameworks. |
CMM Levels
The CMM framework defines five levels of process maturity:
▶️ Initial (Level 1)
(chaotic, ad hoc, reactive, individual heroics): At this level, processes are typically chaotic and ad hoc, with no formal methods or processes in place. Work is often reactive, with a focus on fixing problems as they arise rather than preventing them.
🔁 Repeatable (Level 2)
(managed, measured, controlled): At this level, processes are more formalized and controlled, with some degree of measurement and management in place. Work is still reactive, but processes are more consistent and predictable.
📜Defined (Level 3)
(documented, standardized, integrated): At this level, processes are documented, standardized, and integrated into the organization’s overall project management processes. Work is proactive, with a focus on continuous process improvement.
🚓Managed (Level 4)
(quantitatively managed, optimized): At this level, processes are quantitatively managed and optimized for efficiency and effectiveness. Work is proactive, with a focus on continuous process improvement and the use of data to drive decision making.
🚀Optimizing (Level 5)
(innovative, responsive): At this level, processes are innovative and responsive, with a focus on continuous improvement and the ability to adapt to changing business needs.
It is important to note that these levels of process maturity are not meant to be rigid or prescriptive but are intended to provide a general guide for assessing an organization’s current level of process maturity and identifying areas for improvement.
CMM Levels and Architecture Goals
Generally, most organisations are at the level of maturity of Level 1 or Level 2, i.e. the guardrails are either not written or are written but are not referred to or assured. It is essential to obtain support from the leadership team and stakeholders to establish the data infrastructure and provide the groundwork for security before commencing or executing data analytics use cases/projects/programs. The foundation must be laid properly to avoid major delays or unforeseen costs in the future.
Data architecture within analytics is evolving at a great pace, e.g. Hadoop, which was thought to be the answer to big data just 5 to 7 years ago, is being seriously questioned and challenged. This, along with concepts of evolutionary architecture, domain-driven design, advanced analytics use cases covering AI/ML, low-code/no-code requirements, micro-services architecture or new architectural constructs, e.g. Data Mesh, cannot be embraced if the right foundation is not put in place.
The 27 points covered in the figure above give a flavour but do not cover all the details and should not be looked at in isolation. It is expected that other CMM levels, e.g. data integration, information architecture, data governance, etc., should also work alongside the data analytics maturity.
Examples of Data Analytics Guardrails
Coming Next.
The author is heading one of the largest data analytics transformations and modernizations while working as British Telecom’s Principal Enterprise Architect for Data and Analytics. The above write-up is author’s personal opinion. Contact the author at shuklabhavin@yahoo.com, on LinkedIn, or through Twitter if you have any questions.
Bhavin Shukla 