Value (‘facilitation' and ‘creation’) - Capability ~ Service ~ Enabler

In keeping with the emerging phenomenon of Artificial Intelligence (AI), Enterprise Architects are discovering the need to consider influences from AI agents, AI workflows, Generative Tools, Large Language Models(LLM’s) and Retrieval Augmented Generators, all of which are driving both challenges and changes to organisational Business Operating Models (BOM).

As AI technologies on Software as a Service platform slowly creep into organisational use, as we found with shadow IT, there is an ever-increasing need for stronger oversight and guardrails to mitigate any risks.

Recently, whilst reviewing a low-code AI agent Development Platform and conducting research for my new book, I found myself revisiting the ‘Capability, Service and Enabler’ (CSE) classifications.

Whilst the demarcation of concerns for the CSE’s remains valid, with the advent of new AI capabilities, the gap between services and enablers is getting shorter and now it becomes apparent to revisit the original diagram and show this coupling

Modified Diagram with 'Value' tag introduced
When a notional measure of value is introduced, we observe some valuable insights, especially when we extended to encapsulate both ‘facilitation and ‘creation’.

The ability to classify both services and enablers, with a value indicator, aids and supports risk management efforts, especially where the classification highlights high-value critical components and their impacts.

NB: we are referring to indicators that can be used to prioritise and design durable capabilities and not the associations with organizational workflows or the value chain. 

The illustration below represents a simplified chatbot architecture and used to highlight the split between value creation and facilitation

Basic Chatbot level 0 diagram 

In the above diagram the Dialogue Manager and Natural Language Processing (NLP) engines are classified as value creators. Thus, when planning these two services it would be prudent to propose additional resilience ? which will  be subsequently documented as an additional non-functional requirement.

The ability to assign a notional value becomes critical, especially if the service / enabler is reused or extended across the technology ecosystem.

One of the artefacts from an Enterprise Architecture function is an Inventory of Capabilities for Capability Models, where we now construct a picture of value creators with an option to add weightings with the caveat that these remain subjective.

The standard inventory for architectural artefacts, while kept simple for governance purposes can be extended as shown below. This is something for business architects to consider.

Sample Extract from a Inventory of Capabilities 

In summary, new capabilities can emerge where the boundary is easily crossed or blurred, as with AI Agents. It may be prudent to add a descriptive variable such as value to allow for the governance and prioritisation of resources for these services or enablers.

The above subject warrants a more in-depth exploratory blog, however, is presented for the purpose of illustration only and provides something to consider – hope it got you thinking.  






Location: London, UK

Popular posts from this blog

Solution Design - Table of Contents

Image
  Today’s short blog, the first for 2024, derives from recent work in which I required a classic Table of Contents (TOC) for a Solution Design( SD ) Document/ Artefact. To create this TOC, I began by listing elements one would expect to see in the artefact i.e. primary section headers, which is challenging when you consider the ‘ purpose’ of the document, and  the target audience both of which impact the overall structure of the document. For most artefacts, it would be prudent to tailor the SD to meet the needs and challenges of the specific  problem. For example, a basic SD for a new in-house development may be very technical, especially when the target audience may be the Systems Community ( Developers, Testers, Service Management etc.) and resulting in an artefact with the content and focus on  Component Views(Building Module Blocks) , Deployment Views and the Runtime Operations .  So, when I considered the elements for the SD Artefact I wanted...
Read more

Update

  Thank you for visiting my blog. Having not posted any new content during   2024 I thought I would give a quick update. I have been busy working on Client engagements and developing our new Global Regulatory Directory (GRD) / Sanctions Portal ( www.kyc-data.com ). Having paused work on the   Solutions Architecture Book – I plan to restart in 8 weeks and will be posting snippets throughout the development. Hopefully it should be out in draft and available towards the end of the year. Thanks for visiting and expect some new content soon
Read more

A Basic Non-Functional Requirements Checklist

Image
The following appeared on my previous blog site on January 6th 2014 and received in excess of 16K hits per annum - so reposting on new site.  Earlier today, while reviewing a document I produced some time ago, I discovered a useful Non-Functional Requirements (NFR) checklist and thought I would simplify , ‘repackage’ and share via this blog. NFR checklists are not unique products, they are easily found on the web with numerous examples available for reuse, one such example can be found at the Open Group’s website under the ToGAF Requirements Management section. Most of you are probably familiar with NFR’s – However if not, you can consider them a set of requirements/criteria used during the run-time operation of a system and not the specific behaviours that the system must exert. The NFR’s vary in importance and are usually  aligned to the  context of the system  e.g. Operational Safety could be classed as a NFR, especially when working in hazardous conditions (...
Read more