Architecture
Dime.Scheduler is built with performance and scalability in mind. Therefore, it is based on a loosely coupled architecture that separates the main planning application from the connected plugins, which are responsible for interacting with external applications.
As far as the user is concerned, the application consists of nothing more than an application accessible via a web browser. Real-time updates are sent to and from the back office systems, which means users can keep on working on the latest state of the system - eliminating the need to refresh components or pages manually.
As soon as the user has been authenticated, the application will retrieve the profiles and (defaults) layouts and will apply the security filters so the user gets to see a tailored version of Dime.Scheduler. Users and administrators have tremendous amounts of configurable elements at their disposal so it is possible that users will get to see vastly different sets of components and data.
The previous paragraph brings us to a key tenet: it's all up to the users (and administrators for that matter). Dime.Scheduler is used in a wide array of industries where planning processes can vary greatly. Even within an industry it is likely that organizations will have different requirements and planning methods. That is why Dime.Scheduler offers a heap of components - with their own distinct feature set - and lets the users handle the rest by themselves. In that regard Dime.Scheduler is more like a framework than it is an application that defines the way of working.
The story continues when data is synchronized from and to the back office systems: organizations may implement their own business logic and their own (vertical) solutions. Dime.Scheduler ultimately provides the framework and the building blocks for the planning process, it is up to the users to decide how they wish to work.
For the aficionados, this is the schema that represents the overall architecture:
