Design Environment #

The design environment consists basically of:

• a meta modelling platform
• the corresponding Web-GUI environment
• the BPaaS Modeller that is build on top of the meta modelling platform
• interface enabling the access of the design environment

In addition to this common meta model based design envirionment approach, the BPaaS Design Environment has additionally:

• the Semantic Kernel.

The functional capabilities, apart from obviously designing abstract and concrete business process, include visualizing, querying, and simulating these two types of business process. Another offered functional capability involves the transformation of an abstract business process model to a concrete one. In addition, the environment offers capabilities to compose meta-data and to define KPIs in a top-down manner. The actual KPI definition involves 4 main layers: (i) the layer of tasks (e.g., 10 euros per process), (ii) the layer of process (e.g., data in Europe), (iii) the virtual layer (e.g., deadlines posed for particular BP parts) and (iv) the concrete layer (mapping to a specific concrete and deployable business process model) (e.g., response time for particular services realizing BP tasks). A final functional capability involves the semantic annotation of abstract & concrete business process models with ontology concepts from business, IT & QoS/QoB ontologies. (note: I am not in favour of having these four layers as they are right now - I would recommends the following 4 alternatives ones: (a) abstract BP layer, (b) concrete BP layer, (c) service layer and (d) infrastructure layer with just a question mark of whether we go at a higher-level to map to generic organisational strategic (non-functional) goals).

Four main roles are involved in the operation of the Design Environment. The business process designer is responsible for modelling abstract business processes, while the technical business process designer is responsible for the modelling of concrete/technical business process models (possibly out of abstract ones if no automatic transformation is suppored or cannot be performed). The reviewer is a role responsible for annotating business process models and reviewing the business process models defined (note: this is what I understand from the meaning of "reviewer" - someone who reviews the design process and has also capabilities of annotating the models - if the latter can be attributed as a capability of the designers, then I can drop it). Finally, the IT infrastructure designer is responsible for the design of particular services or internal components that might be needed for the realization of the business process under specification and their storage in the service/component catalogue (note: as I understand it here, the IT infrastructure designer is responsible for the glueing between the BP and IT layer by realizing or requiring the realization of particular missing functionality either in the form of a service or component). 

The result of a BP design is a set of models that are made available to the next step in the life-cycle of a BPaaS which maps to its allocation supported by the Allocation Environment. The models produced are the following: (a) a conceptual business process model in any kind of form (e.g., pictures/figures) along with additional information pertaining to the description of the organisation, its non-functional requirements and its main business objectives, (b) the conceptual business process model is the typical form of a BPMN model along with RDFS-based semantic annotations to business & IT ontology concepts, (c) the concrete business process model in BPMN again along with RDFS-based semantic annotations and (d) the definition of KPIs in a language to be specified or adopted by the consortium (can be based on OWL-Q).

When deploying the Design Environment, we can distinguish between the following components to deploy and have operating: (a) a web-based modeller offered in the form of a SaaS or web application which enables conceptual and concrete BP designers to design their business processes, (b) a business process repository which is responsible for the management & retrieval of abstract business process models assisting in the task of the designer to compose a business process out of business process fragments constituting previous design knowledge, (b) an executable business process repository with the similar focus as with respect to the previous type but concerning the handling of executable/concrete business process models, (c) catalogs for services and components responsible for the management and retrieval of the respective service/component descriptions - such catalogs can enable the technical business process designer to find those services or components which can realize the tasks of the technical business process being designed and (d) the KPI repository which will contain the description of well-known KPIs (actually of BP metrics which can be used in forming KPIs as KPIs are regarded as conditions on such type of metrics) (note: need to consider whether the BP repositories stick to the functional aspect or also consider the non-functional one. If not, then the KPI repository could contain these requirements and their mapping to the functional description of the business processes).

BPaaS Design Repository #

The BPaaS Design Repository is a relational database, realising the meta model. Hence, ....

Meta Model Kernel #

The meta model kerne is a model-aware middle ware that accesses the repository.....

Hybrid BPaaS Modeller #

The hybrid BPaaS Modeller consists of...

• BPMN modelling elements
• Additional Cloud releated deployment elements
• Semantic Lifting

Semantic Kernel #

The semantic kernel enables the interface to ontology managemet systems to conceptuall lift the models in the repository. 

This semantic kernel implements the mechanisms of annotating business processes and individual concepts of a business process with ....

Web Modeller #

The Web-Modeller consists mainly of the Graphical User Interface to....

API #

The API provides a set of interaction methods that enables to import or export data through specifically designed interaction channels.

Relevant input / output channels had already been discussed. ....

Component View #

This high level view on the major building blocks can be further broken down into ....

????

Is there any format how to proceed with the descirption of the individual Components ?