The Living Systems Process Suite development environment offers intuitive drag-and-drop modeling contained within one integrated tool suite. Due to its superior support for application development, the LSPS tool suite uses the Eclipse framework, with the various modeling views designed as an integrated Eclipse perspective.
See the sidebar for information pages on many of individual modeling views.
Process Model Structure
Every process application created with LSPS can be designed as a one-off solution; however, each will more typically take advantage of layered libraries which promote, or potentially mandate, re-use of model elements, templates and patterns.
The essential structure of an application is shown below. All libraries are optional.
Compliance and efficiency often dictate that processes throughout an organization use, or conform to, one or more published templates. These templates can be stored in libraries that can be referenced from process models, with their use either mandated or optional. This improves re-use and ensures uniformity, while allowing differentiation when appropriate. As an example of use, an organization with operations in several countries may enforce that each remote office follow the same core process to on-board a new customer, while allowing each to extend their local process to accomodate specific local regulations.
LSPS allows teams to create and improve process models in a collaborative environment that pools the expertise of distributed business, IT and users during the entire process life cycle.
While the ability to collaborate brings immense benefits, it can also cause delays and confusion if not supported with the right tooling. LSPS is designed to facilitate efficient collaborative model design with social tooling that connects people in a logical and intuitive way.
Integrated support for model versioning with CVS and Subversion repositories.
Difference Comparison & Merge
Powerful tools to compare multiple model versions and merge into a unified master, including conflict resolution.
Automatic Model Refactoring
If an aspect of a model is changed, the entire process application will be automatically refactored to maintain overall integrity.
When a model is saved, its executability is validated, with meaningful warning and error reporting.
Context specific annotations/comments can be made at any point while building and modifying the model to clarify intent.
Iterative Process Discovery
Identifying and modeling an organization's processes can be a daunting task, especially for implicit processes that are held in the common knowledge of a few key individuals. Facing a landscape of multiple departments, applications, and work norms, how should the process of modeling begin?
LSPS is designed with an interface that encourages Business and IT stakeholders to work within the model both in real-time and in simulation environments. Using a top down approach, the first step is to model the big picture with a goal diagram identifying what the process does. The next step is to break this down into compartments describing how the process works. It then becomes a build as you go approach, enabling the designers to iteratively build a process, test, expand, and test again. Snippets, stored in the library, can be reused, ensuring that the design is uniform and the effort is efficient. Depending on a company's available resources and need, this can be done sequentially, division by division, or simultaneously within all divisions.
Configurable In-Flight Model Update
Invariably situations occur in the business environment that necessitate changes to a process once it has been deployed and is executing. To facilitate this, version-controlled modifications made to the model in the design environment can be automatically deployed onto executing instances, even without the need to restart already running process instances. To mitigate the risk of updating to a live environment, LSPS includes two safeguards. First, changes are automatically validated prior to deployment. Second, LSPS ensures that process state and context are preserved by only allowing updates to instances whose state will not be violated by the change. This configurable procedure is illustrated below: