3. Guardrails Maturity – Data Analytics

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:

LevelStateDescriptionBusiness Outcome
1Not writtenThe guardrails are not written, as there is a lack of understanding of what “good” looks like. Missing North Star.
2Written but not referredThe 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.
3Written, referred, but not assuredThe 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.
4Written, referred, manually assuredThe 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.
5Written, referred, automated assuranceThe 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.
Maturity Levels of Guardrails within IT Architecture

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

Data Platform Architectural Evolution.

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.

2. Guardrails for Data Analytics

My previous article discussed an introduction to guardrails and their significance. This is the second blog I plan to write about this topic in a series. This article mainly focuses on the challenges of writing the guardrails in data analytics that uses Data Mesh as the architectural construct and how they can be approached.

📈 Data Analytics Guardrails

Data analytics guardrails are rules, procedures, or controls put in place to help ensure that data analytics processes and systems are being used safely and ethically. These guardrails are designed to prevent data misuse or the unintentional disclosure of sensitive information, and to help ensure that data analytics results are accurate and reliable. Data analytics guardrails can include data governance policies, data privacy regulations, and quality assurance processes. They can also include technical controls, such as data encryption or access controls, to help protect against unauthorized access to data or data breaches. Overall, data analytics guardrails are an important part of any organization’s data analytics strategy, as they help to ensure the data’s safety, security, and integrity and the results of the data analytics process.

🚧 Challenges in Writing Guardrails

The challenge is to “write” guardrails that are easy to interpret and socialise, are feasible and implementable, are machine-readable and can be assured by machines/systems.

But the first hurdle is to agree on what “good” looks like with all the stakeholders, including the team that is expected to live within the boundaries.

⚒️ Breaking the Problem into Manageable Chunks

The first question that comes to mind is where to begin writing the guardrails. The most effective method is to start from the top and then componentise the entire architecture canvas across the Enterprise Architecture into domains, further dividing domains into sub-domain areas. One sub-domain listed below within the Data Domain can be Data Analytics.

A sub-domain, e.g. Data Analytics, can be further modularised by creating independent solution building blocks. We can then understand the scope of these blocks, e.g. operational vs analytical plane, and define finer guardrails for each solution building block within these planes, inside that finite scope and context.

The figure above on Data Analytics Reference Architecture shows how Operational Plane and Analytical Planes are coming close together in a Domain-Driven Design and Data Mesh Architecture. Data Product Management, Data Security and Privacy, Data Quality and others overlap significantly between the operational and analytical planes. On the other hand, Data Integration has overlaps but is still developing as a self-serve, evolutionary architecture and may be maintained by IT rather than the business.

⚛️ Identifying Fundamental Building Block – Data Products

The Data Analytics Reference Architecture and the Solution Building Blocks shown above then use the architectural construct of Data Mesh. Data Mesh helps create the data infrastructure, within the data analytics sub-domain to connect the Operational Plane and the Analytical Plane.

The reference architecture above provides the blueprint to create manageable and reusable technical infrastructure per higher principles from IT guardrails separation of concern. Whereas the Data Mesh construct then provides the governance layer and data architecture to help create Data Products using principles of Domain-Driven Design, making it manageable within the bounded context but interoperable across domains, sub-domains and bounded context.

Data Products accessed via the Data Analytics tools/demand via Data Marketplace will be the actual tangible output to the personas consuming information. As a result, Data Product can be used as a fundamental building block within the Data analytics subdomain.

The advanced analytical plane in the illustration above does not detail the AI / ML aspect, which will be discussed in future blogs.

🌏 Fundamental Building Block within the Data Ecosystem

The responsibility of the architecture is to ensure the quality of the output. If the quality of the fundamental building blocks, i.e. Data Products, and the solution building blocks, i.e. technical components, is well maintained, a high-quality output delivering use cases will be assured.

Each Data Product should ensure that it fits well into the data ecosystem and complies with different dimensions of data governance, data architecture and data management frameworks.

