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: Software. A workflow can be seen as an "application" whose only specific feature is the way it is modeled/implemented.
• Sub-workflow: Software. Sub-workflows are workflows themselves.
• Business workflow diagram: Attachment to the Software. (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.