IRM incorporates a transactional system, referred to as a MAC, to assist users with moves, adds, and changes, allowing the user to record changes into a MAC Ticket that can then either be accepted or cancelled at some later point in time.
When working in a design mode, a set of objects such as Equipment, Cables and Circuits that form a specific future design requirement can be recorded into a MAC. By undertaking design work using the MAC system, allows the system to generate hardware procurement lists, reserve rack space and ports for future installation requirements. For larger projects, the multiple MACs may be assigned to an IRM
Project, which acts as an umbrella to a group of MAC Tickets.
When working in an operational mode, a MAC can be created to track the set of infrastructure changes required for some administrative activity, like moving an employee from one cube to another. These changes can be made in IRM first under a MAC, then the changes in the MAC can be organized into Work Packages and assigned to different teams or personnel for implementation.
Key elements of the MAC system
Creating a MAC in the IRM user interface simply creates a MAC object within which design changes are recorded into its Change Log. After joining a MAC, all changes are recorded into the active MAC's Change Log. Users with write access to the MAC can then edit the MAC object itself, creating Work Packages and assigning any of the MAC's Change Log entries to them.
Objects that can participate in a MAC include the following:
-
Typed Objects (Equipment, Cables, Software, Circuits and Pathways)
-
Helper Objects for Equipment and Cables, specifically Ports, Slots and Plugs.
-
In order to hold down the size and complexity of the MAC system and to match the needs of most IRM customers, only objects that represent physical item instances participate in MACs, such as:
-
-
-
-
-
Note: changes to Types and Categories definitions are not recorded into the Change Log.
A single object can be involved in at most one MAC at any point in time. When any object is changed in any way under a MAC, the object is cloned. The
frozen clone cannot have its state altered in any way. The
Live Object is used for everything, until the MAC is closed out in some fashion.
The benefits of this cloning system include the following:
-
allows a MAC to be cancelled or rolled back removing the live clone without affecting the original frozen clone object.
-
many MACS can be open concurrently without impacting system performance.
-
IRM users can easily switch between working on different MACs.
-
IRM users can visualize and run reports against all of the changes made under MACs.
The following rules provide additional insight into how the MAC system works:
-
If a new object is created under a MAC, it is a live clone, but in this particular case, there is no corresponding frozen clone.
-
If a MAC is completed, the live clones are put back in the non-MAC state, and frozen clones are deleted.
-
If a MAC is cancelled, the live clones are deleted and the frozen clones are put back in the non-MAC state.
-
When an object gets involved in a MAC, it is "locked" in that MAC until the MAC is committed or cancelled, meaning the object cannot be removed from the MAC.
When an IRM user opens a MAC (either by create or join), a MAC ID is displayed, indicating the user's client is put into "MAC mode". This MAC ID is passed back to the IRM server with every state-changing request involving participating objects.
Modifying a MAC object
If a user tries to modify an object that is currently in a MAC but that MAC is not the Active MAC, then the user is prompted to Join the object's MAC to complete the change:
Note: any operation which attempts to modify objects in two different MACs is not allowed, to guarantee that the system remains in a consistent state.
In contrast, users have the ability to set lifecycle state for Areas to "Under Change Control", which means that it is only possible to Add, Edit, Delete or Change objects in the Area within a MAC Ticket. This way, Areas cannot be accidentally changed without a record of the change being made. The purpose of this feature is to provide Users additional administrative control, since setting that Lifecycle stage avoids users making accidental changes without first invoking a MAC.
An implication of being "Under Change Control" is that changes which are not controlled by a MAC, such as decorative drawing object changes, cannot be done.
