Cloud Architecture Diagram

The QLM user creates a new “CloudArchitectureDiagram” the same way as for any other diagram he/she is used with. Then by opening this diagram for the first time, the user is asked to associate it to the Cloud Provider as on the figure below.

Une image contenant texte Description générée automatiquement

Adding a “CloudGrouping”

As for any symbol, the CloudGrouping Symbol defaults to a base provider’s symbol, then its appearance is aligned with the qualification of this grouping (called “GroupingCategory”).

First the user places a grouping default symbol as on the figure below:

Graphical user interface Description automatically generated

Then the user opens the newly placed GloudGrouping and qualifies it to the appropriate Grouping Category, by selecting within the list of Azure Cloud Grouping Categories, as on the figure below:

Graphical user interface Description automatically generated

Applying the change or saving the changed description of the Cloud Grouping (pressing OK) changes the appearance of the CloudGrouping symbol according to the selected category.

Adding a Cloud Service

When adding and qualifying a Cloud Service, hence defining its appearance, the user will be driven by the meta-model to qualify the service.

First the user selects the “Cloud Service” symbol in the symbol’s palette and places it in the diagram page and gives it a name, as shown on the figure below:

Graphical user interface, application Description automatically generated

The user is asked for defining the Cloud Category of this Cloud Service, as shown in the figure below:

Une image contenant texte Description générée automatiquement

The user selects the appropriate Cloud Category.

Then the user is asked for defining the Instance Type of this Cloud Service based on the selected Cloud Category, as shown in the figure below:

Graphical user interface, application Description automatically generated

The user selects the appropriate Instance Type.

Then the user is asked for defining the Resource Type (if any for this Instance Type) of this Cloud Service based on the selected Instance Type (if none, the user clicks OK), as shown in the figure below:

Graphical user interface, text, application Description automatically generated

The user selects the appropriate Resource Type (if any), then press OK.

The Cloud Service gets its appropriate appearance based on the selected category, instance type and resource type (if any), as shown in the figure below:

Graphical user interface, application Description automatically generated

Relating a Cloud Grouping with Enterprise Architecture elements

Cloud Groupings can be related with specific types of elements of the Enterprise Architectures, as shown in the figure below:

Location
Organization
Zone

The selected element will be inserted in the Relates to field of the previously selected CloudGrouping

Graphical user interface, application Description automatically generated

Relating a Cloud Service with Enterprise Architecture elements

Cloud Services can be related with specific types of elements of the Enterprise Architecture as shown in the figure below:

ComputerService
Computer
Database
DataWarehouse
Equipment
Firewall
InformationSystem
Network
Software
Technology
TechnologyComponent

Graphical user interface, application Description automatically generated

Facilitating analysis and reporting

Diagrams show the relationships between Cloud Services and Cloud Groupings (Services within Groupings and reverse), but it is useful to get this knowledge from the repository without browsing the diagrams and use it within reports.

That’s the reason, the “Cloud Grouping” and the “Cloud Service” templates manage and show these relationships which are computed at close of the diagram combining cloud groupings and cloud services, and at time of opening either a Cloud Grouping instance or a Cloud Service Instance. As these relationships are computed, they are not editable: the user cannot add nor delete such relationships shown in the “Cloud Grouping” and “Cloud Service” templates.

Services contained in a Cloud Grouping

Graphical user interface, application Description automatically generated

Cloud Services grouped within the “Availability zone” Cloud Grouping.

Cloud Groupings containing a given Cloud Service

Graphical user interface, application Description automatically generated

Cloud Groupings containing this Cloud Service instance.

OrganizationMap:EDGY

Purpose: The purpose of the Organization Board is to set up team structures and group people together to realize the capabilities of the enterprise. It divides and organizes our work into roles and responsibilities.

Core concerns: An organization is a complex social structure. People form organizations to collaborate and co-create outcomes they cannot achieve alone without explicit agreements about membership, responsibilities and behavioral rules. Organizations are fractal: they are made up of nested structures (e.g. business unit-department-team) that have similar attributes on each level, such as purpose, goals, capabilities and hierarchy.

The Organization Board is a part of the EDGY language created by the Intersection Group.

OntologyDiagram:OWL

An ontology diagram shows classes, object properties and datatype properties, as well as rules (especially set rules).

Symbols (Classes, Set Rules, Datatypes and Instances) are dragged from the palette into the drawing canvas.

Connections (subClassOf, SetRelation, ObjectProperty, DatatypeProperty and Instantiation) connect the appropriate symbols.

The ontology diagram symbols palette provides the set of symbols and links which are used to graphically represent the ontology:

