Creating a Reference Architecture

Problem

As a team grows and becomes more distributed, it becomes increasingly difficult to communicate the company vision across various teams. Not day-to-day work of every team would require thinking about the company product, the problem that is solved for customers, or how all of those pieces come together. Over time, teams get to specialize, become more siloed and fail to understand the bigger picture. We saw this happening when we moved from being US-centric to becoming a global business with a focus on Europe and APACand new products launched across those regions.

Actions taken

To mend the problem, we created a reference architecture for the company. It is a document that takes the form of several diagrams and a narrative around these diagrams and which serves as the North Star showcasing where the company is going. The document doesn’t state where the company and teams are today but is a representation of what we plan to make of the company and its products. It balances being too technical and burdened with technical terminology with being too high-level and resembling an executive-level presentation. It details how our products fit into the ecosystem, which teams fall under different big areas, and how the overall progression will look like.

It took us several weeks to do it. We brought together leaders from different teams to share their input on the diagramming side, and then one person took the lead on writing the narrative. The narrative should be communicated as a story, and help from marketing folks could be crucial in making that story compelling. If the whole process is run well, the final document should be something that will resonate with everyone in the company, from ICs to the CEO.

I think that identifying key individuals in every significant stakeholder’s group who will serve as a voice for that group is critical. The companies struggling with this problem are usually large, and different departments can have conflicting interests as well as visions of where the company should be heading. I would try to ensure representation across the board, which is best accomplished by forming a co-working group that would be willing to spend a couple of hours every week progressing this. The more unison achieved during the process should vouch for better adoption of the document.

Lessons learned

• We developed the reference architecture to point to teams not where we are now but where we are going. This is an evolving, not a static kind of document. Static documents can make people anxious and pessimistic because they look like everything is decided and set in stone. If you don’t speak about evolution, people will not be motivated to strive to get somewhere. Of course, the point is not to get there but to be on the road. But as long as you are moving forward, you are realizing the vision.
• You need to keep up-to-date on this document. Doing it for the first time takes a significant effort but once you did it, you will need a dedicated person to keep it up-to-date. A dedicated person can be a manager, senior manager, or chief architect, but you have to make sure that everyone knows who is responsible for refreshing the document every quarter.