I was in the US Army. The Chain of Command in the Army (the lines of ownership between organizational units) is sacrosanct because, if you do not know who your supervisor is, people can die in the time it takes a member of an organizational unit to determine who has decision-making authority. Therefore, every leader's first and forever job is to communicate down to their subordinates, making clear that they are in charge of those subordinates, as well as communicating up to their superior, making sure the superior knows they're still in charge (because leaders can become incapacitated, be absent from the battlefield, die, et cetera).
From the Ranger Handbook:
The establishment of leadership relationships results in what everyone is familiar with - a hierarchy of organizational units (led by leaders), which looks like a tree's roots (with the highest leader at the top and the lowest followers at the bottom).
In Service Now, the table of records that appears to be most like an organizational unit is Department (cmn_department). Additionally, Service Now has included a Business Unit (business_unit) table, which appears to be used to show the functional grouping of Departments. After reviewing your line-diagram above (the one with "Legal Entity" at its head), I am concerned that Service Now is encouraging an often poorly executed business practice - the matrix organization. The "Legal Entity" line diagram shows two different Divisions with arrows (what I assume represents "ownership" relationships) pointing to the same Department. This introduces the paralyzing situation of "who is my boss?" It is not an overstatement to say that this is paralyzing - when your competitor or adversary only has to think "ask my boss", while you have to start with "who is my boss", it will lead to the latter organization being outperformed by the former organization.
Now, what the US Army DOES do is this - when a soldier, or a small organization, needs to be utilized by another leader or larger organization, which is not in its current chain of command, then the leader that owns the soldier or small organization DETACHES that element, positively communicating to the other leader that for a set time duration, or indefinite time duration, the other leader has authority over the detached soldier or small organization. The new leader now has the soldier or small organization ATTACHED to their organization. This is so important that the US Army expects leaders to risk their lives, in the middle of battle, to make these kinds of detachment/attachment communications.
So, in summary, consider this:
- DO continue allowing the creation of parent-child relationships between Department (organizational unit) records;
- DO NOT allow two parent Department records to exist for one child Department record, at the same time (there must always be ONE parent Department, for every child Department, at any particular point in time);
- the same should be true for Business Unit records - do allow parent-child relationships between Business Unit records, yet do not allow more that one parent Business Unit record for each child Business Unit record;
- the same should be true for relationships between the two classes of records, Departments (cmn_department) and Business Units (business_unit) - continue allowing Department records to have a parent Business Unit record, but do not allow a Department record to have multiple parent Business Unit records;
- DO consider adding the infrastructure into Service Now to potentially allow indefinite, or time bound, detachment/attachment relationships, in the form of parent Department "detaching" a child Department, to be temporarily (or indefinitely) owned by another parent Department [this may borrow from your implementation of User Delegate (sys_user_delegate) records, but which enforces the rule of only one parent Department at any given time].
