The method is a step-by-step guide that navigates LVD on the landscape. The method is an iterative approach that starts by modelling the Vision and mission definition and ends with modelling the deployment platform.

Envisioning: Vision to Capability Map

The Vision and Mission

The Vision and the Mission set the foundation of the enterprise: the enterprise exists to accomplish the Mission, and thereby actualize the Vision.

Objectives

The first task of the Business Engineer is to analyse the Mission to identify specific, practical objectives that embody the elements of the Mission. These objectives have two aspects. On the one hand, they are the foundation of action. However, since it is not possible to achieve all of them at once, they are subject to priority decisions, and so they also embody the foundation of Governance (see The GODSModel).

Usage Scenario

Next, we illustrate each objective by developing one (or more) usage scenario showing the objective achieved.

Larry Snowden is a woodcarver. He produces small useful objects carved from roots and other complex-shaped pieces of timber. He has decided to try out the Art Exchange and sets out to “publish” some of his works there. He starts with a Wooden Owl.

He accesses the Art Exchange web site. The home page offers the options to log in or to join the Art Exchange as a new “Artist”.

He selects the New Artist option; this enables him to create his artistic profile and provide a User ID and Password. After submitting his details, he is prompted with registration confirmation.

After clicking OK he chooses the option Publish from the main menu. Before uploading a photo of his work, he is prompted to submit a number of tags to classify his work.

Given the special nature of his work, he finds that the available tags are insufficient, and he selects the Add Tag option to specify “root carving” as a new tag. The new entry is provisionally accepted, but he sees a message stating “This provisional tag will be reviewed by the curator. If needed, alternative suggestions will be communicated to you”. (This editing mechanism is in place to guard against proliferation of redundant tags).

Having classified his new offering, Larry is invited to upload the photo (which must meet size and resolution specifications); he receives an upload confirmation response and also can see the work as part of his portfolio.

Now Larry has privileged access to the record of his offering. He will be able to monitor who views it, comments made on it, and eventually offers of purchase or requests for quotation.

This provision gives Larry confidence that he remains in control of his works as published on the Art Exchange.

This example of a scenario is introduced here “out of the blue”. In real circumstances, it would result from consultations with (prospective) users: it is important to know from the start that the proposed behaviour of the business will be agreeable to its consumers.

Value Chain

Underlying such a story is a schema of value transformation: a Value chain. Larry expects to draw benefit from his use of the Art Exchange. Other potential users also have their value expectations. In this case, Larry provides an input (his work and his idea on classification), and the business adds storage, security and the means for Larry to oversee and control the life cycle of his input.

This is not the whole story, of course. Larry expects that further value will accrue, in the form of contacts with viewers, recognition, fame (?) and eventually sales. All these elements of value will appear in other scenarios (e.g., the story of a critic praising and publicising the work).

Capabilities

A little reflection shows that the various value chains associated with the enterprise objectives all depend essentially on a way of storing and retrieving the art objects (Artefacts) which are the whole point of the Art Exchange. So we identify the very first Capability of the enterprise: Artefact Storage and Retrieval.

Next we see the need for entering artefacts into the store: Entry Management. Part of the entry process is the adaptive tagging. The need to evolve the tagging framework over time must be met by another capability: Metadata Management. The need to associate artists and their works securely gives rise to Identity Management (to keep track of persons and artefacts) and Portfolio Management (to enable artists to control their works).

We have identified five high-level capabilities by analysing just one, very limited usage scenario. At this point, we have little idea of the further refinements which may come from other scenarios. We simply make a note of the capabilities as identified, and pursue our scenario analysis.

As the identified capabilities multiply, it becomes possible (and necessary) to recognize relationships and dependencies among them. This eventually leads to a hierarchical Capability Map as illustrated in Figure 3 below.

Strategy: Capability Map to Portfolio

After analysing most of the scenarios and defining the capabilities, the architect and Business Owner (Executive) should establish an approach to Enterprise Architecture development with the following features:

Classifying the capabilities based on the GODS model gives the architect a “Context Diagram” for the whole Business. In this way, the capability priority is defined based on business needs and maturity level that will drive the construction of a heat map.

The heat map is supplemented with strategic and tactical considerations, e.g.:

• Louis-Vijay Dupont (LVD) also strategically expects that the forum is going to pay for itself and the plans to reinvest the profits for maintaining the arts ecosystem.
• Al is going to manage the entire design and integration; however, some of the development work is going to be outsourced on the web with the intention to reduce the time to market.

Using the heat map and additional considerations, the architect and business owner can then come to an agreement on a roadmap and program of work, which should deliver a Phase 1 offering only key capabilities to enable the Arts Exchange stakeholders to be actively exchanging arts and comments with minimum functionality.

The idea is that the revenue generated with Phase 1 would be used to finance the other phases that will deliver the total functionality and support continuous improvements.

Phase 1, therefore, delivers the capabilities defined above; each main capability is to be delivered by separate projects that could be delivered in parallel if outsourced to different suppliers.

Analysis: Capability to Requirement

With a defined program of work, a capability or a set of capabilities becomes the scope, within which the business analyst works with representative users, going over the scenarios, listening carefully to the users’ view of how the system should work, and assembling a wish list.

