The PMDA Framework functionality enables a flexible management of different model types which are used for:

Each model is classified based on domain-related information from different viewpoints (business, aspects, technical and platform), scope (universe, component and object), levels of abstraction (CIM, PIM and PSM).

To enable the technical structure and dynamics of the Portal, Security, Storage and those of the Arts Exchange Business to evolve independently, the framework classifies and separates models of different viewpoints into four different domain types, which are:

• Business Models used to define the Business Architecture. Examples of Business Models are models which define the Entry Management, Person, Artefact, Tags, Image Store, etc.
• Aspect Models used to describe Aspect Architecture, that is, those concerns which cut across business domains and are generally applicable to business systems. Examples of Aspect concerns are Security (User, and Identity Management ), Reliability, Scalability, Resilience, etc.
• Technical Models used to describe the technical design patterns used to implement Capabilities Services. Technical Models define technical concerns. Examples are UTube, Pages, Menus, Buttons, Actions, Services, Records, etc.
• Platform Models used to describe the platform-specific components used to deploy Capability Services that have been implemented using Technical Models. Platform Models define platform domain components. Examples are Triple-Store, Application Server, Rules Engine, Hosting Server, etc.

The PMDA framework addresses the progressive decomposition required when defining the Arts Exchange Business, enabling models to be contained within other models of the same type. The framework recognises three different types corresponding to three different scopes, namely:

• Universe Models, representing the maximum scope of the Arts Exchange Business, for instance the whole extended Enterprise. The universe models establish a common language for the Arts industry model. A universe defines the enterprise behaviour in terms of constituent components and required interfaces.
• Object Models representing objects, i.e., atomic units of structure behaviour and rules , such as: Person, Artefact, User, Image Store, Tag, Page, Form, Host, Menu, Buttons, Data Repositories, etc.
• Component Models representing intermediate scopes, with recursive embedding/composition (Functional Domains). The component models define domain structure by the way in which they are composed of other component or object models and their relationships. Examples of Component models are (for Business) Entry Management, Meta-Data Management, Portfolio Management, (for Aspect) Identity Management (for Technology) SPARQL Web Pages Services, (for Platform) Any Vendor Platform Components, etc.

Using the classification and segmentation described above, the PMDA Framework enables the envisioning of different types of Capabilities such as:

• Core Capability represents the actions which an endeavour could not thrive without. Core Capabilities are defined by definition models (CIMs). Core Capabilities are implemented using Implemented Services defined by Design Models (PIMs) and deployed using Deployed Services defined by Deployment Models (PSMs).
• Implemented Service represents the mapping between a Core Capability and an Implementation Capabilities (Technical CIM) captured using Design Models (PIMs) .
• Deployed Service represents the mapping between an Implemented Service and a Deployment Capability (Platform CIM) captured using Deployment Models (PSMs).

Based on each Core Capability and its requirements, the PMDA Definition phase delivers the Business Executable Models (Business Definition Models) composed of Business Objects and Components that are used to deliver the equivalent of TOGAF’s Business Architecture.

•  Definition Models (CIMs) specify the logic of a system without showing constructional details using the Parametric Computation Independent Modelling Language (PCIML). A CIM captures a domain’s structure, its behaviour in terms of Finite-state machines (FSM) representing the lifecycles of objects and components, and rules. The Definition Model plays an important role in bridging the gap between subject matter experts (i.e., business experts) and experts in the design and construction of the system (i.e., IT experts). For example, the Business CIMs define the business structure, business lifecycles (statecharts) and business rules, captured using PCIML.

The definition models are also used to define Design Patterns required to create the TOGAF Information Systems Architecture during the design phase using the Technical Definition Models (CIM) and Platform Devices required to create the TOGAF Technology Architecture during the deployment phase using the Platform Definition Models (CIM).

Figure 2 shows part of the Arts Exchange Business Architecture defined using a top-down approach, where the Business Universe CIM representing the Arts Exchange Universe is at the top. The next level decomposes the Arts industry universe into Arts Exchange Organization Structure, Stakeholder Relationship Management (Target Group), Value Chain and External Influences Management Business Component CIM which represent some of the main concepts of this industry.

Figure 2 also shows each sub-domain decomposed into more specialised component or object CIMs. For example, the Arts Exchange Organization Structure Management Component CIM is decomposed into the Business Unit, Job Function, Organization, Location Management Object CIMs. The Value Chain Management Component CIM is decomposed into Entry Management, Meta-data Management, Record Management and Order Capture Management Component CIMs, etc.

Each CIM is defined using PCIML. The definition follows a bottom-up approach where the first CIMs to be defined are the Business Object CIMs which capture the object’s structure, behaviour and rules. Building on this first step, Business Component CIMs capturing the structure, behaviour and rules of components can be defined. Component Finite-State Machines (FSM) are constructed recursively by connecting the previously defined Object FSMs. Finally the Business Universe CIM represents the “maximal component” model.

Using the Definition Models (CIM), the Framework provides views and functionality around:

• domain activity statecharts simulation from States, Actions and Transitions perspectives based on inferred domain resources, services and states taxonomies represented using SKOS;
• graphical relationships diagram of objects;
• definition reporting;
• WBS Definition reporting based on the status of each CIM covered by the Core Capability;
• generation of executable models (Schemas, Rules and Data Models) used for prototyping, usability and data migration tests.

The Business Component CIMs for example, can be defined incrementally over time by different projects, implementing different Business Components delivered by different Core Capabilities.

