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.

Models for Transfer of Perception

Research on physiology of the visual system, neuroscience and cognition shows our perceptions are controlled hallucinations based on predictions, progressively refined by feedback of sensory input.

Perception starts, not with sensory input from the eyes, but with a prediction in the brain. We then look for confirmation of our prediction in the sensory input. Where we detect anomalies, the brain adjusts the prediction and seeks new evidence. This has profound implications for models to share our perceptions.

First, we need to consider the receiver’s world view & experience and their likely predictions, which affect how they interpret what we share. If we can translate our message to a medium, format and notation that corresponds to what they are familiar with, we are far more likely to succeed. For a database designer, using UML diagrams is a good strategy. For a risk manager, this will fail, but they may be receptive to a diagram that categorises information according to risk parameters such as sensitivity to exposure and impact of exposure. It will help if we prime the expectation (and hence the prediction) with defining shared concepts. Ontologies are valuable in providing the nouns for later communication.

Enterprise Architecture benefits from a strong meta model defining the agreed concepts, relationships and properties we deem important that describe instances of the concepts. The meta model and appropriate tools (repository and modeling, query, reporting and visualisation) allow us to collaborate, to share and support multiple formats, notations and frameworks to work successfully with different communities.

The theory of communication (Shannon and Weaver) advocates redundant information in the message and feedback to the sender to ensure that messages were successfully transferred. For visual models, this translates to providing “dual coding” i.e. both symbols and text to facilitate correct perception of the information. We should also query the receiver to ensure they perceive what we intended to convey.

Efficiency can be enhanced using principles from compression of messages (e.g. in transmission of images, audio or video), where prediction is also used to predict what comes next and then to only transmit information if the actual signal differs. E.g. in a video we only transmit the changes from frame to frame, a very small proportion of the full image of the frame. For models, this translates to providing only difference or exception models, or models where the important information is highlighted in some way, by colour, modifying symbols or other means. In this way we have a lot less to encode and interpret. Again, competent tools can assist by providing filters, query, summary and highlighting mechanisms to generate useful outputs, potentially “on the fly”.

We are researching these topics and progressively enhancing our tools and methods at Inspired.org. Let’s connect!

Be a force for good

Give me a place to stand and a lever long enough..

and I will move the world. So said Archimedes, apparently.

When we train you as an architect, particularly a business architect, we are giving you a long lever (= much power). We also hope to give you some solid principles and moral grounding as a place to stand. Architects are change agents.

Be a force for good.

For each change that you propose, ask:

• Which stakeholders will this impact positively? How? To what extent?

• Which stakeholders (and potentially other parties) will this impact negatively? How? To what extent?

• Then try to maximise the good and minimise the harm

• Apply systems thinking to anticipate consequences

• Ensure we are thinking long term and that proposed approach is sustainable

• Try on a small scale (think MVP, prototype, etc. ) to prove concept, benefits, identify negative impacts

• Iterate and improve or pivot before scaling up. Scale when benefits are being realised

• Design and adjust metrics to get desired behaviour

• Involve everyone affected (or at least their representatives) in the design of the future. Those closest often have knowledge that we don’t. They have history of what has been tried. They have ideas to contribute. They need to be on board to help make the change. If roles are affected or eliminated, people need better and significant roles to play going forward.

Context and IQ

Alan Kay is the source of two quotes I love:

1. The best way to predict the future is to invent it

2. Context is worth 60 IQ Points

Many enterprise and business architecture methods advocate aligning with business strategy. This alone indicates that they themselves are coming from another perspective than business strategy! In the case of methods like TOGAF® that is reflecting their history as IT Enterprise Architecture approaches.

We contend that Business Architecture and Strategy are inextricably interwoven. We also believe that the important stuff to worry about when doing strategy is “out there”, i.e. in the context, not internal. We have control over things like organisation structure, process, value stream (to an extent) and capabilities. What we don’t have control over, but which we absolutely must pay attention to in our strategy is the stuff out there, such as competition, legislation, social change, technology innovation, politics and the state of the economy.