Taking the Entry Management capability for example, the business analyst identifies the following requirement list:

This list of requirements will again be scrutinised on the basis of the strategy: the result will be to confirm requirements and accordingly redefine and adjust the scope of work of each project.

Definition: Core Capability to Business Executable Model

Each specific project will work with the associated list of Core Capabilities and Requirements. The analyst will start modelling the PMDA Business Definitions Models, which will be used to create Business Executable Models.

PMDA provides Business Analysts or Business modelers with the right tool to capture the definition of “how” a capability is defined and delivered. This tool is called Parametric Computation-Independent Modelling Language (PCIML); it is a meta-model which organises and supports the capture of a business definition (Structure, Behaviour and Rules) as represented in the Figure 5 below.

Armed with PCIML, the Business Analyst (BA) or Business Modeller will model the definition of the business based on the material collected with Business Users via workshops or one-to-one meetings, which has been translated into Objectives, Capabilities, Requirements List and Usage Scenarios.

See the Business Capability Definition using PCIML post for details

Mapping the capabilities to Business Executable Models

At this stage the Business Analyst maps the Business Definition Models to each single capability creating a link between strategy (Capability) and definition (the models used to define it logically) as shown in the Figure 6

Reporting

The resulting domain models such as Entry Management or any of the five object definition models can be printed in PMDA documentation reports that represented the following elements:

1. The business architecture chart provides a view of the capabilities related to the business domains modelled.
2. The domain chart provides a view of the domain being modelled, and the dependencies it has on other domains
3. The business operations and vocabulary taxonomy of each business domains modelled
4. The class diagram which defines the classes and class associations for the domain
5. The statechart diagram which defines the states, events, and state transitions for a class or class instance.
6. The action language which defines the actions or operations that perform processing on model elements.

In traditional Business or Function Definitions Documents we have a series of disparate Visio diagrams and free text which attempts to represent the above elements. In PMDA they are inferred from models that are semantically connected; they evolve with PCIML changes, avoiding the duplication of disparate documents which can easily fall out of sync.

Prototyping the Definition Models (PCIML)

When using PMDA, as opposed to traditional methods, in the end of the definition phase, the entire business logic is “coded” and simulation is possible on all models without any type of development.

With feedback from LVD, who has read all the documentation generated, the Business Analyst uses PMDA to simulate each capability in isolation and within the Entry Management scope. This will guarantee that each capability is correct and consistent with related capabilities.

PCIML also enables configuration, simulation, constraints validation, etc by execution of an inference engine on any definition model described.

PMDA provides the Business Analyst the ability to simulate each transition step by step. It displays the Model Operation and Resources Taxonomy. The state transition simulation can be based on the State, Operation or Filter. The Business Analyst can also navigate through the Things relationship graph and create different types of diagrams.

After simulation of the transitions, the Business Analyst will want to simulate the rules and validate them against available data extracted from arts lists acquired by LVD.

Creating Schema, Rules and Data Models

Using the simulated Definition models, the Business Analyst uses PMDA to create one schema model, one rules model and one data model for each definition model, where he can test the data input and rules at the level of each individual object (Person, User, Tag, etc) and also at the level of the Entry Management Component.

PMDA also provides a default data modelling editor and many methods for loading data into the data models.

NOTE: The main improvement PMDA brings over existing tooling is this:

At the end of definition phase, the business definition models capture the entire business logic while remaining agnostic of technical design.

Design: Capability to Service Implementation

The design phase is when LVD (Business Owner, Business Analyst), Al (Solution Architect) and a freelancer (Developer) will start using the best “form” available in a web portal to implement the Entry Management Capabilities as View Services and Portal Widgets.

PMDA provides Solutions Architects, Developers and Business Analysts with the right tool to capture the design of “how” a capability is implemented. This tool is called Parametric Platform-Independent Modelling Language (PPIML); it is a meta-model which organises and supports the capture of a business design using a particular Implementation Capability.

Therefore, after the Core Capabilities are logically defined using Business Definition models and PCIML, Al (Solution Architect) involves a freelancer (Developer) in order to work on the design of services that will to support those core capabilities which require some kind of technology implementation.

In the design phase, LVD and Al will design the way the Arts Exchange should look like, in other words they will define its “form”.

Following the business definition and guided by Al, the freelancer develops portal widgets that deliver the implementation capability required by the Arts Exchange Phase 1.

LVD’s vision is founded on enabling stakeholders such as Artists, Critics and Public to collaborate using an arts forum in the form of an internet Portal.

The entire portal and widgets is developed using SPARQL Web Pages (SWP). SWP is an RDF-based framework to describe user interfaces for rendering Semantic Web data.

The portal widgets are constructed to be generic and fully configurable by meta-data parameters used to render and display a widget independently of its functional domain. The portal widgets are also compatible with the ESTCA transition engine, capable of communicating using events and using the SPOP protocol.

The separation of the implementation capability from the business logic definition is essential in enabling the business and technology to evolve separately.

During the design phase, these widgets are used to design the Entry Management Business Design Models such as the Person and Artefact models that store the design of the related pages, pagelets, buttons, etc.