AreaDescriptionData Product Context
Data ArchitectureDefines the blueprint for organising and managing data assetsLifecycle Management of Data Products
Data Modelling & DesignThe process of discovering, analysing, representing, and communicating data requirements and designsIt deals with how Data Products are internally structured and connected to the use cases. This area brings the discipline ensuring that the data products are reused, data is shared, and redundant copies of data are not created outside of the domain where the data belongs.
Data Storage & OperationsThe design, implementation, and support of stored data.  Operations provide support throughout the data lifecycle from planning for to disposal of dataThis is the Information Lifecycle management of the data stored within the Data Products.
Data Security and PrivacyThe protection of data from unauthorized access or use.The measures and practices are implemented to prevent unauthorized access to or disclosure of Data Products. It also deals with the data within the Data Products around the rights of individuals to control how their personal information is collected, used, and shared.
Data Integration & InteroperabilityThe movement, consolidation, and translation of data between data stores, applications, and organisations. Integration: messaging, formats etc. Interoperability: semantics, understanding, and interworkingHelps in the consolidation, convergence and connection of the Data Products.
Document & Content ManagementStorage, management, and access to digital content, such as documents, images, videos, and audio files.Unstructured data managed within the Data Products. The architecture managing Data Lake vs. Data Warehouse use cases for documents, images, videos and audit files.
Reference & Master DataOngoing reconciliation, maintenance, and sharing of core enterprise data to enable consistent access to a single version of truthStoring hierarchies to map levels, codes to harmonise data from various systems, lookups to map descriptions, enumerations and any domain/sub-domain specific patterns within or across Data Products.
BI & Advanced AnalyticsPlanning, implementation, and control processes and technology to manage decision support data, analytics, and reportingThe data structure design within Data Products, e.g. dimensional approach, denormalised, etc. And how the data/information is consumed within the reports, dashboards and advanced analytics.
Metadata ManagementHigh quality integrated metadata on: definitions, data models, data flows, and other information critical to understanding data throughout its lifecycleThis discipline aims to link Data Products to the Enterprise Metadata Management Service. It should be noted that Domain Boundaries are subject to change as a result of modifications to business processes or upcoming Domain Distillations. The domain, sub-domain, bounded context and data product boundaries should not be materialised/physicalised but mapped logically within the metadata repository.
Data Quality ManagementThe planning and implementation of quality management techniques and systems to measure, assess, and improve the fitness of dataChecking Data Integrity within the Data Products in the Data Analytics sub-domain. Data Integrity is a subset of overall Data Quality Management. The Data Integrity check within Data Analytics should be integrated into the organisation’s Enterprise Data Quality Service.

When the Data Product complies with the guidelines established by each of the dimensions above, it can be shared and reused and is expected to provide the use cases’ specified benefits.

📏Maturity Levels of Guardrails and Principles

The third write-up in the series will focus on the maturity levels for data analytics guardrails.

Coming Next.

1. Guardrails, An Introduction

Guardrails (Plural Noun): A rail at the edge of something, such as a cliff or the deck of a boat, that prevents people from falling off.

What, in your opinion, should be the first priority before embarking on any new venture or innovation? First and foremost, safety?

At first glance in the photograph, the white car appears to be leaving the arrival gate. The fact is that this is a departure gate. If you look closer, there is a small “No Entry” board in blue, suggesting that this is a departure gate and not an arrival gate. The white double line on the road also indicates that this is the pause for the outgoing vehicle, i.e. the departure area before a vehicle takes the major road.

How did we reach this confusing stage, and how is this linked to the topic of guardrails?

This is called “hard coding” within the IT Engineering area. The “Arrival” and “In” signs were hardcoded into a decorative gate when the train station was built with a thought process to make it look artistic, grand and elegant. However, the most important point missed was that there can be a state change at some point in the future. An entry gate can also become an exit gate in future due to an increase in traffic or a change to other external parameters, e.g. road design, taxi ranks, car size, etc. Avoiding hardcoding and making it configurable would be a guardrail similar to something in IT that could have avoided this situation.

