Does this sound familiar?
Enterprise System A has been replaced by Enterprise System B and while the switch went successfully, the stakeholders are hopping mad. The data has issues that were not identified during testing and there are an increasing number of issues being identified. The number of hostile meetings you are being asked to attend are multiplying by the day and the situation seems to be getting worse even though a tremendous amount of effort is being exerted to correct the data.
I encountered a similar situation recently and as I peeled the layers back on the situation to identify the root cause I suddenly came to the realization that the solution architects had ignored Conway's Law.
The master record in this case is shared between departments and Department A only use about 5% of the overall master record for the department's function. The majority of the master record supports the function of Department B. All of the edits in the new solution had to be completed in System C of the diagram below in an attempt to enforce a single source of truth. As the primary users of the data Department B no longer had the ability to edit the data. Since System C did not support the function of Department B it did not have native functionality to support the full master record. Attempts were made to force the data into that system, but it was lacking data integrity and input validation. In addition there were challenges with giving Department B the access to edit within System C.
This lead to a situation where the consuming department was trying to send requests to the department that was now responsible for the edits. As you can imagine the department that was now doing all of the edits had little motivation to make the edits timely or correctly for the other department.
After identifying the root cause and explaining that we needed a solution that embraced Conway's Law the response was, "What the heck is Conway's Law."
For those who are not familiar, Conway's Law is technically not a law but is a widely excepted sociological observation by Melvin Conway. Conway introduced the concept in the paper "How Do Committees Invent?" written in 1967. The observation was dubbed "Conway's Law" and popularized in the seminal book "The Mythical Man Month" by Fred Brooks in 1975. Since that time several studies have been completed by researchers that have found strong evidence to support Conway's observation.
Conway's Law states:
Any Organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
At first glance this doesn't seem to apply to the situation at hand, but when we consider Al Shalloway's corollary to Conway's Law:
When development groups change how their development staff are organized, their current application architecture will work against them.
Taking it a bit further, James O. Coplien and Neil B Harrison stated:
If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture.
Now we have arrived at the problem at hand. The communication structure of the organization is not in alignment with the architecture of the solution. The communication between the departments is expensive due to a high level of friction and until that issue is addressed the uncomfortable meetings will continue and the customers will continue to be adversely affected.
Fortunately, Conway's Law helped us both identify the issue and to design a solution that permanently fixes the issue and makes everyone happy. Andy Oram and Greg Wilson suggest the following corollary of Conway's Law in their book "Making Software: What Really Works, and Why We Believe It".
A software system whose structure closely matches its organization’s communication structure works better (defined broadly) than a system whose structure differs from its organization’s communication structure.
Designing a solution meant we first needed to under understand the organizational communication channels. Then we could create a solution that embraces the communication channels while at the same time enforcing master data integrity and attribute level ownership.
The implementation included creating a microsite and a set of microservices to act as a broker of the data to be maintained by both departments. This solution allows edits to specific attributes by the parties who were best informed. The high friction communication between departments is eliminated and the consumers of the data will be enabled to make timely edits to the master data.
An argument can be made that the overall solution is now more complex to maintain. This is might be true however the benefits of a properly executed microservices architecture is that it is loosely coupled with the systems it interfaces with. At some point in the future when the organization restructures or the enterprise systems change microsite could be deleted or modified with relative ease. The added complexity is offset by the benefits of accurate and timely master data.
