Workflow integration to the model

This page shows how the workflow data maps to the general EasySOA Core model.

Note: before even starting to talk about integration, it would be wise to define the point of the BPM aspect in EasySOA. This definition can be found on page EasySOA and workflow build process (this pages also provides some hints about the vocabulary).

Mapping

As a reminder, here is an up-to-date version of the EasySOA Core model. This mapping is based on the 2012/06/15 version.

• Workflow: System. A workflow can be seen as a functional-level system. The concrete type of workflow may be derived from System, if need be.
• Sub-workflow: System. Sub-workflows are workflows themselves.
• Workflow applicative target: Software. There may be several targets for only one software (when implementing the software using two technologies, for instance one for interactive steps and another for automatic steps).
• Business workflow diagram: Attachment to the wokflow. (Property, content stream, domain-specific object modeled as a RequirementsDocument, ... ?)
• Technical workflow diagram: Same as Business workflow diagram.
• Executable workflow: Deliverable.
• Sub-workflow call: the link between a workflow and the sub-workflows it calls can be represented by "dependencies" in an ArchitectureRequirementsDocument. That means we only represent links between diagrams (to ease navigation), since workflows are not central to our model: services are.
• Activities, Actors, Lanes, etc. (workflow diagram items): not modeled. Details about a workflow are available in a workflow diagram, and users should refer to it, would they need to.
• Connectors: only partially modeled. As EasySOA is mainly about SOA, we focus on services used in workflows (potentially by the means of connectors). This is represented by a "dependency" link in an ArchitectureRequirementsDocument, the same way as sub-workflow links. These links could optionally be modeled by two different types of documents.