Skip to end of metadata
Go to start of metadata

The system is designed with many requirements in mind, some of them slightly conflicting:

  • We need user interface that quickly adapts to the needs of specific customer. The user interface should support all the nuances of business logic (e.g. specific edit forms).
  • We need business logic that will quickly adapt to customer's business processes and identity management logic. E.g. we need specific escalations in approval processes, integration with trouble ticket systems, etc.
  • We need stable security model that will enforce consistency of access control policy. E.g. we need model based on Role-Based Access Control (RBAC), Rule Based Access Control (RuBAC) or maybe an entirely different security and policy model. We expect that one (hybrid) model will fit majority of deployments, however, we should be able to adapt or replace the model in extreme cases.
  • We need re-usable provisioning modules that will connect to the external systems (as source, target or both). We do not want to adapt these modules to specific business logic and we want them to be developed independently from the rest of the system.
  • We want object repository that can store data in a variety of storage systems. We want a data model that is reasonably stable, as we want other models to take advantage of that.

Therefore we design the system in a form of layers. The layers depend on the lower layers, but we expect that each layer will be developed with a different dynamics and will address a different concern.

Subsystems

Responsibility

Dynamics

Description

User Interface

Presentation Logic

Changing quickly, easy to change

 

Business Logic

Customer's Business Logic

Moderate changes, easy to adapt

Workflows, approvals, integration with other business processes (e.g. trouble tickets)

IDM Model

Identity Management and Security Logic

Slow to change, open-closed principle

Enforcement of a basic security policy structure, checks for consistency. Some form of automation (e.g. roles), but quite rigid to change outside of the constraints of the model.

Provisioning

Integration Logic

Moderate changes, quickly connecting new systems

Connectors to manage users/groups on target systems, connectors to pull source information. Need to add and replace connectors quickly, sharing connectors with other systems

Repository

Data Storage

Very stable but easy to extend

Storing data of the basic data model and also other (unexpected) data. Basic data model must be very stable (other layers depend on it), but it should be easy to extend.

 

External links

  • No labels