Class (symbol for a Class which may be automatically colored based on the Class characteristics)
Union, Intersection, Disjioint and Complement (symbols for set Rules)
owlDataType (symbol for defining the data type of a data Property defining a Class)
Instance (symbol for instances of a given Class)
subClassOf (connector linking a Class as subClass to its superClass Class)
SetRelation (connector linking a Class or a set Rule to a set Rule; composite rules can be formalized)
ObjectProperty (connector linking a Class or Set Rule to a Class or a set Rule defining the entertained relationship)
DatatypeProperty (connector linking a Class oa setRule to a Datatype)

owlInstanciation (connector linking a Class or a setRule to corresponding Instances)

As in any QualiWare diagram, connecting 2 symbols is achieved by selecting the connector, then the source symbol, then the target symbol, then giving it a name.

The coloring of the Class symbol is achieved based on the Class characteristics.

A class can be:

A Thing
A standard owl Class defined in the current ontology edited in the currentontology diagram
External to the concerned ontology (the one edited in the diagram)
A rdfs Class
A Resource
A deprecated Class

Since it is contextual to the edited diagram, defining a Class as being external to an ontology is achieved by selecting the classes which are external to the ontology depicted in the diagram copying them and pasting them in the “External Classes” field of the definition template of the diagram.

The same can be achieved for ObjectProperties which are external to the edited ontology.

A same Class (unique in the repository) can be a standard owl Class in the ontology defining it (and appearing pale blue in the diagram depicting this ontology) and dark blue (since external) in possibly many other diagrams depicting other ontologies referencing to this Class.

Same for ObjectProperties.

When closing a diagram, the corresponding Ontology instance (the one which refers to the diagram) is updated. Its contained Classes and Object Properties fields are updated.

The instances of Class, ObjectProperty, DatatypeProperty and set Rules instances edited in the diagram are also updated (see corresponding paragraphs)

MilkyWayEnterpriseMap:EDGY

Purpose: The purpose of the MilkyWayEnterpriseMap diagram is to map the different elements into one diagram, creating a view of the enterprise

Core concerns: The MilkyWay enables you to collect objects of the different facets in the EDGY language in one diagram.

From the center and outwards, the milkyway shows:

the identity elements (Purpose and Story)
the Organization
the architecture elements (Capability and Process)
the Product
the experience elements (Task and Journey)
the Brand

JourneyMap:EDGY

Purpose: The purpose the Journey Board is to promote an empathetic view of the people we are designing for/with and to share insight and data about people’s lives in a narrative scenario form that co-creators can relate to.

Core concerns: A brand is a symbolic representation of our enterprise and its products. It is designed to communicate our identity (especially how we are different from others) and to invoke a set of expectations in people about our enterprise and our products, particularly in relation to people’s own needs and desires.

The Activity Board is a part of the EDGY language created by the Intersection Group.

ContentMap:EDGY

Purpose: The purpose the Content Board is to capture key messages, media and formats used to convey identity, story and purpose to audiences, while setting a consistent ton of voice across formats, media and distribution channels to best engage people.

Core concerns: Content refers to data or information that is communicated between and towards people. It requires a medium to convey the underlying message to its audiences, such as audiovisual media like text, images or video, sound recordings or accessible alternatives. In an enterprise, various forms of content are being produced and maintained, exchanged and promoted.

The Content Board is a part of the EDGY language created by the Intersection Group.

ChannelMap:EDGY

Purpose: The purpose the Channel Board is to get an overview of where and how people interact with the enterprise or each other and make them connect.

Core concerns: Channels are the means of communication between people and the enterprise. They are where moments of interaction between people and the enterprise take place.

The Channel Board is a part of the EDGY language created by the Intersection Group.

CapabilityMap:EDGY

Purpose: The purpose the Capability Board is to Clarify what needs to be done and the assets your people need to do that, while focusing your resources on the right outputs to contribute towards achieving the intended outcomes.

Core concerns: Enterprises strive to achieve their purpose by creating products that feature in people’s experiences. To do so, they must design and realise their capabilities by orchestrating meaningful combinations of people and assets. Each capability produces well-defined outputs for internal or external business use and contributes directly or indirectly to product creation.

The Capability Board is a part of the EDGY language created by the Intersection Group.

BrandMap:EDGY

Purpose: The purpose the Brand Board is to structure, plan and create brand identities, their interrelations, dependencies and expressions (e.g. physical appearance, culture, values, promises).

The Brand Board is a part of the EDGY language created by the Intersection Group.

AssetMap:EDGY

Purpose: The purpose the Asset Board is to build new capabilities from existing assets and knowing your existing assets to build up new ones, to improve capabilities and competitive advantage

Core concerns: Assets are an important concept in economics and strategic management and a central part of finance. Buying assets from suppliers connects the enterprise to its supply chain.

The Activity Board is a part of the EDGY language created by the Intersection Group.