To connect the portal widget to the business logic definition created during the definition phase, the developer created the PMDA Technical API by simply defining the portal widgets by the means of Technical Object Definition Models (PCIML). The technical models define the configuration parameters used by the portal technology to render:

• Page
• Form
• Button
• Save Actions
• Update Actions
• Messages, etc.

Any portal application such as Sharepoint or platform packages such as PeopleSoft, Siebel, Sales Force, etc; can also be connected to PMDA via the same API. For detail on how to define the Technical API see Post (to be published).

With the technical models defined, Al creates the Web Portal Widget Implementation Capability in PMDA.

With the implementation capability created, Al (the architect) or the freelancer (developer) will create a PMDA Design Model (PPIML) for each definition model such as Person, Artefact, etc using the Web Portal Widget implementation capability.

PMDA design models (PPIML) are used to create the interoperability between each Business Object Definition and the Web Portal Widget implementation specification designing Business Object Design Models (PPIML) specific gadgets such as:

• Person Design Model
  • Artist New Page
  • Artist Search Page
  • Artist Edit Page
  • Edit Profile Button
  • Save Artist Button
  • Artist Search Result Grid
• Artefact Design Model
  • Artefact list Grid pagelet
  • Artefact Detail Page

PMDA pre loads a big deal of the design, however some design configuration is necessary around final layout adjustments, security, rules and templates.

Depending on the level of connection between the technology application and PMDA, prototyping is also available without the need to migrate the Platform Specific Models generated by PMDA in the form of configuration meta-data.

NOTE: The main improvement PMDA brings over existing tooling is this:

At the end of design phase, the business design models capture the entire business implementation while remaining agnostic of platform.

 

Deployment: Service Deployment & Roll-out

The deployment phase is when LVD (Business Owner, Business Analyst), Al (Solution Architect) and a freelancer (Service Manager) will select the best platform available in the market to deploy the Entry Management Implementation Services using compatible platform components.

PMDA provides Solutions Architects, Systems Engineers and Service Managers with the right tool to capture the configuration of the components a capability is deployed. This tool is called Parametric Platform-Specific Modelling Language (PPSML); it is a meta-model which organises and supports the capture of a business deployment using a particular Deployment Capability.

Therefore, after the Implementation Services are designed using Business Design models and PPIML, LVD (The Owner) involves Al (The Architect) again in order to work on the deployment of services that support those core capabilities which require some kind of deployment platform.

The deployment phase, is when LVD and Al configure the deployment of the Arts Exchange portal, in other words define the platform products to be used.

Following the business design and guided by Al, a freelancer decides to deploy the portal widgets using the Semantic Web Platform using the Top Brad Suite that deliver the deployment capability required by the Arts Exchange Phase 1.

LVD’s vision is founded on enabling stakeholders such as Artists, Critics and Public to collaborate using an arts forum in the form of an internet Portal.

The entire portal and widgets is deployed using the Top Braid Suite.

NOTE: Any other platform like open source platform, Microsoft, IBM, etc could also be used. 

The portal widgets are deployed to be generic and fully configurable by meta-data parameters used to deploy different environments that are independent of the widget design. The platform components are also compatible with the ESTCA transition engine, capable of configuring different Agents and ESTCA Engines which communicate using the SPOP protocol.

The separation of deployment capability from the business design is essential in enabling the design and platform to evolve separately.

During the deployment phase, these platform components are used to configure the Entry Management Business Deployment Models such Person and Artefact models that drive the deployment of the related Data Repositories, Schema Repository, Rules Repository, Application Server, etc.

To connect the portal platform components to  the business design created during the design phase, the system engineer created the PMDA Platform API by simply defining the portal components by means of Platform Object Definition Models (PCIML). The platform models define the configuration parameters used by the portal platform to deploy and connect:

• Data Repository
• Schema Repository
• Rules Repository
• Application Server
• ESTCA Engine
• Host Server, etc.

Any portal platform components provided by platforms such as Open source Products, Top Braid Suite, Microsoft, IBM or Oracle can also be connected to PMDA via the same API. For detail on how to define the Platform API see Post (to be published).

With the platform models defined, Al creates the Top Braid Suite Deployment Capability in PMDA.

With the deployment capability created, Al (the architect) or the freelancer (developer) will create a PMDA Deployment Model (PPSML) for each design model such as Person, Artefact, etc using the Top Braid Suite Deployment Capability.

PMDA Deployment Models (PPSML) are used to create the interoperability between each Business Object Design and the Top Braid Suite Deployment Capability configuring Business Object Deployment Models (PPSML) specific platform components such as:

• Person Schema Repository
• Person Data Repository
• Person Rules Repository
• Person Application Server
• Person ESTCA Engine
• Artefact Schema Repository
• Artefact Data Repository
• Artefact Rules Repository
• Artefact Application Server
• Artefact ESTCA Engine

PMDA pre much of the development environment, however the entire configuration can be changed.

Depending on the level of connection between the platform application and PMDA, automatic deployment is also available without the need to manually change or deploy platform components.

Now,  is time to understand the Product supporting the method.