GSMA/LF Networking Anuket - Reference Models

Lets start with a couple of quotes:

• "Many companies attack the enterprise architecture excercise with lots of drawings and analysis of both existing and hoped-for systems capabilites.  ... While the architecure for a new building is captured in blue-prints, enterprise architecture is often represented in principles, policies, and technology choices. Thus the conept can be difficult for managers to get their arms around. We have found that a simple picture, which we refer to as the "core diagram" helps managers debate and eventually come to understand their company's enterprise architecture."

This is an "oldie" taken from "Enterprise Architecture as Strategy". The reason I am referencing it, is due to its statement of the value of a  "simple picture" and "core diagram".

This blog is broadly about "models" and why they are valuable (some don't even get out of bed for less than $10,000 a day ;-) ). The examples are primarily taken from work I contributed to the "LNF/GSMA Anuket Reference Model".

Status: March 2023 - Writing done, now reviewing.

Models, Work and Value

It is always good to have a clear understanding of subject at hand, so from the Oxford Dictionary.

Model (noun) - via Oxford on iPhone:

• a three-dimensional representation of a person or things or of a proposed structure, typically on a smaller scale than the original
• a thing used as an example to follow or imitate
• a simplified description, especially a mathemetical one, of a system or process, to assist calculations and predictions
• a person employed to display clothes by wearing them
• a particular design or version of a product

If your an architect of "things" (buildings, systems, towns, enterprises), then you need to be a modeller.

The reason for modelling (confirmed via ChatGPT ;-) ) is that it:

• is Essential for Understanding and Communications - I put these together, as it could be that a person has a complete understanding and the only model is the one that they maintain in their head, but if they want to communicate and share that understanding or get input into whether their model is correct then it has to be communicated and so the model moves from idea to artifact or object. Which leads to ...
• is Essential for Analysis - once formulated and communicated the model supports analysis and can be used to validate and test whether the real system will behave and perform as expected and importantly the analysis includes validation and elaboration of the model itself. The result is an improved (better) model, with broader coverage of scenarios for analysis and in it's ability to support understanding across the target audience
• can Predict - a model can provide direct predication/s. This is distinct from analysis, where the model is an input into a stakeholder/audience prediction rather than a source of prediction. A simple example from Newtoninan physics: v = u + at where v == final velocity, u == initial velocity, a == acceleration, t == time, provides a prediction (proven many times over, in its domain) of the velocity that an object will be moving at after acellerating for some time.
• is Economically Prudent - it is cheaper and faster to first create and validate via a model than via the real thing.  However be aware that only the real thing can be used to determine if the model was correct or not. This is evident with every systems investment, where you will need a model of the goal, a model of the cost and a model of the timeline (plan). Without these very few (or should I say a vanishingly small number ;-) ) will be provided funding to go from model to realisation.

These points get to the value of a model (and indirectly to the value of doing architecture).

In the realm of IT Architecture, Enterprise Architecture and Business Architecture, what are the common characteristics of models:

• Invariant Models - these are models of domain which are invariant within a domain and the same model is used across multiple organisations and instances. Well know examples include TMF Open Digital Architecture  (ODA) (Telco) or the BIAN (Banking Industry Architecture Network) Models (Banking) which are Enterprise Architecture Industry Models and the "Canonical Web Architecture" for a generalised view of Web Application Architecture. As the model is  invariant it is very useful for: analsysis of relative performance across cases, as a starting point for understanding and realisation of specific implementation and for analysis of implementation alternatives (option definition and selection). While at IBM, I was co-author in definition of BizADS (Business Architecture Description Standard), which aimed to define a model for the general description of business. This was another example of an invariant model, starting with generic demand and intent and executing a plan, transform and operate cycle:

• Specific Model - these are models which are specific to an organisation or particular implementation. The focus here is to help understand and communicate the specifics of a particular organisation or systems. This is the type of model that is shown in the case studies of "Enterprise Archtecture as Strategy" (quoted at the beginning of this blog) "core diagram". Here is an example for "bitCo". The aim was to distill: its ownership and publicly stated charter and the key business measures against this, the product BitCo sells and its go to market model, as well as it key suppliers and partners:

