Less INK more INQ* please

*Information Nutrition Quotient

Ink used to be the medium of communication and transferring knowledge and emotions. Text, diagrams and drawings. Its been largely superseded by digital images and video.
In the age of AI, we see more and more translation of a brief text into a waffly video. AI generated narrative, random vaguely related backgrounds and AI voice. A paragraph becomes a 7 minute video on YouTube. A click bait headline and we get sucked in.

This is all extremely inefficient.

In machine terms:

• AI’s to generate the script, backgrounds, video and voice were trained on massive data sets in huge data centres consuming lots of power

• AI’s did the generation (once, or multiple times if their driver tweaked things). The text inflated from a kilobyte or so to between 5 and 20 Mb depending upon resolution. It needed to be generated, encoded and compressed

• Then it got uploaded, previewed and streamed/viewed n times. If it got viewed 1000 times, that’s 10 x 1000Mb =10 Gb of network bandwidth and storage. Client systems had to decompress, decode and render it…

In human terms:

• Viewers spent 7 minutes each viewing it: 7000 minutes = 116 hours 40 minutes
  If the viewers were smart and tech savvy, they had their AI summarise it first, so that required some more processing (but many would have got the gist from the summary and not gone on to view it, saving their time)

• The original text could probably have been read in <30 seconds, so wasted time was about 6500 minutes = 108 hours 20 minutes

I contend that the message could also have been distorted quite severely in this process!

Maybe we should just share the original prompt as a LinkedIn or similar post??

I propose a new metric, viz: Information Nutrition Quotient (INQ).

This is the useful information in a message (text, document, model, video) divided by the size of the message and the time/effort required from the receiver to process it (i.e. to successfully comprehend the message). Difficult to measure each of these factors, but the concept is still valuable. Try to encode the maximum useful information in the minimum bulk of message. Remember the ten commandments fit on two tablets, the US Constitution fits on four (large) pages and the entire syntax of Smalltalk on a postcard.

If data is the lifeblood, how’s your heart?

Organisations are paying more attention to data management, often driven by compliance, privacy or cyber security concerns. But simply holding data doesn’t generate value.

We need a thorough understanding of the relationships between data (numbers, text, pictures, audio, video, facts), information (data meaningful to humans: salary, sales, order, invoice, fingerprint etc), knowledge (richly connected data: contextual data, trend data, inference) and wisdom (deep insights, experience shaped). Value increases as we move up this hierarchy. Alongside that, if we are to understand what we have, manage it properly, secure it, use it, integrate it etc., we need meta data: data about data. Where is it from? How is it structured? Who owns it? How much can we trust it? How is it derived? What format is it in? Where do we keep it? How long should we hold it? What are the constraints on its use…

All of the above are complicated by the explosion of data brought on by new forms of data; technology capabilities to capture, store, manipulate, communicate, generate, represent and analyse data and innovative applications. Virtualisation of products and services compounds the problem, as more of what we offer and sell to customers is information rather than physical.

There are more opportunities than ever before to profit from data, information, knowledge and its proper use. But there are also more challenges associated with doing it properly, successfully, reliably and securely. All of these rely upon skills and capabilities. Specifically, we need high skills to understand, analyse, model, design and implement data related products and services. This is the realm of Data and Information Architecture.

Architects also need to understand business requirements, facilitate communication and build consensus, define vision, bridge gaps and scope initiatives. They need to guide projects and solution designers. Crucially, they need to connect the business/conceptual view of data with the logical (application) and physical (database and technology) views. They need to devise, apply and encourage use of good principles to evolve the data and information landscape in positive ways.

Data management is ultimately a business responsibility, but can be assisted by many technical skills, including: maturity assessment, modelling, meta data management, technology architecture, risk analysis, integration design and considerations of security and privacy.
A comprehensive data/information architecture and data management capability is vital to deliver business benefits as well as ensure security, privacy and acceptable risk.

These are all topics covered in depth in our Techniques and Deliverables of Information Architecture intensive online live course from the 7-11th November. See details here.

#dataarchitecture #informationarchitecture #digitaltransformation #bigdata #businessintelligence #bi #datamodelling

Data Models in Business Architecture? Sure!

Many argue that data considerations are too technical for the business and should be the preserve of data and information architects or data scientists. However, current wisdom says that data is a business asset from which we should gain value and strategic advantage. Data ownership and responsibility should vest in the business, with IT being custodians and curators.

How do we resolve this paradox? Simple: its a T-shaped problem. Business Architecture is at a high level of abstraction, broad in coverage, but not detailed in depth. It is the horizontal bar of the T. Information Architecture is like the stem of the T. It has a number of layers of abstraction, including subject areas, conceptual models, logical models and physical models. Alongside those is meta data to map between the layers, cross reference usage, communities, implementations, security, ownership and myriad other concerns.

The overlap between the vertical and horizontal is where data should be in business architecture, as a Domain Model. This is at a conceptual level and includes the concepts of importance to the business. The Domain is the “subject of discourse”, in practical terms, the industry, such as Telecommunications, Retail, Manufacturing, Education or Health Care. The Domain Model should cover all relevant business concepts, but not include any technology specific details, or detailed requirements. It’s the 3000 metre view of data.
It should include: Concept Names, Definitions, Sample Instances, Identifying Properties, Relationships (Type/SubType, Containment, Association, Role). It may contain cardinalities/ratios, but these are not essential. Concepts can be grouped into useful subject areas, such as Finance, Product, Customer, etc. There should be a graphical view and a business glossary. It might be derived from or aligned to an industry reference model.

So what do we do with it? Lots! It is a Rosetta Stone to facilitate accurate communication between business communities and from there to technical communities. It gives us the nouns for our discussions around ownership, sharing, privacy, security, archival, requirements, business rules and more. It allows us to track progress w.r.t. data automation, migration, sharing, security, privacy management and metrics and quality. It facilitates consensus and integration. It helps to prevent duplication and integrity problems. It helps us leverage data as an asset and provides the platform for digital transformation.

#businessarchitecture #dataarchitecture #enterprisearchitecture #conceptualmodel