It is absolutely vital that we understand our current context and future scenarios for how this will evolve before we choose direction and commit resources. For example, we don’t want to build a new internal combustion engine car model when we will not be allowed to sell it in a zero emissions future city. We don’t want to create a physical store to try to compete in an industry that has gone completely digital (e.g. music), unless, of course we have identified and are happy with a niche audience (e.g. those who prefer buying music on vinyl). We do not want to bring a service to market that legislation will prohibit us selling.

Understanding the context is vital to making sensible choices for future product and service offerings and hence the organisation, capabilities, partners, processes, technology, systems and data these will require. A good technique for considering contextual issues is STEEPLED, which stands for: Social, Technology, Economic, Environment, Politics, Legal, Ethical and Demographics. These are best considered in facilitated workshops exploiting scenario analysis techniques. We may also have to draft in participants with specialist knowledge.

Equally important is understanding all the Stakeholders and how we interact with them. These parties include Customers, Shareholders, Partners, Suppliers, Regulators, Unions, Industry Bodies, Related Companies etc. We like to do a Stakeholder Net Value Exchange (SNVE) model to identify what each party contributes and expects. This can be a brilliant starting point for downstream analysis including business events, value streams, process analysis and information analysis.

If you want more information on methods that integrate these perspectives and techniques, please visit inspired.org. There is also training, the Holistic Architecture Language and tools.

Leveraging Assets

An asset was traditionally something you own which had value or which you could use to derive value. An example of the former would be cash or gold. An example of the latter would be an item of equipment.
We can update this in two important ways:

1. Assets can be virtual or digital, so we could have something like a skill, a design, a patent or a recording

2. We don’t necessarily have to own them to derive value from them

Some of the fastest growing and valuable companies do not own the assets they leverage. Uber does not own cars; AirBnB does not own accommodation; YouTube does not own the content it serves.

Virtual assets, such as a design, can be very valuable. We can profit from royalties, copyright, trademarks etc. without necessarily ourselves making the product or delivering the service. Consider the inventor of the crown bottle cap, William Painter, whose company received a royalty on every cap used for several decades!

Digital assets are also profitable. A music track is recorded once, but can be listed on thousands of websites virtually for free, then duplicated, again virtually for free and shipped to consumers, again almost for free. This can occur millions of times, generating substantial revenues while not parting with the original asset.

The best though, is using someone else’s assets to deliver value. Uber, for example, uses the assets of owners (cars), the assets of drivers (skill and time), the global infrastructure of the Internet (funded by advertising, corporates and governments) and the asset of the user (cell phone) to deliver a valuable and desirable service.

In doing business and architecture planning, it is useful to contemplate Asset Leverage.

First list assets. Look for things that you own, things that you know, things that you know how to do. Try to find things in the categories of physical (e.g. property, stock, equipment); monetary (cash, investments, shares, bonds etc.); knowledge/designs/patents (e.g. books, recordings, designs, models); virtual (e.g. skills, customer goodwill) and digital (e.g. recordings, images).

Next think about assets you do not own that you can leverage. Examples include those of Partners (e.g. supplier knowledge, skill, equipment, stock); Customers (e.g. premises, network, computing, cell phone, time); Investors (expertise, connections); Infrastructure (e.g. Internet, public facilities); other Owners of something you need (e.g. Accommodation, Cars, Images, Location data).

Figure out to what extent you are currently leveraging the assets. Look for opportunities to leverage them to a greater extent. A great deal of value can be unlocked this way. You can find the best opportunities by looking for those assets that can generate a lot of value that you can access with relatively little effort or expense.  

#businessarchitecture #strategy #businessanalysis #digitaltransformation #assets

Satisfied Stakeholders

A stakeholder is someone (person, entity) that has an interest in the outcome of something. An investor in a business is a stakeholder, as are its CEO and its suppliers and its staff members. A sponsor in a project is a stakeholder, as are the people who will use the resulting system and maintain it. Stakeholders have different perspectives, motivations and expectations. Often, we will rely upon stakeholders for things that we want: investment, information, participation, approval, support, resources… So, it is really important to identify stakeholders, keep them engaged and to meet their expectations (within reason and without compromising our own goals).

