Microsof Azure Ecore model with core classes, networking, storage, and compute. Currently the model contains only the most important classes and is not well documented.

The metamodel documentation may complement other forms of learning:

• Home page would provide an overview possibly with interactive diagrams¹
• Left navigation provides an alphabetial visual (icons) hierarchical representation of Azure concepts. The tree is searchable and elements have tooltips with short definitions of model elements.
• Generated UML Diagram shows structure and relationships between elements. It may become very big for large models.
• Graphs might provide another visual representation of mdel elements and their relationships:
  • Default graph shows package elements and their relationships using force layout. Elements can rearranged by dragging. Elements have tooltips and double-click on an element navigates to the element page.
  • Circular graph has the same functionality, but uses circular layout.
  • Force graph uses live force layout.
  • Graphs with dependencies - similar to the above graphs, but include dependencies from other packages and elements from sub-packages. Packages form categories and can be turned on and off - this is where the live force graph might be more convenient because it rearranges remaining nodes:
    • Default graph
    • Circular graph
    • Force graph
• Element pages, e.g. Virtual Machine would provide an overview of an element, possibly with interactive diagrams. Ideally, they would literally quote the official documentation - need to get a permission from Microsoft Learn. They would also provide links to in-depth documentation on Microsoft Learn and other sites. Element pages also feature a generated context diagram and graphs, e.g. default force graph. Context diagrams and graphs are smaller than package diagrams/graphs and allow to focus on a particular concept.
• Glossary provides an alphabetically ordered linear searchable representation of the model.

The metamodel documentation as explained above may accelerate learning of Azure concepts. With a plethora of books, courses, and online references its value-add may not justify creation and maintenance of the metamodel. However, unlike many other training/learning materials the metamodel can be customized similar to inheritance in object-oriented languages - a class can be sub-classed and its methods can be overridden. As a mater of fact, this is exactly how it works under the hood - a documentation generation processor is subclassed and its methods are overridden to customize documentation. Example.

This capability may be beneficial for organizations adopting Azure, especially large organizations with multiple groups taking care of different parts and adopting Azure at different pace. In this case there would be multiple documentation customizations with multiple releases organized along the Enterprise Continuum similar to how it is done with, say, Java releases.

Let's assume that there is an enterprise with a central cloud adoption organization "Cloud Services", segments, and multiple development organizations in each segment. In this case:

• The "Cloud Services" organization will take the metamodel and cusomize it by:
  • Hiding (suppressing) model elements which the organization is not going to use at a particular stage of adoption. For example, queue storage may be out of scope for the wave X of aoption.
  • Customizing documentation of the remaining elements. E.g. the generic documentation which explains how to create a subscription via the portal, API, SDK's etc. might be replaced with org-specific documentation which explains that a new subscription shall be created by creating an IaC pipeline in a source repository and then creating a pull request. Or by submitting a request in the internal service management system.
  • Creating flavors of documentation for different technologies
• Segments may further customize documentation to address their specifics, e.g. the legal landscape or segment level technology choices. For example, the central function may provide a choice of cloud databases or VM/container images, and a segment may standardize on a subset.
• Development teams may customize even further. For example, by providing documentation how to deploy components built using in-house developed technologies.

In the above scenario specializations the right of the enterprise continuum may contribute to more generic documentation to the left of the continuum. For example, a segment may create a better way of doing things and the central function may adopt it for other segments to reuse. Another variant - a segment may pilot a new way of doing things and then contribute refinements to the central function. One way to do it is fork/pull request.

Use the metamodel to create a model populated with data retrieved from information systems - Azure, internal systems, ... Create specialized subclasses where needed. E.g. there might be a subclass of Azure subscription with a bi-directional reference to some internal model element, e.g. a cost center. The loading process may read a tag or a mapping Excel spreadsheet to establish such a linkage. Once it is established, it can be used to traverse the model for analysis and reporting. There might be different reports/data formats delivered to multiple stakeholders using multiple delivery vehicles. See Architecture and TOGAF models for additional details. The Azure model may be used in conjunction with the above models. E.g. there might be a specialization of those models where Azure elements such as Subscription and Resource extend Solution Building Block.