• Scope, Focus & Abstraction - there are a common set of modelling tools that are used irrespective of what is being modelled. This includes process and data modeling. Case in point is UML (Unified Modeling Language) based tools for systems implementation models as well as enterprise and business domain modeling (both TMF ODA Telco and BIAN Banking Models use UML). The difference is scope and focus.  The opening quote says: "While the architecure for a new building is captured in blue-prints, enterprise architecture is often represented in principles, policies, and technology choices". Many times I have seen "Solution Architecuture" (& hence modelling) as being equivalent to "building architecuture", while "Enterprise Architecture" is more akin to "Town Planning" and using "Building" architecture as metaphor for Enterprise Architecture indicates lack of understanding. I choose to disagree, there is a common set of tools and techniques across all these architecture endevours. The important aspect is to have clearly defined scope and focus and a well understood level of abstraction. With the Anuket Storage model (covered below) the scope is a particular technical sub-system, while for Multi-Cloud Interaction focus is cross-organisation / cross-cloud boundaries and hence at a much high level of abstraction. Both have common attributes.
• Formal and Informal Models - A formal model is one that compiles to some specification and typically is supported by a tool, which can enforce syntax of the specification and extract some of the semantics from the model. An informal model is made from an arbitary set of elements and there is no enforced layout/connectivity and the meaning is in the eye of the beholder. I would love to only work with formal models, so that I could also use the model as basis for tool supported analysis, round trip engineering and prediction. There is one problem though.... typically formal models are the domain of modelling experts and are not greeted with the same positiviely by broader stakeholder community. Also when initially formulating an idea and strategy imposing formal approach may inhibit rather then help. So each approach has its merits.
• "Models, Work and Value" - so now we have view of the various types of models, lets cover who they are used by and why they are valuable. The "work" in this is because while you might model a model ship as a hobby the IT/enterprise/business architecture models are typically done for work and are developed and used by multiple stakeholders. Their value is in their utility to these stakeholders. So a model's ability to aid communications and understanding is critical. The (now superseded) IEEE 1471 "Recommendation for Practice for Architectural Description of Software-Intensive Systems" provided an excellent articulation of architectural description which encompassed "stakeholder" and "concern" as fundemental part of the conceptual model. The value of the model rests in its ability to address the concerns of its stakeholders:

So lets now look at some of the Anuket Models, I was involved in defining.

Storage Model

Storage, what could be simpler ?

One of the nice things about using Clouds is that it is simple. One of the things that becomes apparent when building clouds are: the simplicity has a lot of complexity being managed behind the scenes and that the design decision made as part of the build have huge impact of how easy the platform is to manage once in operation.

While working on building a tenanted private cloud solution, I was asked to look at the storage sub-system and the alternate capabilities and way of delivering these. I worked with a number storage subject matter experts, who's job was just storage systems. The result was getting well immersed in the subject. It became apparent that it is very hard to capture the variety solutions and technology easily, there were:

• Layers - physical, operating systems, applications
• Consumption Models - block, file, object
• Characteristics and Qualities - shared, non-shared, performance, reliability, security
• Technologies - the multitude of ways that storage can be delivered and
• Perspective - are we looking this this from consumer or provider persepective.

As with most things "virtual" the entire technical stack then comes back around full circle. So what might be provided by a high level solution at the hypervisor/virtualisation layer gets consumed at a low level physical layer within the virtual machine or for performance reasons the hypervisor may allow cut through back down to the native physical layer. A simple concrete example is that a virtual disk image sits on a file system of the host machine, but is consumed as block storage by virtual machine.

The "General Cloud Storage Model" (section "3.6 Storage") aims to capture these aspects of storage in a way that covered consumer & provider perspectives , that was invariant of any technology while providing a taxonomy into which the alternate storage technologies could be mapped:

The model was refined over a number of Anuket releases (Moselle & Nile). The Anuket specification (section "3.6 Storage") provides:

• model overview,
• example stereotypical storage deployment scenarios (Software Defined Storage, Virtual NAS (or vNAS), Storage for K8S & OpenStack  and even PXE boot storage) as well as
• architectural considerations for provision of cloud storage.

I will not repeat these here, see the Anuket Reference model for details.

The model helped:

• capture the details of storage delivery
• provides a good basis for understanding the multitude of ways that this can be achieved and
• provides a basis for reviewing these and determining which is best approach in a given scenario.

