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