"Creating an Operating Model requires an agnostic approach"
There is one question that every DevOps Professional must answer for each change request – what am I going to break?
The time it takes you to answer that question is a good measure of business agility – your ability to respond to change. The analysis work to identify operations and technology dependencies is also central to achieving a high level of Operational Resilience and complying with the EU Digital Operational Resilience Act [DORA: EU 2554/2022].
Change Intelligence is about understanding interdependencies.
It involves an elementary level of detail to allow you identify points of failure and answer the question, what am I going to break?
It is the same level of detail you need to assess a vulnerability that could be exploited during a cyber-attack and ensure compliance with DORA.
A new generation of Change Intelligence Platforms is now emerging to support the complexity of running multiple Enterprise Apps in the Cloud. The leaders in this area provide a single solution to help businesses capture the interdependencies between:
· Standard Operating Procedures
· Reference Data
· Business Rules
· Regulatory Rules
· Architecture Diagrams
· User Stories (Requirements, Version Control, Audit and Release Management).
Connecting the detail in each of these areas to give you insights into what will break is what Change Intelligence Platforms are about.
It is about knowing within a few seconds what user interfaces, functions, views, procedures, reports, system interfaces, email templates etc., will break if you delete a field. Not just those that are directly impacted, the capability to look through code and discover all the objects that will be impacted.
Building an Enterprise grade App requires precision engineering.
To understand the level of precision, we need to go back in time to the most basic principle of automation – it starts with requirements, systems automate business processes.
It requires an appreciation that the objects in a Technology Stack automate process activities in an Operating Model. In the best designed systems, there will be a high level of correlation and explain-ability between activities and objects.
To understand interdependency, we need the highest level of precision. We need to discover the elementary detail – all the task level activities and all the objects, the metadata, in the technology stacks. This cannot be achieved with just a framework – someone must get into the weeds and figure it out.
At an enterprise level, it involves the identification and management of millions of metadata items, each of which needs to be analysed and updated for change. It needs to be co-ordinated across environments – development, quality assurance, production and business continuity. Managing this scale of complexity requires automation – it cannot be done manually.
Creating an Operating Model requires an agnostic approach. You need to think about how a business operated before technology was introduced.
That world was about paper – product catalogues, purchase orders, contracts, invoices, receipts, memos, records, ledgers, reports etc. An operating environment where meticulous attention to detail was a key skill as everything had to be written down. Paper records were indexed, filed, and boxed so they could be retrieved for future reference. A world of activity performed by people with clearly defined jobs to be done.
A world where every activity could be observed and explained, with tangible inputs and outputs. It was easier to understand why and connect each activity to a business outcome.
For most, observability in a world of technology is limited to what they see in a user interface. This results in significant gaps in knowledge.
The Technology Stack for a business application, has four main types of objects:
· Graphical User Interfaces (GUI) objects – data input fields, drop downs, pick lists, buttons etc.
· Functions - Coded objects that accept parameters, perform calculations, and return a value.
· Procedures - Coded objects that manage data.
· Database objects - Objects, consisting of tables and fields that are used to record data.
Data exists in 3 different forms which need to be managed and optimised in different ways:
· Reference Data (One dimension). Lists of unique values – product ID, customers ID, country ID etc.
· Transactions Data (Two dimensions). A record of a transaction – a customer bought a product, for a price, on a date (Online Transaction Processing – OLTP that uses relational databases).
· Analytical Data (Three+ dimensions). The time dimension – insights into what customers bought what products over the past year (Online Analytical Processing – OLAP with cubes of data).
Cloud enables a new design approach.
The first wave of cloud has focused mainly on the development of point solutions. An app for every problem. Many of these apps have been developed with an on-premise mindset, respecting a legacy of functional silos, that pre-date cloud and can act as barriers to delivering customer centric solutions.
Think about the number of process activities that require you to identify a country. In the sales process it is used for shipping, to calculate sales tax and to verify a customer’s identity.
Think about the number of apps that use country data for automation. Transaction data that includes country identifiers. Data that has to be interfaced with other apps and consolidated in analytics solutions.
A second wave of cloud has already started. It is focused on platforms and creating end to end customer focused solutions for businesses. It is about delivering consistency with apps that are designed to work together (not just apps that can work together). It involves important design decisions to standardise reference data, for example the use of ISO country codes, and the discipline to enforce that standard across the platform. It delivers solutions that are easier to interface and removes the translation overhead associated with analytics.
Change Intelligence Platforms provide the transparency you need to understand interdependency, remove a legacy of suboptimal design and enforce new standards.