The "General Cloud Storage Model" was third iteration of attempting to provide a Storage model, it has much broader coverage than prior iterations.

Iteration zero and one are various diagrams and a spreadsheet of technical analysis. A generalist architect trying to understand the world of the storage specialist.

The second iteration was included within Anuket as  "Storage for Tenant Consumption" model "Lakelse" release and only covered the tenant consumption and tiering perspective.  This provides a view of the "what" but not the "how".

The target audience for the Anuket storage model is cloud providers and architects. As storage is a foundational part of any infrastructure solution. Having been involved in building a number of cloud solutions it is apparent that the default storage choices do not result in a good outcome in many cases with the result of need to do significant rebuilds.

In general, the data held within an enterprise storage solution is the most valuable IT asset and its integrity and managability is critcal. Currently the total storage capacity worldwide and storage demand is measured in "zetta-bytes":

The impact of this is that the storage systems are getting so large, that the management of the storage and the protection of the data contained becomes more and more difficult, as you cannot simply "copy" data from one place to another. So  if you need to rebuild the storage sub-system, simply moving the stored contents becomes multi-day preparation activity.

So we need to prepare by architecting for our future storage scenarios carefully, which the "Anuket Reference Model" can help with.

As a model it is an example of a:

• Invariant Model - as it can be support analysis of many storage deployment variations
• Focus - is to support understanding and decision making
• Stakeholders & Concerns - Cloud Architects - the options and considerations for provision of storage within multi-tenanted cloud solution, Implementors / Builders of Cloud infrastructure - have clear scope and expection of capabilities that will be delivered by storage solution/s, Tenants - have clear model of alternate storage capabilities that are available for consumption and be able to clearly distinguish and select what best fits their scenario & Product Owner - have clear model of a alternate capabilities, cost and considerations, against which they can establish priorities for funding and delivery.

NOTE: #1: The original Turing machine had an "infinite tape" (see model picture at start of blog)

NOTE #2: Thank you to Mat Devanny from NetApp on the storage education.

Multi-Cloud Interactions Model

The Multi-Cloud Interactions Model:

The impetus for the Multi-Cloud Interactions Model was to address the question, "How could I expand my Cloud offering to leverage external cloud providers and services?".

The question was raised by Product Owner of an internal private Cloud platform who wanted to be able to integrate with and leverge capabilities avaliable from public Cloud Providers (initially IaaS - Infrastructure-as-a-Service capabilities provided by AWS, Azure, Google etc).

The focus of the teams efforts had been almost exclusively with ETSI NFVi style VNF/Application orchestration (MANO - Management and Orchestration) capabilities and the scope of question limited to "Should I consume public cloud using each cloud providers exposed API (AWS APIs for example), use an abstraction layer (such as Apache JClouds) or build my my own abstraction layer?".

A model that outlined overall scope of the problems was needed. The Multi-Cloud Interactions Model took a broader view than just considering application orchestration, covering the overall life cycle, including:

• Commercial Aspects - Accounts and payments
• Technical Aspects - Connectivity, Resource Managemet, Application Mangement
• End Consumption and Use - Catalog and usage transactions/conversations/communications

With the initial framework in place it was then possible to look at different scenarios as alternate instansiations of the constituent parts. This helps with understanding the composability that a set of APIs would need to support.

The model allows illustration of alternate simple XaaS scenarios:

And alternate ways to achieve objective, either through technical means, such using API brokerage to operate across multiple cloud providers:

Or via commercial model such as Cloud Brokerage:

Illustrating these alternate way of achieving ends helps in choosing the right model  for a given organisation and the implications of this.

As a model the "Multi-Cloud Interactions Model" is:

• Invariant - the model is generic and allows definition of specific cases through alternate instansiations
• Informal - the grouping of interactions is by high level classification and not detailed specification
• Focus - strategic to help determine current and future stance and capability gaps
• Stakeholders & Concerns - Cloud Strategist - organisational capabilities and gaps, market offerings and differentiation opportunities, strategic planning and risk analysis.

Within LNF / GSMA Anuket Reference team the next increment for the "Multi-Cloud Interactions Model" will be to map current technologies, standards, open source initiatives and market offerings to help with understanding what is currently available to be leverage, where there are gaps and what existing initiatives might be candidates for endorsement (as per Architecture Reference Model 1 - OpenStack for Multi-tenant VNF management & Architecture Reference Model 2 - Kubernetes for Multi-tenant CNF management).