🗽 Boundaries Liberate

Guardrails / Boundaries sound claustrophobic and negative in nature. They are being seen as restrictive, an unnecessary rule that takes away freedom.

Another way to look at it is that boundaries provide safety, it helps us liberate rather than constrain us. For example, children from a school near a busy road could only play in areas where adults could keep an eye on them. This was true until a fence was built, after which the children could play in any area of the playground of their choosing.

Boundaries limit options but also provide freedom of choice from the available options. As Greg Mckeown puts nicely in his book Essentialism – The Disciplined Pursuit of Less, it gives freedom to select the vital few from the trivial many and is central to Essentialism.

It is not about policing and restricting freedom but taking out unnecessary adventures that can risk the overall goal/vision, may lead one to danger, or waste crucial time exploring things that do not really matter. Too many options may not lead us anywhere; guardrails allow us to experiment within the chosen option.

Exploring Examples of Different Types of Guardrails:
📿Guardrails: Religious Beliefs

This is Kutubiya mosque, Marrakech, Morrocco, and no building can be taller than this Meenaret in the old town. This is by design, as it reminds people that principles and values are higher than anything else.

The principles of Islam are Surrender, Submission, Sincerity, Obedience and Peace.

🏳️ Guardrails: Political Beliefs

India’s Republic Day falls on 26th January. This was when the Constitution of India came into effect on 26th January 1950, and India became a Republic.

The word republic comes from the Latin term res publica, which literally means “public affair” or “public matter”, i.e. the power resides with the people.

The constitution is a book of rules, principles and guidance on how the country should operate. It is above any law, politics or religion of the country, which brings “real” freedom to the people by setting up boundaries.

The constitution sets up three pillars,

🏛️ The Legislative Power: Task of passing laws and supervising their implementation

👮‍♂️ The Executive Power: This is the federal government tasked to implement laws created by the legislation.

⚖️The Judicial Power: Interprets law and administers justice; their task is to ensure the laws are complied with.

The constitution is above all these pillars because the power resides with the people, and the three pillars work for them.

It is important to note that the Constitution defines the duty, roles and responsibilities, and power between the Union and the States, as India is a Union of States, i.e. establishing the fine balance between Centralisation and Decentralisation. Without this balance, it is impossible to scale up the governance of such a big country, having a rich diversity of cultures, 1.3B people, different religions and roots in ancient civilisations.

🏨 Guardrails: Organisational Beliefs

British Telecom has a 178-year history, employs over 100,000 people, and operates in 187 countries. 

A code of conduct for all BT employees and principles is established within the Digital area. It is impossible to scale and establish the right culture unless these are defined and agreed upon by the citizens of the organisation.

👴 Guardrails: Personal Beliefs

The three guiding principles in my life of which are constructive.

❤️ Speak Truth (First Person)

Speaking the truth means being true to myself. This ensures that I am always consistent with my responses and do not have to think about them.

🤗 Love (Second Person, Singular)

Loving everyone individually and treating them the way I want to be treated.

♾️ Compassion (Third Person, Plural)

Compassion is for the third person, and it is plural. It is about being kind to everyone as a group.

The other three principles are contrarian and instruct me on what to avoid doing. This is specific to me and my way of life; there is no right or wrong.

🍾 Do Not Intoxicate

Trying not to drink alcohol.

🍗 Avoid Meat

Do not eat anything that is not plant-based, except milk and honey. It’s more like a way of life I’ve grown up with.

🎲 Do Not Gamble

Don’t gamble, and don’t do anything that has to do with gambling. So far in my career, I haven’t worked for any company that deals with gambling.

What are your personal and family guardrails? I would love to hear from you!

Guardrails: IT Architecture, Data and Analytics

As an Enterprise Architect, this is a great topic that is close to my heart. I promise to write in detail about the guidelines for data and analytics in IT architecture. This will include figuring out where to begin, how to define, and giving an assessment of the maturity model for data architecture guardrails.