From a Core Capability perspective, the Business CIMs capture the agents that are responsible for delivering the capability and also the taxonomy of services and resources provided by each capability, as well as the associated business value, business goals and business requirements. The Implemented and deployed services related to the Core Capability are captured in the Business PIM and Business PSM built in the next PMDA phases described below.

The PMDA Design phase delivers Implemented Services, the equivalent of TOGAF’s Information Systems Architecture. It starts by mapping a Core Capability with a particular Implementation Capabilities; the Implementation Capabilities is defined by a technical component CIM also delivered in the PMDA Definition phase.

Continuing the example of Figure 1, the PMDA Design phase extends each Entry Management Business Component constituent CIM with a design specification captured using the respective Business Design Model (PIM).

• Design Models (PIMs) capture the design using the Parametric Platform Independent Modelling Language (PPIML). A Platform-Independent Model (PIM) captures the construction of a system on an ontological level, meaning that the construction of the system is specified without implementation details. A PIM serves to extend the definition of Core Capabilities captured in a CIM which is mapped to an Implementation Capabilities with the design that best implements the Core Capability using PPIML. Each CIM can have multiple PIMs, enabling a Core Capability to have many Implemented Services.

When creating a Business PIM, an Implementation Capabilities must be selected in order to define the design pattern to be used.

• Implementation Capabilities are used during the creation of a new PIM which maps Core Capabilities using a CIM with design patterns defined by a Technical Component CIM. Each Implementation Capabilities is based on one Technical Component CIM which is composed of several Technical Object CIMs used to define individual elements provided by a particular type of design pattern.

In the example of Figure 1, the same method used to create the Entry Management Business CIM is applied to create a Technical Component CIM called SPARQL Web Pages Services, with its constituent Technical Object CIMs which define the SPARQL Web Pages-specific Pages, Classes, Permissions Lists, Reports, Forms, Messages, etc.

When the Implementation Capabilities is created, the schema and rules are instantiated from the SPARQL Web Pages Services Technical Component CIM and its constituent Object CIMs. The SPARQL Web Pages Services Component Schema and rules models are then imported by the PPIML meta-model ontology connecting each model to the appropriate PPIML Construct. For example, the Page is to be connected to the Output PPIML construct, while the Record is going to be connected to the Element PPIML construct.

Figure 3 shows the example of the Person Management PIM created based on the Person Management CIM using the SWP Portal Services Implementation Capability. The Person Application Architecture is then defined, where SPARQL Web Pages Classes and Page of Person is connected with the Person business object definition inside the Person Management PIM. Each Person Technical PIM defines the person canonical model by connecting the business object definition of Person with each Technical Application used to deploy Person type services in the Data Architecture. This enables the integration between Core Capabilities to be defined in the CIM viewpoint and not in the PIM viewpoint as is the case with most integrations.

Using the Business Design Models (PIM) as an example, the Framework provides functionality around:

• Core Capability reporting based on the relationship of Business Architecture to Information Systems Architecture;
• graphical representation of data and application architecture by Core Capability;
• WBS design reporting based on the status of each PIM used to implement the service;
• Generation of application-specific configuration meta-data.

The PMDA Deployment phase delivers a Deployed Service the equivalent of TOGAF’s Technology Architecture. It starts by mapping an Implemented Service (PIM) with a particular Deployment Capability used for deployment; this Deployment Capability is defined by a platform definition (CIM) also delivered in the PMDA Definition phase.

Continuing the example of Figure 1, the PMDA Deployment phase extends each Entry Management Business Component constituent PIM with a Deployment Capability captured using the respective Business Deployment Models (PSM).

• Deployment Models (PSMs) capture the deployment configuration using the Parametric Platform Specific Modelling Language (PPSML). A Platform-Specific Model (PSM) extends the Implemented Services captured in a PIM which is mapped to a Deployment Capability that best deploys the Implemented Service using PPSML. Each PIM can have multiple PSMs, enabling a Implemented Service to have many Deployed Services.

 

When creating a Business PSM, a Deployment Capability must be selected in order to define the deployment components to be used.

• Deployment Capabilities are used during the creation of a new PSM which maps an Implemented Service using a PIM with deployment components defined by Platform Component CIMs. Each Deployment Capability is based on a Platform Component CIM which is composed of several Platform Object CIMs used to define individual services provided by a particular type of platform.

When the Deployment Capability is created, the schema and rules are instantiated from the Top Braid Live Platform Component CIM and its constituent Object CIMs. The Top Braid Live  Platform Component Schema and rules models are then imported by the PPSML meta-model ontology connecting each device to the appropriate PPSML Construct.

Fig. 3 shows the example of a Person Management PSM based on the Person Management PIM using the Top Braid Live Deployment Capability. The Person Technology Architecture is then defined, where the Jena TDB  which has the Person Schema will be mapped to the Person business object definition inside the Person Management PSM. As an example, the set of Person PSMs defines the enterprise database in which Person data is deployed.

Each CIM, PIM and PSM also has properties used for Project Management, such as Allocated Resource, Estimated Effort, Percentage Completed, Target Date, etc used to measure the effort of Deployment.

Using the Business Deployment Model (PSM) as an example, the Framework provides functionality around:

• Core Capability reporting based on the relationship of Business Architecture and Information Systems Architecture to the Technology Architecture;
• graphical representation of the Technology Architecture by Core Capability;
• WBS Deployment reporting based on the status of each PSM required to deploy the service;
• Generation of platform configuration meta-data models.