In the world of software development, communication is key—not just for the success of a project, but for the very structure of the software itself. This principle is encapsulated in Conway's Law[1], which suggests that organizations design systems that mirror their own communication structures. If an organization operates in silos, its software is likely to reflect that, leading to disjointed and inefficient systems. But what happens when an organization takes this law to heart and actively applies it to improve its software architecture? This is the story of how SAP, is doing just that.
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
- Melvin Conway
The Challenge
Big companies, and SAP is no exception, tend to organize themselves in hierarchies with different levels of depth. That naturally creates an organizational “distance” between internal organizations and teams. It is not to say that these companies are designing their hierarchies in the wrong way, but simply that for each way they choose to organize these hierarchies, there will be trade-offs.
At SAP, integration between our solutions and a seamless experience across them demands that these solutions are built following central architecture and technology guidelines, as well as product standards to ensure compliance with processes and regulations.
Adding to that mix, technology consumers (i.e., business applications teams) and technology providers (e.g., platform and reuse component teams) are often organizationally distant from each other.
The challenge here is that the hierarchy and organizational distance can cause misalignments, when designing these central guidelines and catering for the needs of technology consumers as a group.
How can we mitigate that?
Enter Cross-Product Architecture
To lower the chance that stakeholders are left out of important architectural cross-company decisions, SAP came up with a concept which resonates with the Inverse Conway Maneuver[1].
Cross-Product Architecture (CPA) is a working model that creates communication lines connecting stakeholders of different architectural topics, including technology providers and consumers.
Examples of these topics include Artificial Intelligence, Data Architecture, or API and Events, which are more architectural in nature, but also includes topics supporting development practices such as InnerSource.
The topics are represented as Working Groups and their work is divided into Workstreams, i.e., projects.
There are several outputs that can come out of Workstreams, but the most notable are Architecture Decision Records (ADRs) and Frontrunners where the decided target architecture is piloted in customer facing scenarios.
To support this model, well defined roles are described such as the Working Group coordinator and (co-)leads, as well as organization contacts who can be nominated by their respective organizations to ensure a formal representation.
To ensure that the ADRs are meeting the expectations of their stakeholders, they need to pass a well-defined and tool-assisted review process, where the results are kept transparent and traceable, giving the documents their needed legitimacy and authority.
To ensure transparency, the results and roadmaps of different working groups are communicated quarterly on a consolidated report, and working groups are encouraged to discuss their topics and conduct deep dive sessions in open forum calls that can happen at different levels (workstream, working group, cross-working group). Additionally, working groups are expected to track their work in a backlog, and all this information can be found easily from a central landing page in combination with a tool developed inhouse to manage the metadata of working groups and workstreams. Interested parties can register to the workgroup to receive updates.
The initiative is coordinated and facilitated by a central team which also makes sure that the information flows from the working groups to senior leadership and vice-versa, to ensure that work is aligned with the strategy of the company. The operational aspects of the initiative are communicated and discussed frequently with the coordinators and leads of the working groups, to keep it lean and improve it where possible.
In essence the whole initiative is in line with the InnerSource culture and best practices (see https://innersourcecommons.org/), by establishing a well-defined way to collaborate on cross-company architecture topics, with transparency and traceability.
The Results and Benefits
At the current point in time, the CPA working model has 28 active working groups which collectively run over 100 workstreams. More than 50 workstreams have already finished and reached their stated goals. Numerous major architecture decisions have been taken and reviewed successfully across the organization and many frontrunners have validated the feasibility of the concepts in pilot implementations at customers.
What we still must figure out
CPA has so far proven to be a valuable collaboration model, but that does not mean it works without any friction. So, where could we still improve?
First, the speed, or perception thereof. You may have heard the saying “if you want to go fast, go alone, if you want to go far, go together”. Alignment is not for free, and it takes time, but in the other hand, going “rogue” may mean one will have regression or rework if the path taken conflicts with the resulting alignment. Keep in mind that even if we reach an optimal collaboration process, there will still be a trade-off between alignment and speed.
Second, the actual implementation and maintenance of new software that realizes the aligned decisions is out of scope of CPA, so a well-defined model for that is still required.
Finally, participation is still something to improve, as the cross-company alignment work is in competition for resources that also must work on the “local” architecture of their own solutions. Designing a reward system that results in a good balance between these forces is still a challenge.
Wrap Up
In the words of Martin Fowler, “Accepting Conway's Law is superior to ignoring it”, and that is what we are doing at SAP.
With our approach, we are mitigating the inherent silo effect that comes with a hierarchical structure, and building bridges between those siloes with Cross-product Architecture.
We expect that CPA will be long-lived, as the need for mitigating the effects of Conway's Law are not going anywhere, but we also have in mind that this approach requires continuous maintenance and continuous improvement
- SAP Managed Tags:
1 Comment
