Purpose: The purpose of the Business Process Network is to at document a mid- to high-level view of Business Processes and their interrelationships.
Core concerns: The Business Process Network template enables the documentation of top to mid-level processes. The core objects available to model with are Business Processes, Business Events, Business Objects, Business Scope, Information Systems, and different types of connections. Below you can see two examples of a Business Process Network modelled in different styles.
High level process view without business events or connections between processes:
High-level process view where business events and connections indicate a flow between processes, stakeholders and customers:
Relation to other templates: The top-level processes would typically be broken down to one or more levels of mid-level processes. The last level of Business Process Networks can then be broken down to several Workflow Diagrams or Business Process Diagrams detailing the activities contained within the business process
Properties and metadata: The Business Process Network can for example retain the following information:
Description of the diagram
Link to the owner of the diagram
Link to the one responsible for executing the processes in the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
In the picture below you can see the Business Process Network’s properties dialogue window, where the diagrams properties can be viewed and edited:
Purpose: The purpose of the Business Ecosystem template is to enable an organization to understand itself from an outside-out perspective by modelling the environment in which the organization is embedded.
Core concerns: The Business Ecosystem supplies five elements to model with: Business, People, Things, Business Interaction and Business Moment. The Business Ecosystem template should primarily be used for modeling entities outside the enterprise to identify new business opportunities in the form of Business Moments.
Above you can see a model of a Business Ecosystem. The blue areas are Business Moments, where the interactions between People, Businesses and Things create business opportunities for your enterprise.
Relation to other templates: The Business Ecosystem model is based on the Enterprise Design theories and is as such in the same family as the Customer journey map.
Properties and metadata: The Business Ecosystem can for example retain the following information:
A description of the diagram
Link to the owner of the application architecture
Link to the one responsible for the application architecture
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.
For more information: If you want to learn more about Enterprise Design, we have a four-part webinar by Milan Guenther available for viewing. You can also visit Milan’s website, where you can learn more about the Enterprise Design framework.
Purpose: The purpose of the Business Capability Model template is to provide an overview of the of the state and health of an enterprise in the form of its Capabilities.
Core concerns: The Business Capability Model is a simple template that by default only allows for the modelling of Capabilities with the possibility to add notes if needed. The metadata of the Capabilities – such as status and importance can then be graphically displayed in the business capabilities to create a useful overview.
The stripe on the left side to represent Business Importance and two dots representing Business Maturity and Target Maturity. The new design scales better and provides management with a single view of important strategic capabilities with a plan for improvements. Also it allows the business architect to highlight a set of capabilities by coloring the symbol’s background – a widely used technique.
Business Capability model with new symbol design
In the picture above you can see an example of a Business Capability Model. Here the Business Capabilities are grouped in different areas and the status and importance of them are shown by their green, yellow or red colorings.
In this Business Capability Model (shown above), more attributes are shown at the right-hand side of the Capability. This way you can get a more detailed view of the state of your enterprises Capabilities.
Other functionalities: Using the Analysis tool, the information from the Business Capability Model template can generate maturity- and score heat maps, hierarchies, score views, capability contexts, gap analyses, dashboards, and what-if-, impact- and investment analyses.
Relation to other templates: The Business Capability Model is a strategic template and is as such complimentary to for example the Strategy Model and Work Model. It can be used to illustrate a change process going from one set of capabilities to another. A Capability can link to the Business Processes that uses it as well as the resources it employs. This way it can also be analyzed which Business Processes would be affected by the improvement or worsen of a given Capability.
It is easy to update and analyse the capability models via the standard views on the web:
The capabilities in a Business Capability Model can easily be scored and presented in filterable and editable lists via the spreadsheet functionality in e.g. the Properties view
The capabilities can be presented in a Capability heatmap
From the Delivered by view you can analyze and update relations between capabilities and initiatives, processes, applications and information-objects.
Properties and metadata: The Business Capability Model can for example retain the following information:
A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.
The above picture shows the properties dialogue window for the Business Capability Model where you can edit the diagram’s properties.
Note that the Capabilities’ metadata that are exhibited in the Business Capability Model is not further described here as they belong to the Capability object and not the Business Capability Model template.
Purpose: The Business Canvas, is a strategic management and entrepreneurial template. It allows you to describe, design, challenge, invent, and pivot your business model.
Core Concerns: The core elements of the business canvas are framework cells that define a strategic or organizational entities and, if needed, connections between them. The Business Model can be structured any way you wish. The most well know structure of a business model is Alexander Osterwalder’s Business Model Canvas.
The above picture shows a blank Business Model Canvas where each area is represented by a framework cell.
The strategic or organizational entities can then be enriched with an extended portfolio of strategic symbols such as vision, mission, goals, stakeholders, information systems and business processes.
Full content list of the extended portfolio:
Vision
Mission
Business Object
Market
Competitive Advantage
Technology
Competence
Capability
Performance Indicator
Business Function
Business Process
Organization Unit
Stakeholder
Information System
External Entity
Location
Channel
Goal
Opportunity
Threat
Trend
Material Asset
Intellectual Capital Asset
Business Rule
Key Performance Indicator
The picture below shows a Business Model Canvas that is filled out with symbols from the extended portfolio.
Purpose: The purpose of the Architecture Framework template, is to provide an overview of the enterprise, and the context for a diagram, showing where in the architecture and repository it belongs. An Architecture Framework shows the overall structure of the architecture and the structure with which it is represented in the repository.
Core concerns: The Architecture Framework template consists of FrameWorkCells, FrameWorkColumns, FrameWorkRows and LineOfBusinesses. You can choose to model the framework to fit the one your organization is using – QualiWare supports a wide range of architecture frameworks out of the box such as Zachman, TOGAF , OIOEA, EA3 Cube, EDGY, QualiWare EA Framework, and many more.
Below, you can see an example of a TOGAF framework:
Relation to other templates: The Architecture Framework template is used to represent the repository’s architecture in the form of a specific framework. If CXO dashboards are to be created, the Strategy Model should be used instead.
Properties and metadata: The Architecture Framework can for example retain the following information:
A description of the diagram
Link to Architecture principles and project models
Link to the owner of the framework
Link to the one responsible for the framework
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
The above picture shows the properties dialogue window for the Architecture Framework where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.
The resource map viewpoint allows the business architect to create a structured overview of the resources of the enterprise. A resource map typically shows two or three levels of resources across the entire enterprise. It can, for example, be used as a heat map to identify areas of investment. In some cases, a resource map may also show relationships between resources and the capabilities they are assigned to.
Concerns: History of models Purpose: Designing, deciding, informing Scope: Implementation and Migration
The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture.
Concerns: Consistency, reduction of complexity, impact of change, flexibility Purpose: Designing, deciding, informing Scope: Multiple layer/Multiple aspect
The layered viewpoint pictures several layers and aspects of an Enterprise Architecture in one diagram. There are two categories of layers, namely dedicated layers and service layers. The layers are the result of the use of the “grouping” relationship for a natural partitioning of the entire set of objects and relationships that belong to a model. The technology, application, process, and actor/role layers belong to the first category. The structural principle behind a fully layered viewpoint is that each dedicated layer exposes, by means of the “realization” relationship, a layer of services, which are further on “serving” the next dedicated layer. Thus, we can easily separate the internal structure and organization of a dedicated layer from its externally observable behavior expressed as the service layer that the dedicated layer realizes. The order, number, or nature of these layers are not fixed, but in general a (more or less) complete and natural layering of an ArchiMate model should contain the succession of layers depicted in the example given below. However, this example is by no means intended to be prescriptive. The main goal of the layered viewpoint is to provide an overview in one diagram. Furthermore, this viewpoint can be used as support for impact of change analysis and performance analysis or for extending the service portfolio.
All core elements and all relationships are permitted in this viewpoint.
The stakeholder viewpoint allows the analyst to model the stakeholders, the internal and external drivers for change, and the assessments (in terms of strengths, weaknesses, opportunities, and threats) of these drivers. Also, the links to the initial (high-level) goals that address these concerns and assessments may be described. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.
The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more tangible goals, and the refinement of tangible goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship.
In addition, the principles may be modeled that guide the refinement of goals into requirements.