There is also a desire to bring together the coverage of the "Multi-Cloud Interfactions Model" with the "Infrastruture Life-Cycle Model". As many of the interactions defined in the "Multi-Cloud Interactions Model" are part of the "Operate & Manage" chevrons of the Infrastructure Life-Cycle Model", as well as parts of the iteractions get re-used / re-purposed to support the "Build" & "Provision" part of the infra-structure life-cycle.

These two different views which have some areas of overlapping concern is typical when creating models, as the model inevitably reflects the focus of the author (in these cases myself ;-). So while the interactions was primarily concerned with integration and API requires to operate cloud across different organisations, the infrastructure life-cycle model was concerned with the process of building clouds and automating this and its operation.

Wind Up

Model are not diagrams and architecture is more than models.

The purpose of this blog was to provide an update on some modeling that I have been contributing to Linux Foundation Network / GSMA "Anuket Reference Model". The aim is to help Communications Service Providers (CSP) with the building and operation of Clouds, as these are the platforms that they are already using to build their current and future services on top of.

When thinking about models it is essential to think about the stakeholders and the purpose / concerns that they are addressing.

If you do this then the model will prove its worth.

The model should help in getting alignment and most importantly help reduce risk and deliver the modelled target economically.

Formal and in-formal models both have their place. While the examples here are informal, you can see my blog "an5 - Intelligent Network Design" for a formal model that applies AI to the problem of network design using a network modelling language.

Remember that the model is an intermediate step toward the end goal, so yes love the model (architects tend to do this), but drive toward the goal.

This blog is more about modelling than the actual models, for more information on the Anuket Reference Model go to the LFN  source and GSMA Cloud Infrastructure Reference Model (Currently Version 3). The team would like to hear from people who would like to contribute.

NOTE: I believe this blog post is more informative than the ChapGPT, response to the question of "What is the value of architecture model?".

References & Links:

Enterprise Architecture as Strategy - Creating a Foundation for Business Execution: Jeanne W. Ross, Peter Weill, David C. Robertson (HBA Press - 2006), available to read via ResearchGate

Linda Evangelista - a model,  credited for saying "We don't wake up for less than $10,000 a day."

LF Networking - LF (Linux Foundation) Networking which has: The primary mission (the “Mission”) of the LF Networking Fund (the “Directed Fund”) is to raise, budget and spend funds and coordinate support for open source and/or open specification projects involved with the movement or communication of data on a network (including, but not limited to, data plane, control plane, analytics, orchestration, and automation technologies for enterprise, cloud, and carrier networks, collectively the “Scope”) ..

GSMA - An industry mobile communcations body, historically "Groupe Speciale Mobile" Association - GSMA is a global organisation unifying the mobile ecosystem to discover, develop and deliver innovation foundational to positive business environments and societal change. Our vision is to unlock the full power of connectivity so that people, industry, and society thrive.

Anuket - formed via amalgamtion of CNTT, OPNFV under auspices of LFN & GSMA - Anuket delivers a common model, standardized reference infrastructure specifications, and conformance and performance frameworks for virtualized and cloud native network functions, enabling faster, more robust onboarding into production, reducing costs and accelerating communications digital transformations

"Official Document NG.126 – Cloud Infrastructure Model" - the GSMA published version of Anuket Reference Model

ETSI NFV - the ETSI NFV & NFVi works defined the initial models for Network Function Virtualisation with the ETSI NFVi Architecture providing a key industry reference model. ETSI reference architecture include definition of MANO (Management & Orchestration). Anuket is more focused on implementation.

Zettabyte Era - our alarming data traffice and storage consumption trend.

Storage Supply/Demand Crisis in a Zettabyte World - the growth in storage demand is greater than our ability to sustain supply... better empty the trash.

Model from Oxford Learners Dictonary - my definition come from the Oxford Dictionary on iPhone, it is pretty similar

IEEE 1471 - "IEEE Recommendation for Practice for Architectural Description of Software-Intensive Systems" provided an excellent definition of architecture models covering: view, viewpoint, concerns and stakeholders (accepted in 2000)

Picture: "Univeral Tuning Machine" from: https://web.mit.edu/manoli/turing/www/turing.html with its infinite length tape storage