In the process of forming a new Architecture Group at Axway, I found myself explaining how this function fits into the overall R&D process and why it plays such a vital role. Designing and building a well-functioning city proved to be a useful analogy.
To me, software architecture is primarily focused on translating the goals and visions of company leadership into an actionable roadmap against which R&D can execute.
It is not overly prescriptive, but provides a set of standards within which all technical teams can operate, knowing their efforts will fit and work well with everything else being developed and planned.
Without this important bridge between vision and action, the individual developer teams can end up wasting time and resources on potentially conflicting solutions, duplicating efforts, or stalled production based on localized rather than company-wide priorities.
SW Architecture as “Zones and Codes” of City Planning
To highlight how this works in practice, we’ll borrow an analogy from how city planning works in the United States. The city planning office takes the vision promoted by the mayor and other city leaders and turns it into a set of codes and guidelines for builders.
Likewise, the architectural group takes the vision promoted by the CTO/CEO office (or the city master plan) and turns it into rules and guidelines (zoning and building codes) that the engineering teams will use when creating product plans (building blueprints) and, finally, building the service.
| Executive/Board | Architecture | R&D/Engineering | |
| 1. CTO Vision or “City Master Plan” | 2. Underlying Systems or “Zoning Codes” | 3. General Guidelines or “Building Codes” | 4-5. Building Blueprints leading to Final Product |
| A master plan recommends how a city should exist in the future (has maps, diagrams, reports, and statistics to support the vision.)
| Zoning codes regulate the type of structures built in each location, how structures interact with the surroundings. | Building codes are for the structure itself: how its physical characteristics affect safety and accessibility. | The plan for construction of a specific building adheres to rules established by the city master plan and relevant zoning and building codes. Within these parameters, the local architect/builder can build their vision. |
Of the 5 steps above, the Architecture Group is responsible for steps 2 and 3. It must provide, with appropriate input from relevant experts and stakeholders, the guidance which enables builders to know what is (and is not) allowed. This ensures their new “building” sits and interacts harmoniously within the overall fabric of the “city.”
This does not exclude the Architecture Group from being highly involved in steps 1, and steps 4 and 5. A vision that’s impossible to implement is not useful and architecture can help guide those decisions.
A blueprint is a plan for a building, but it does not cover every case, and sometimes adjustments have to be made. Architecture can help there too in providing experience and guidance on what has worked in other situations.
Working Groups Mirror the IETF Model to Incorporate Input
Much like the public comment periods in city planning, where experts and the general public are invited to participate, SW architects cannot make effective guidelines without the input of technical teams.
At Axway, “Working Groups” is the mechanism by which this vital perspective is to be gathered and incorporated into the final architectural guidelines. The process includes several phases where comments and feedback are not only welcomed but necessary.
How do we run working groups to solve the seemingly conflicting tasks of both empowering individual teams, as well as creating a structure and commonality to help bring speed and efficiency? It turns out addressing this problem is very similar to the way open standards bodies work: getting multiple autonomous groups to agree on technical approaches.
The Internet Engineering Task Force already defines a successful way to collaborate across different groups. Therefore, the working group process, we are adopting is modeled on the IETF. It is also already in use by other teams inside Axway.
The IETF Working Group Process
The IETF has a hierarchical structure with distributed activities. The Internet Engineering Steering Group (IESG) is largely responsible for deciding which topic areas the IETF will address in its work and which it will not. In these areas, the IETF establishes charters for working groups (WGs) to define standards.
In turn, individuals (not companies) join the working group to participate in the standards-writing process and eventually publish Requests for Comments (RFCs), the IETF’s standards documents.
In our model, the Architecture Group (AG) is responsible for setting the items of interest and writing the charters for the various working groups. Once a working group finishes, the results are placed into an Architecture Decision Record (ADR) that other teams can refer to. The ADR not only documents the decision, but also the reason, and serves as a record of the thought process that went into the decision.
Ensuring Compliance and Adherence
Having a robust system of input and iterative feedback will ensure the guidelines make sense and are straightforward to implement. However, no set of standards, no matter how well thought out, will be successful if teams have no incentive to follow them consistently.
At Axway, monitoring implementation compliance is where our Governance Council comes into play. Making approval of team product roadmaps and development plans contingent on compliance with company standards ensures that the vision set by company leadership is effectively translated into the end products.
Learn about API Management and architecture deployment.
Follow us on social