Community Modeling

For each community the five view points are tested (Enterprise, Information, Computational, Engineering and Technology).

On department level more detail is introduced, such as department’s roles, behavior and policy that are the scope of this document.

Individual documents for the departments should be compiled, if this document gets to big to contain it all and introducing the detail on department level, such as participants, process definitions and task definitions.

For each task definitions a corresponding system function is required (in general).

Community modeling as part of the Open Distributed Processing (ODP) introduces five viewpoints and each community should be analyses using each of the view points.

The viewpoints are considered in the industry as simple and complete, covering all the domains of architectural design.

The five view points are:

• Enterprise viewpoint, which focuses on the purpose, scope and policies governing the activities of the specified system within the organisation of which it is a part.
• Information viewpoint focuses on what kinds of information is handled by the system/community and constraints on the use and interpretation of that information.
• Computational viewpoint is the functional decomposition of the system/community into a set of objects that interacts at interfaces – and for this reason enables distribution.
• Engineering viewpoint shows the infrastructure required to support the distribution
• Technology viewpoint is concerned with the choice of technology to support system distribution.

The community is the configuration of enterprise objects formed to meet an objective. Any objective may be refined into a set of sub objectives. A community is specified by a contract, which models the agreement amongst the entities to work together to meet the objective.

As such a contract (service level agreement):

• States the objective for which the community exists.
• Governs the structure, the behavior and policies of the community.
• Constrains the behavior of the members in the community.
• States the rules for the assignment of enterprise objective roles.

Each community object models entity an abstract or concrete thing of interest (e.g. Front Counter, Housing Services etc.). The configuration of the community model is modelled in terms of the way the Front Counter and other departments interact in fulfilling roles, which identify behaviors intended to meet the objective of the Front Counter community.

Behavior is a collection of actions (things that happen), with constrains such as business rules and service level agreements. This level will be modelled in BPI Swim-line models.

A Community Object may be involved in (play roles in) an action in one or more of the following three ways:

• If it participates in the action it is an actor with respect to that action and will be represented as a swim-lane in the BPI models.
• If it referenced (e.g. Mentioned) in the action it is an artifact with respect to that action often modeled as a secondary actor or a black-box in the BPM.
• If it is essential to the (performance of) that action, and requires allocation or may become unavailable, it is the resource in respect to that action. Typically these are forms, but not restricted to forms only.

A role identifies a specific behavior of a department (object) in the community. This behavior is observed as a set of interactions in which departments participate and the relationships between them. In general these interactions are covered by service level agreements to validate the performance against defined KPI.

The modeling of the behavior is done using the Business Process Modeling Notation. Behavior may be structure into one or more processes, each of which is a diagram of steps taking place in a prescribed manner (bound by policies and agreements) and which contributes to the fulfillment of an objective.

To define the scope of this document Community Modeling is chosen, community modeling allows us to group the resources with the same set of goals; as such a community has a set of members, which are resources, an objective which is defined by one or more goals and behaviors.

The sub-communities all have the same goal and that is supporting the community , using policies and documents to allow for the interaction between the communities.

Note: Community Modeling is a carefully defined process and method (not a methodology), in the context of this document only a small part of Community Modeling is used.