Another reason to really keep an eye on stakeholders is this: If we are a business, we prosper to the extent that we continue to deliver value to our stakeholders; delivering that value requires capabilities, which in turn rely upon people, processes, systems, data, technology etc. So this guides where we put our focus and what we need to optimise in our business and enterprise architecture.

From a project perspective, our stakeholders are providing inputs (money, information, resources etc.) with the expectation of some desirable change or result (e.g. a new process, product, system etc. ). To produce the outputs that they require, we will need to carry out various tasks, apply skills, resources and effort to produce various artefacts. If we pay attention to what stakeholders need, we can translate that to product models (configurations of deliverables if you like), the tasks required to produce them, and the people, skills, resources and tools needed to perform the tasks. So, stakeholders can lead us directly into good project plans.

A technique we have evolved to rapidly analyse stakeholder interaction is the Stakeholder Net Value Exchange. This puts an enterprise or project in a central “black box”, surrounded by Stakeholder Types (e.g. Customer) & some important independent Stakeholders (e.g. Industry Regulator). We connect the stakeholders to the entity via edges in the direction of Value flow. You can think of these relationships as Stakeholder provides Value to Entity (inbound) or Stakeholder expects Value from Entity (outbound). For a compact diagram, the value can be recorded as text on the arrow. For a richer diagram (where we can start to see commonality etc. and define values more deeply) we put a Value symbol on the flow.

It is really illuminating to see an Enterprise or a Project from this perspective. It is also possible to model more than one collaborating entity this way, e.g. ourselves and a strategic business partner.
More detailed analysis easily ensues: We need to include all the Stakeholder types as concepts in our Domain Model; We can contemplate what Business Events occur with each Stakeholder, what Business Communication results and which Processes support them.

#Stakeholder #projectmanagement #enterprisearchitecture #businessarchitecture

Agile Process or Artefact?

There is much hype around Agile these days. We know that things are moving faster than ever and that “slow business is no business”.

There are agile methods, agile techniques, agile projects, agile best practices, agile coaches and agile certifications. But how many agile businesses are there?

I support the original tenets of the Agile Manifesto and the teachings of the founders. They highlight user involvement, refinement through iteration, communication, flexible working and trust relationships between business and technologists. All good things.

I do have a problem with agile dogma and religion in the absence of other essentials for Agile practices to work. These essentials include: high skill, small teams, continuity of resources, trust and attention to quality and testing. Agile should also not be used as an excuse to bin architecture, requirements definition and documentation.

I often see Agile abused to “crank the handle harder” in development projects in an attempt by business to get to functional goals earlier. The emphasis here is wrong. We don’t need a more pressured process, we need a better result: higher quality (better matching requirements) and more adaptable to future requirements.

Using a building analogy, many Agile projects are “laying bricks faster”. This may be without fully understanding requirements, proper design for safety, scalability and still creating a “fixed” artefact, namely a brick and mortar building. If requirements change, as business evolution dictates they will, another project is required to break down elements and build others.

I suggest we should be building more flexible artefacts. Take a conference centre, which must host a sports match one day, a book fair the next, on the weekend a rock concert and the following week a motor show. We know it has to be flexible and that we won't have time to rebuild. Flexibility is thus a stable requirement. Knowing that, we can design and build for it, even using a conventional construction approach. We can build a shell with large open, reconfigurable spaces, movable walls, power outlets in the floors, lighting on tracks, etc. This will allow the user community to alter the building themselves in a matter of hours.

We need Architecture to identify high level stakeholder requirements and change dimensions and try out conceptual options rapidly, partition elements that can be tackled by separate teams with defined interfaces and then to guide implementation. The construction itself could be agile or conventional. The former offers advantages where some requirements and suitable solutions are not known and need to be tried, prototyped and refined. Using an Agile approach requires high skills, stable teams, continuity of resources as well as a high trust from sponsors.

The solutions should be documented so they are easily used by the operators and maintainable for adaptation.

#Agile #SolutionArchitecture #EnterpriseArchitecture

A Contrary View on Capability

