Business Process Ontology

Speeding-up Business Process Design

Jenz & Partner has developed a comprehensive business process ontology, which supports private (internal) business processes as well as public (collaborative) business processes. It allows business analysts to create and maintain semantically rich definitions of business processes.

Ontologies are explicit formal specifications of the concepts and terms in a domain and the relationships among them. No longer are ontologies relegated to the realm of artificial intelligence, but are playing an increasingly significant role in bridging the “understanding gap” between business and IT.

A business process ontology serves two distinct purposes. Firstly, it makes knowledge explicit and allows for knowledge sharing among domain experts and IT people engaged in software design and development. Secondly, since it includes machine-readable definitions of concepts, it serves as a requirements specification from which a number of software artefacts can be generated.

By creating instances from concepts (i.e. classes), a knowledge base can be easily constituted. Hence, the knowledge base can be used for rapid prototyping without having to write a single line of code. Prototyping can be performed by non-IT experts, such as business analysts.

How would this compare to current methods?

The major benefits of the Jenz & Partner approach are:

The entire semantically rich process definition is kept in a single place. There is no need to keep process definition elements scattered around over multiple repositories, created and edited with various costly tools.
Business process definitions are stored in XML, which makes it fairly easy and straightforward to generate process definitions using different syntax (e.g. UML activity diagrams, Event-driven Process Chains etc.).
Cost effective approach, since zero license fee tools can be used.

Our White Paper provides information about how the software development value chain can be simplified. (Download)

For further information about ontologies and their practical use, please see our Frequently Asked Questions document. (Download).

For further information, please contact us at info@jenzundpartner.de

Current Approach	Ontology-driven Approach
Software Engineer-centric (i.e. software engineers do most of the software design work).	Business Analyst-centric (i.e. business analysts define functional and nonfunctional requirements, from which model artifacts can be derived).
Project-centric design.	Ontology-based design, definitions are project-neutral and can thus be used in a cross-project fashion.
Generation of development artifacts from tools (e.g. JBuilder).	Generation of design and development artifacts based on machine-processable semantics.
Generally late validation of design (software product needs to exist at least in a rudimentary fashion).	Early validation of design, since Ontology & Knowledge Base Editors generally support rapid prototyping.
Design and development artifacts are spread over multiple tool repositories, making it difficult to keep definitions in sync.	Single source of control, since definitions are stored in a single place.
Significant dependency on the ability of software design and development tool vendors to survive in a highly competitive environment.	Dependency on tool vendors is reduced, since ontologies are increasingly based on public standards (e.g. RDF, OWL). Business analysts are free to define their own metamodel(s).
Re-use of design is possible in a limited fashion. In general, tool capabilities determine, whether and to what extent re-use is possible.	Design re-use is generally possible. Beyond that, open source ontologies will become available, which also allow for re-use of design.