Coming Soon!

The MUTE Point

Data and AI Transformation: Change in Leadership

When joining Teams, the microphone is automatically muted in meetings with more than a specific number of participants. Do you find it frustrating, or is it the right feature?

I was working on a large transformation programme in 2010-11. We were a tightly knit group of 60-70 architects and transformation specialists in a secure room with restricted access. We were planning and implementing one of the National Health Service’s largest data transformation programmes. A new gentleman, Gavin Mander, entered the room and began sitting in one of the large spaces where we used to sit. After a few weeks, the gentleman could still be seen sitting in that corner daily, but he was now frequently seen talking to our Program Director, Chris Leary. A change in leadership was soon announced, and we were all made aware of the transition period for the two leaders’ handshake.

The leadership team that helped deliver Secondary Uses Service (SUS) for National Health Service. My apologies I was unable to recollect all the names.
Seated on the floor (from left) – Jane Rollings (#2), Jasbir Singh Riyard (last)

Seated on Chair (from left) – Jason Perkins (#1), Mike Thomson (#3), James Ormrod (#4), Gavin Mander (#6), Naren Kamat (#7), Amol Kapote(#8), Adrian Rogers (#10), Mark Carr (#11).

First Standing (from left) – Suhail Kazi(#03), Bhavin Shukla (#05), Roy Taylor (#07), Deepak Thakurdesai (#08), Peter Flynn (#10), Kashif Ahmed (#11), Ketul Savla (#13)

Standing Back (from left): Emma Ross (#09), Chandan Kumar (#10), Henry Walker (#11), Tim Black (#12)

We used to have all-hands meetings, but they were still presided over by our current leader, not the upcoming leader, the gentleman in the corner. We didn’t hear anything about the new leader’s thought process or new ideas; it was business as usual for us.

At the time, my attention was directed toward the more technical aspects of building, and as a result, I failed to recognise the significance of this nuanced but essential lesson. The modifications, the new ideas, and the obvious shift in leadership all took place later, but the transition was smooth, and there was no obvious sign of disruption caused by it.

After a decade, when I joined BT as Principal Enterprise Architect for Data Analytics, I could fully appreciate both leaders’ greatness. After working on and leading numerous transformation programmes, I assumed the role at BT would be no different. I only realised the full scope and complexity of the role after a couple of months. I was fortunate to have Jason Perkins in the organisation as my mentor, who encouraged me not to form or voice early opinions about the current estate and environment and to keep an open mind about the actual cause of the pain points and possible solutions. I was lucky to have such guidance, which helped me lay down the strategy and enterprise architecture that was niche, upcoming and recognised within the industry but was tailor-made for BT. This would not have been possible if I only went forward along with the tools I had in my armour and if I had built early opinion of the challenges and related causes.

This is one of the lessons I have learnt while going through the journey that the MUTE button should be set to default ON for a certain duration while joining a large organisation. For a good result, we should spend more time first listening, building relationships and getting to know people and processes. This will help us develop a strategy and plan that isn’t influenced by our past experiences and looks to the future.

In Data and AI Space, there are several ways to start out as a leader in a new organisation. Even though my thoughts might be true in other areas, my expertise and most of my experience have been in the Data Ecosystem. Here are a few important ones to consider when you join an organisation as a data leader, but this may not be the whole list.

📜Following the Scroll

The incoming leadership believes in the target state specified by the predecessor and comprehends the advantages of achieving it entirely. It is more about enforcing the established concept, which has been difficult and slow to implement. The strategy focuses on adhering to the specified guidelines and enhancing the capability to implement the identified change. This occurs when the organisation is aware of what “good” looks like, and the necessary repairs, but some key individuals or departments within the organisation have not accepted the change. The focus of this change can be limited to those who are resisting it because of their emotional attachment to legacy or because of their own definition of the end state, or to those areas of the organisation that believe the new world will lead to their existential crisis, or to the larger community that does not understand the strategy and direction because the strategy has not been socialised and clearly communicated.

🚦 Turning it Red

Highlight to the leadership that the current state of affairs is unmanageable and the strategy or implementation is either failing or will eventually fail. Changing the current status to RED is one method for managing change. Numerous advantages may accrue from this approach, such as enhanced focus and prioritisation, additional financing for rectification, additional energy to accelerate, cause disruption, and pivot if necessary, etc. This approach has the trade-off of calling into question the abilities and efforts of current and past teams and a baselined strategy. It can lead to uncertainty over the overall strategy, increase the delivery duration, encourage a blaming culture within and across different departments, and leaves a demotivated team.

🎯 Defining the Target State

It is understood that the target state has not been defined, and the incoming leadership has been given the job of defining the strategy, describing the end state, and getting buy-in from stakeholders so that this doesn’t come as a surprise when money is needed. This state is helpful because it lets you start over and understand the organization’s long-term goals. It will need a business case and a clear analysis of the costs and benefits. This kind of reform may take a long time to implement because there isn’t enough funding, and everyone doesn’t agree on what “good” means. It’s a marathon, and the team might lose steam. Also, not all the departments in the organisation would be at the same level of maturity, which could slow everyone down during implementation.

🚧 Removing Roadblocks

This is more of joining when the organisation is in a state of frustration. The change and the work that needs to be done are well understood, the stakeholders have come to an agreement, and the money is there to make the change happen. But the timelines for making this change are unrealistic, causing chaos and frustration in the organisation. The incoming leadership is expected to understand the roadblocks or processes that might slow down the change and educate the senior leadership with realistic timelines or develop alternatives that can speed up the critical processes that are working as the longest pole. This can be fixed by making small changes to the process or adding more resources to speed up the change.

❄️ Resolving Dependencies

This is when one enters an organisation when multiple transformations are taking place at the same time. The transformations of data and analytics are very complicated because they depend on other parts of the architecture, such as Business Architecture, Application Architecture, and Technology Architecture. The data and analytics transformations can’t be seen or done in isolation because other moving parts can cause major rework and might require retrofitting down the road. This can mean that the business case benefits won’t be realised. So, instead of implementing the data and analytics strategy from the Enterprise Architecture blueprint and technology strategy in small pieces, like “Data Analytics modernization,” “Building Data Hub,” and “Enterprise Data Quality as a service,” it is important to first enable the Data Infrastructure and then overlay with end-to-end use cases. The maturity of the architectural building blocks needs to be improved, and the components should be enriched each time. This way, the dependencies and changes across all four pillars of the architecture can be managed and monitored.


One single approach from the list above may not work, and it will require a combination of the above and/or introducing the ones not listed here. But one thing is common to any of these, current understanding and history are required to define the approach to reach the end state.

Joining an organisation is a time of change for both the person and the organisation or team, which takes time. Organisations that bring people in key leadership role need to ensure that the right handoff and handshake happens. This means giving the new leader the original problem statement, the direction taken, and the challenges seen. It is also the job of the incoming leadership to not jump to conclusions about the problems and refrain from providing immediate solutions. False memories and bad experiences from the past, which I have discussed in the seven layers of existence, could change the fate of the organisation. Below are a few take-home points:

  • Not all IT problems have to do with technology or are technically based.
  • History and the people who know how things got to be the way they are and how we reached so far are important to understanding the root cause. Layoffs, redundancy, resignations and change can be done relatively easily within the engineering team but not in the strategy and enterprise architecture function, as it is not just a technical aspect but also about trust and relationships established with the stakeholders. Do not let the people who have lived through and understand the current strategy and problem statement walk out the door; they could be a gold mine for you.
  • The organisation should facilitate knowledge transfer and appropriate handover.
  • Having an open mind when one joins can help the person look at the problem as a whole and makes it less likely to form biases. Scars and experiences from the past are important, but they might not be useful or helpful in the new place. Don’t forget that one moved to a new job because the person wasn’t happy with the old organisation or ways of working in some way, i.e. it wasn’t all roses there. Individuals should not rush to prove themselves in the initial stage of joining the organisation.

Enterprise architecture is about looking at the big picture, researching, and connecting the dots. Building relationships with various individuals and teams is required. The single global currency of relationship and ally-building is “trust.” A certain level of aggression is required to push the strategy through, not as an imposition, but through the element of trust and only by explaining the rationale. Trust takes time to build, so settling in and spending time within the organisation is important before making major decisions and making your opinions known. The Mute Point!

If you’ve made it this far, I strongly recommend you to watch a 5-minute video by Simon Sinek in which he explains why leadership is about consistency rather than intensity and why trust is more important than performance, especially in this role.

Data and AI Transformations: Agility, Scalability and Partnerships

Within IT and business, we work on several transformation programs, which are either to deliver strategic initiatives or to meet regulatory requirements. The strategic initiatives may cater for the medium to long-term business demand or upgradation of technology and platforms. In some cases, it can innovate and help businesses meet their strategy to bring new products to market.

This short write-up highlights the factors that can become important in the overall success of such transformation programs. 

Recipe for success in large transformation programmes:

🦉Agility – wisdom-based journey: 

Even with the best of people, processes and technology in hands, it is not apparent to understand all the challenges at the start. Every organisation and transformation journey is different. We learn as we progress; hence, we should be ready to experiment and be open to opportunities for other routes/alternatives. So that we if have to pivot later, then we can.

🏗️ Build to Scale – Scalability by Design:

We are in a fast-moving world, and hence we need to be agile, where we want to try something quick and check its chances of success or failure. Sometimes, we need to crystallise an idea into a product to be more measurable and tangible. Converting it into a product ensures understanding the actual value and outcome before discarding it. We are well aware of the challenges and success rate of start-ups, where “horses” (the opportunities that the start-up generates) or “jockeys” the founders) can be one that gets blamed. The more significant challenge is not if the idea fails to deliver but if it is a grand success. A successful idea brings more work; if it cannot scale, it can become a bottleneck later. So, build scalability upfront, as this cannot be an afterthought.

✍️ Partnerships – Conscious Team: 

The partnerships have to be big and bold. There can be several factors to help us choose partners, e.g. cost, SME knowledge, reputation, future roadmaps and ambition, etc. When selecting our partners, we must be cautious about how much we trust and rely on, as true partnerships are generally not proven until the first disagreement. We do not need Dream Team; what is required is a Conscious Team.

When we look at the transformation, we must consider our strengths and weaknesses. Focussing on our strengths can help us understand how we are different and unique from others. The recognition of strength can give real purpose. It can become the fabric to join the organisation’s people to achieve the transformation outcome.

It takes us to introspect; what is unique about BT?

BT is unique in many ways, but in the above context and from the area I lead, i.e. Data and AI perspective:

  • 🏰 The company has a rich heritage of more than 176 years. We know how many start-ups come and go. It would not have been possible for BT to be in business for these many years if it did not continuously reinvent itself. We must not stop reinventing and innovating further.
  • 🤝 To be a leader in the business, the company has to be a Trusted Provider. From an IT perspective, this comes only if the data and system are secure. We need to ensure that the trust that our customers have put in us so far continues in future as well.
  • 💲 Profit can take us only to a certain level, and we need a purpose to achieve more for the transformation. We must ask simple but difficult questions, are we addressing the most critical challenge for society? BT’s vision is clear – “We connect for Good”. BT plays one of the most vital roles in laying down the country’s infrastructure by helping to connect.

After listening to Matt McNeill (Google) last year, I was inspired to write an article on this topic during a BT-Google knowledge-sharing session. The above article is my personal view and wisdom developed while leading large-scale data transformation programs. I currently lead the Enterprise Architecture function for transforming and modernising BT’s data and analytics, which has helped me understand the importance of agility, scalability and partnerships.