Capabilities are fashionable. Everyone is modelling them, but not always well… And just what is a capability?

Popular business and EA methods use it more or less interchangeably with a “Business Function”, i.e. something we do. I differ.

Capabilities are often listed below a value chain/network to support the delivery of the value adding steps. This is all well and good. Often stated in simple phrases such as “Attract Talent”, “Create Desirable Products”. In this form they are equal to business functions. Less usefully, they will sometimes be stated as nouns, e.g. “Human Resources” or “Accounting”. These are vague at best and equate more to organisational units or departments.

Other methods include goal, process and service modelling. How do we make sense of all these? Are they competing or complementary?

One technique useful for all of them is decomposition - breaking down higher level goals / concepts / requirements to more detail or more concrete ones.

We can decompose Mission into Goals and Objectives; Mission into Functions; Processes into sub-processes and activities; Services into service components, etc. Can they be integrated? Fortunately, yes! Mission, Goals and Objectives are about what we want to achieve, independent of what needs to be done or how. They can provide a starting point for our decomposition. One mission breaks down into goals (broad directions) which break down into objectives (specific, measurable, achievable, realistic, time bounded). Mission (or objectives) can also be decomposed into functions: what must we do to achieve the goals? Functions should have a verb (doing something), an object (to what?) and qualifying clauses (how, with what constraints).

Functions can be sequenced on dependencies to form end to end business processes. Functions and processes can be packaged as services, with providers (who does it?), consumers (who uses it?), inputs (what is necessary to do it?), outputs (what is expected as a result?) and service levels. We need a catalogue of available services, and a designated way to invoke them.

Ah, but what of capabilities? Well, functions, processes, services can all deliver capabilities. A capability implies the ability to do something (function) for someone/thing (consumer) producing a desired result (service/product) at a particular location, with a certain service level (e.g. volume, efficiency, accuracy, etc. ) and potentially other requirements (e.g. in a particular language). To deliver a capability will typically require resources, such as skill, information, application support, infrastructure and physical presence.

There is nothing wrong with defining business functions (proto-capabilities) at a high level below the value chain. We should ensure, however, that they are expanded into full capabilities during later design to deliver all the dimensions required.

#Capability #EnterpriseModelling #BusinessModelling #EnterpriseArchitecture

All Roads Lead to ROME

No, not the historic city. And in fact not all, but few! ROME here stands for Return on Modelling Effort, a term coined by Op 't Land, Proper, Waage, Cloo and Steghuis in Enterprise Architecture - Creating Value by Informed Governance. Springer, 2008.

It is important: organisations spend thousands of hours and millions in revenue building various kinds of models in strategy, finance, enterprise architecture, requirements, solution design and other areas. Often these are useful to their creators, but do not deliver organisational value in excess of their cost.
The problems are often related to appropriateness of models to the kinds of analysis required, accessibility of the models to relevant stakeholders and quality of the models themselves.

Appropriateness relates to the relevant concepts being included, the ability of the models to capture knowledge, share knowledge, support analysis and insights and serve as inputs to further steps. It is also influenced by the appropriate level of abstraction and detail.

Accessibility is related to the representation of the models in ways that are familiar to the relevant stakeholders, ease of sharing and distribution. Architects love complex graphical models, but a business executive might prefer a poster, powerpoint deck or even a story. A financial executive will prefer a spreadsheet or graph. We also need ways to deal with complexity and scale to make them manageable, as well as ways to highlight important insights, rather than overwhelm with volume.

Quality is related to accuracy of gathered information, mapping to the model, fidelity of the modelling techniques and accurate translation to accessible output formats.

Achieving high ROME depends upon a few fundamentals, including: clearly understanding the purpose of the models; identifying and knowing the frame of reference of the Stakeholders in both business and technical domains; choosing appropriate modelling concepts, techniques and representation language that is effective, concise, efficient and precise enough. It also requires sharing outputs (including interim or evolving ones) and engaging various stakeholders positively in the process of model formulation, improvement and evolution.

#ROME #Modelling #EnterpriseArchitecture #BusinessArchitecture #ModellingLanguage