That’s because an agile approach discourages up-front documentation and empowers development teams to design and build the system. But what about the solution architect? Isn’t it his or her responsibility to determine the best fit architectural solution design before a development team even starts working on it? If not, does a solution architect still have an important role to play in an agile environment? Absolutely, let’s explain why.
How do mature agile development teams tackle design?
Experienced development teams take on the end-to-end responsibility for a certain system that delivers value to the customer. They design, build, test and deliver new requirements that impact this system and are responsible for its maintenance afterwards.
Most of the time, the requirements are split in small user stories that can be delivered in sprints of one to three weeks. To determine the best design to implement the user story, an ‘emergent’ approach is needed. This means design decisions are postponed for as long as possible, so the decisions are based on facts coming from working code instead of assumptions and documentation.
An ‘emergent’ approach goes hand in hand with a behaviour-driven development approach in which expected behaviours are described before designing or building the story. Several potential solutions can be built in parallel. If one is not working, it will be excluded. Lessons learned are incorporated in the other ongoing potential solutions. Once one of the solutions passes all expected behaviours, both from the new story as of all previous stories, it wins.
During this process, the team might conclude that one of the previous stories was designed and built in such a way that it does not support the needs of the new story. At that stage, the winning solution will need to redesign the previous story. In fact, experienced agile development teams will refactor and restructure code continuously.
Less experienced development teams might need more guidance to deliver a solution that fulfills the business needs.
Where does a solution architect fit in?
In small organisations with a few, experienced development teams that oversee the whole IT landscape, a dedicated solution architect might not be required. That’s because experienced team members take over his typical tasks. However, in larger companies, or in organisations with immature teams, someone is needed who:
- Has a high-level overview of the most important systems and technologies of the organisation;
- Keeps an eye on the market trends and innovation;
- Is capable to translate high-level business needs into working solutions (potentially impacting business processes, the organisation and/or any number of new or existing IT systems scattered over multiple teams);
- Leads discussions about the architecture of new systems (considering the organisation’s strategy, non-functional requirements, technology, type of architecture and required skills);
- Guides multiple development teams to deliver a consistent end result;
- Gives guidance depending on the maturity of the development team;
- Sells the proposed solution to different stakeholders (IT management, business stakeholders and developers).
As soon as it’s clear what’s expected from every team (both from an architectural as a functional point of view), each team will start figuring out the most appropriate design to fulfill the expectations.
Should solution architects tackle things differently?
Generally speaking, the tasks of a solution architect are independent from the delivery approach of the organisation. However, he or she can help companies to accelerate achieving higher levels of agile maturity:
- Solution architects are in the lead to decide on the type of architecture and technology. Agile development teams thrive when recurring tasks such as code integration, testing and deployment across different environments, are automated (aka Continuous Integration and Continuous Deployment - CI/CD in short - in DevOps). The choice of architecture and technology plays an important role in setting up CI/CD pipelines.
For instance, for operational systems, a service-based architecture with clearly defined API’s in a cloud environment will boost automation, unlike a monolithic application deployed on mainframe.
- Solution architects give guidance to development teams. To increase the agile maturity level of the teams, they should avoid to elaborate solutions to the deepest level of detail. Let them describe a solution to the level that a team is capable to get started with instead. In this way, the solution architect needs to describe less so the team gradually learns to take up new responsibilities.
In the following example, the solution architect needs to specify an interface between two systems to transfer personal data:
- For new, inexperienced teams:
- Explain both systems functionally and technically.
- Explain why the interface is needed.
- Describe all required fields in the interface with their characteristics.
- Eescribe via which mechanism it should be set up (file transfer, SOAP call, REST call, etc.);
- For more experienced teams:
- Explain the system not in the span of control of the team functionally and technically.
- Explain why the interface is needed.
- Describe the most important fields in the interface with their characteristics.
- Describe whether it should be real-time or not.
- For very experienced teams:
- Explain the system not in the span of control of the team functionally.
- Explain why the interface is needed and which person characteristics are required.
The thin line between architecture and design
A frequently asked question is how detailed the architecture should be. The answer is easy: it depends! It depends on the maturity level of the development team as mentioned before. But it also depends on the organisational culture. For instance, a lot of companies are cost-driven or value-driven. The consequence? New features can only get approved when a detailed, reliable business case is available. And a detailed, reliable business case requires a more detailed architecture.
A more important question is how the solution architect collaborates with the development teams. If the solution architect involves development teams in defining the architecture as of the start, and (s)he continues to give support during the implementation, then less elaborated architecture work is required. That’s because development teams become capable of filling in the details and translating architectures into designs.
In short: yes, solution architects are still required in large or immature agile companies. The typical tasks of a solution architect remain the same, but the ‘one-size-fits-all’ type of architectural work is no longer reality. Solution architects will need to give sufficient details, so a team can pick up work easily. This level of detail will change while teams become more mature. Collaboration with these teams is key to understand what they need. Moreover, solution architects can be a driving force behind maturing agile development teams.