Going from Architect to Architecting: the Evolution of a Key Role

A changing world

Software could be viewed as a very young science, compared to the more traditional sciences. But even in its infancy, one of its key components, its architecture and how that is formed, has changed significantly. Gone are the architectural blueprints, the months given to producing the complete design that would solve all problems, and gone is the sole individual governing all. That paradigm shift was partly driven by the industry creating better tools, and partly by the changing behaviour of customers. Their interaction model changed from a transactional service to a consumption driven service, moving customer behavior from systems of record to systems of engagement, where customers now have more active and timely demands. Software architecture needed to evolve to meet this new demand and embrace the available tools. Today, architecture is more about decisions than structure, more about reacting to constant change than following a master plan, more about delivering frequently than one big drop. The implications of this on the role the architect plays is profound. 

In this article we will explore the cultural change of moving towards shared architecture, and the role that the architect has evolved into; from one with an air of authority and singular vision, to one in which system design issues are surfaced, which require team-wide input to resolve. This has caused an inversion of control style relationship to develop. Teams that are being coached and guided towards shared ownership might be struggling with this paradigm shift of ownership. 

We will explore our experience with this change, from our combined 25+ years’ experience of wearing multiple hats in a team, from being an engineer, and a product owner, to a team coach and manager. Each of these roles has allowed us to interface with architects and has provided us with observations of the changing landscape and the role the architect has tried- and at times failed- to evolve. We hope to offer guidance to those stuck in transition, as well as those looking to further enhance and distribute their architecting.

Change Factors at Play

A changing responsibility

Traditionally, an architect had a number of fundamental responsibilities. One of those involved the scalability profile of the application. The architect needed to consider a number of different factors to ensure that the anticipated load on the system could be handled. That informed decisions that ranged from what language would best handle this style of application? How do we want to handle I/O? To block or not? What is our database strategy? How many cores do we need? What about RAM? What about storage? The level of refinement on this gave careful consideration to the deployment strategies, the availability of specific hardware or chipsets, right down to the location the applications would be staged from. Those decisions ultimately gave a holistic overview of the lifecycle of the application, its intended usage and often informed the update cadence and strategy.

In a more modern context, the tooling available to the overall development team has reduced the previous number of considerations that an architect would need to have thought through. The capabilities of autoscaling, for example, ensure that questions that surround the computational resources needed by the app are neutralised as a topic (notwithstanding that somebody needs to pick up the bill!!). Deployment and handling bursty load is made trivial through orchestration platforms like Kubernetes that will manage additional instantiations of your application on demand and step them down as traffic decreases. Profiling tools, from static analysis of cyclomatic complexity to performance analysis metrics, right through to visualisations of your APIs capabilities, has now made a wealth of information available at a team-wide level. The toolkit described above now appears on standard job specifications, meaning the previous specialised knowledge of the architect is naturally distributed across the entire team and the knowledge generation and data insights far exceed what a singular role could ever have hoped to share in the team. This means some ownership and accountability in this space has transitioned over to the team as a whole, rather than being solely owned by one individual. Shared ownership has become a thing. Now the team often decides on the tooling, influenced by industry standards, client expectations and technology alignment within the company.

Changing consumption patterns

The rapid evolution of cloud computing (or the SaaS culture and model) has prompted a move towards flexibility in how we ship, when we ship, and what we ship. The focus now is on creating a more robust onboarding of services and support, allowing the team the capability to change focus quickly. Knowing that increased functionality comes with more user accessibility of the feature set means that learning the consumption profile becomes a key decision in how features are developed and grown. That hardening element, previously a multi-month thought exercise on stability, scale and robustness, has now given way to more willingness to experiment.

Features being released under banners of technical preview, with caveats of do-not-use this in production often willfully ignored, allow the safety net for the evolution of the app to grow in lockstep with your customers demands. This removes the vacuum effect of the customer being disconnected from the team, with that prior relationship often solely managed on behalf of the team by roles such as the business systems analyst, or more recently the product owner. Now, the team is much more customer-aware and maybe even more aware than the architect is at times. They have exposure to how the customer interfaces with the system and when combined with the insights derived from their telemetry applications, the pulse on what the customer needs, why they need it and how they need it is present. That brings a powerful multi faceted view on the evolution of the app as now, the entire team, with their diverse backgrounds, skillsets and niche expertise can contribute towards the grander vision, truly transitioning it from the role of a single individual, to one the team largely drives, but in collaboration with the customers needs.

The actual impact of this, at a code structure level, is best seen through the rise of microservices. With this change of ownership and the change in demand, the application as a whole needs to be in a position to evolve independently; to allow some services to try something different, to test out a feature, to be able to switch on and off functionality for some or all customers. This has created a virtuous cycle wherein this development approach has created a suite of supporting tools and services such as API Gateways to organise your service contracts, to messaging systems like Apache Kafka through to microservice enabling frameworks such as Spring Boot, Flask and other language-specific frameworks. The availability and maturity of this tooling has in turn made it easier for teams to self select microservices as an architectural style to adopt, further driving the investment in the tooling.

For the architect, they no longer can design the architecture with their master blueprint in mind. Modern consumption patterns have demanded more agility. The architect must constantly adapt their system design to address the fast flowing customer needs; they must facilitate the evolution of the architecture.

Mindset changes, opportunities, challenges and new skills to be mastered by today's architect

After seeing the different control factors at play, we believe that there are things that need to change for the modern architect; challenges to address and opportunities to take advantage of, and new skills to be attained and practised.

Software architecture is constantly evolving

A fundamental principle of today’s software architecture is that it's an evolutionary journey, with varying routes and many influences. That evolution means we change our thinking based on what we learn, but the architect has a key role in enabling that conversation to happen. Taking two quotes from a chief architect who we interacted with at Red Hat to capture some of the thoughts and concerns that face today's architects:

A critical subject is the impact of Conway's law: the architecture of your system reflects the structure of the organisation building it.

Another aspect of architecture conversation is surfacing issues that either nobody was aware of, or that everyone was aware of but were not willing to talk about. Putting these to the fore for discussion is essential. Not with a sole focus to solve and implement, but more so to discuss them such that everyone knows there is a path forward or that we can initiate appropriate adjustment as the design evolves. Sometimes one of the most important outcomes of these discussions is the realisation that the problem is not a problem at that point in time. The clarity that this can provide is essential for everyone. It allows people to focus on upcoming tasks without some feeling of a shadow looming over them, in other words, it removes an unspoken burden. -- Emmanuel Bernard, distinguished engineer and architect, Red Hat

The presumption is that the majority would tend to agree with those thoughts, but has their architectural decision process evolved to match this thinking? Are they taking into account org structure? Are they forgoing up front design to introduce up front conversations? The first step with any change is awareness and then acceptance.

One of the primary influences on product/service changes is customer interaction and feedback, and even understanding that your customer may be internal teams as well as paying customers. The feedback loop is continuous in modern markets. and the architect must fully embrace this opportunity. In conjunction with continuous feedback, there is an expectancy of frequent, or as close to continuous as possible, delivery. This introduces challenges for the architect, their team and their organisational structure, as rarely can continuous delivery be achieved in isolation; it often requires an organisational movement to achieve it successfully.

Small iterations resulting in frequent deliveries can be ideal for functionality that fits into such a window. However, when introducing potential bigger pieces of functionality (e.g. architectural refactoring), it may not be as simple as one would expect. This challenges the architect and his team to be able to deliver component parts on a frequent basis, while still ensuring the service runs satisfactorily, ensuring SLAs and quality expectations are abided by. More importantly surfacing a resolution path early in the development, before a forced evolution occurs, brings a sense of ownership to an enforced change. 

In a lot of cases the timing of design decisions can be governed by business needs. The marrying of business needs, in a timely fashion, with system design decisions, is a real challenge that the architect and his/her team need to address. The traditional focus of creating an architecture primarily focused on the end goal, has changed to “what’s needed next to adequately address the business needs of the upcoming months". This may lead to decisions which may be changed further down the line, but they are the correct decisions at the point in time. As we learn by building and our customers learn by interacting with our products, it provides the tight feedback loop that makes any changes informed in the here and now. It's the natural evolution of the system architecture, and knowing that ahead of time and building in strategies to handle best case and worst case scenarios is a key skill that the team needs to develop. Architecture used to be perceived as a straight road, but it isn’t and arguably never should be again. The evolution of an architecture has many twists and turns on its way with each one bringing a learning opportunity.

That’s not to say that the architect must ignore the perceived end goal of the architecture, something that used to be their only focus. In the current climate, the product owner becomes a very important collaborator for the architect, meaning that end goal and vision become a shared experience. Debating, collaborating and agreeing with the product owner on the vision of the product/service is essential for the architect to ensure that there is a direction, even if it may not be crystal clear all the time. Conversely, that debate allows a sense of realism to the product owner’s vision, hopefully allowing a compromise that reflects what’s achievable and what a realistic timeline looks like. This vision provides guide rails and becomes another important input to the technical decision-making process.

Architecture is no longer an individual sport

The architect playing a sole role in the software development game is no longer the case. Architecting a system is now a team sport. That team is the cross functional capability that now delivers a product and is made up of anyone who adds value to the overall process of delivering software, which still includes the architect. Part of the reason behind this, as discussed earlier, is that the software development ecosystem is a polyglot of technologies, languages (not only development languages, also business and technical), experiences (development and user) and stakeholders. No one person can touch all bases. This change has surfaced the need for a mindset shift for the architect; working as part of a team has great benefits but in turn has its challenges.

To be able to lean on others and hand over responsibility is an important skill that needs to be attained. This comes down to building trust between the architect and team members. They must now share ownership of the technical direction and trust colleagues to own and drive certain aspects or components of the system. The ecosystem of how architecture evolves has changed from a single top down commander to a conglomerate of peer contributors, all with diverse perspectives.

For trust to be bi-directional, there are times when judgment needs to be held in reserve, and new ideas and opinions allowed to flourish. The architect needs to be a leading figure in establishing psychological safety for his/her team. Meritocracy of ideas must be nourished in order to allow the architecture to evolve in the most optimal way.

Failures at the team level, rather than being perceived as incompetence, must be seen as opportunities to get things right. More frequent delivery cadence aids this approach as action can be taken quickly.

The architect needs to accept that architecting has evolved from being an exclusive individualized responsibility, to that of a shared team responsibility. Through this acceptance, they can avail of the array of benefits a team environment can generate. For people who have worn the more traditional architect’s hat, the perceived lowering of themselves to be a team member can most definitely be a struggle. We have unfortunately seen this first hand, where the architect took on a more challenging tone to every idea, suggestion or improvement that the team was bringing up in their innovation phase.

This led to an impasse, as the team slowly over time became silent, knowing their suggestions were not being taken at face value and the architect, unable to reconcile their own limitations, was unable to chart a path forward. In turn, this becomes as much a battle against the title and a reluctance to relinquish control and acknowledge gaps in their own knowledge and capability. This action in our team continued  with the need to become a deliberate reviewer of all proposed changes, undermining the growth of more than capable team members and slowing down the pace of delivery. While we have seen this pattern in several companies, over several industries, the fast paced evolution of technical stacks in a cloud centric environment is making this an even bigger challenge.

This means that the architect is no longer the singular authority on a technical area, as the speed of improvements means a constant drive to improve tooling; stacks and approaches are happening within every developer, and more importantly across the industry, making it a technical arms race. This will inadvertently cause a failure to support, trust and enable that tech stack progression if the architect is unwilling to trust and empower those around them. This becomes a losing battle for a team, as the architect feels they need to catch up with their own knowledge to make a decision, however, the developers are actively coding, debugging, experimenting and learning day in day out and at a far deeper level than the architect can reach. If that knowledge gap is never bridged, it leads to attrition and a fundamental loss of psychological safety within teams. Strong leadership is required to address this and more importantly strong support, from coaching to mentoring, to help the architect overcome the fears they are experiencing. What both the architect and the overall team need to be aware of, is that what's best for the team may not be best for the individual, but will often reap the most benefits (for the betterment of the product or service being built).

An example of this is slowing down a release cadence to ensure common understanding. In a prior company we had a subject matter expert (SME) who was empowered with the architect position while also possessing the technical ability to drive the implementation of the feature from their design almost solo. Their vision for the architecture of this particular product was to refactor the existing component oriented design pattern towards a more modular plugin based strategy. This came from their own vast experience of the architectural best practices and from deep interlocks with customers. Their vision was projected as a robust Proof of Concept, undertaken solo, a well-formed email explaining their rationale and a suggestion that the refactor could be in place before the next scheduled customer drop. While the vision, passion and capability were undeniably things we (Chris as an engineer, Leigh as an engineering manager) wanted to tap into, an air of unease existed within the team. It was an architectural shift, with new technology that the team as a whole had minimal awareness of. The SME in this case was due to lead another project roughly three months after the next customer drop and were already contractually expecting a delivery, meaning a cost of delay would be incurred.

A decision was taken to support the SMEs vision, but to engage them to elaborate more on the benefits (better interoperability, smoother customer integrations, easier debugging) and then negotiate our release commitments with both customers. This gave a safe footing to slow down the eagerness of the individual, while supporting the idea and more importantly allowing the team as a whole to get comfortable with the tech and the changes. The result was a sustainable architecture, but more importantly sustainable skills cultured within the five other developers who longer term would own the evolution of this product. This undoubtedly caused pressure on the sales team and customer side, but the payback over the coming 18 months was clear for the development team as they negotiated the rapid business requests to add functionality. This had a happy ending, but that wider buy-in required honest conversations from the engineering leadership to create the safety for both the team and products’ evolution.

Technical acumen is no longer sufficient

Technical knowledge has and will always be a prerequisite for the architect. Business acumen and market understanding has most definitely increased its importance. But the big change the architect needs is to use coaching skills across all the people involved in the software lifecycle. This may sound overly simplistic, but is so important for the architect in the ever increasing fast paced software industry. Their ability to listen and consume the business perspective, the technical needs and wants from the engineers on the ground and the management's need to deliver fast becomes essential. The architect needs to become competent in the use of “powerful open questions” as an important mechanism to provoke deeper thinking and elicit varying perspectives.

Things like asking “Why” questions can infer judgment, e.g. why did you take that approach? Changing to “What made you decide on that approach?” will prompt the responder to explain their thinking rather than justifying their decision, as it may have been deemed incorrect if asked using “Why?” This simple change and the use of open, curious language can go a long way to creating inclusivity across the group and more importantly, creating a supportive atmosphere rather than a perceived challenging atmosphere.

The architect has become a polyglot; their traditional technical language has been accompanied by the language of business and the language necessary to extract the best views and ideas from engineering teams.

Practical Tips

Having distilled down the challenge, here are six practical tips for architects and five practical tips for teams who might be struggling with this transition.

For architects:

1. Become a mentor to the team's growing understanding of architecture, rather than an impediment. Share your knowledge openly and proactively. 
2. Seek coaching to help you get beyond inner challenges that only you feel but the team may not be aware of. Don’t suffer alone, and guided support can aid your role evolution.
3. Welcome being challenged by customers, the team and your environment. That feedback loop can be exhausting, but channeled in the right way can be hugely rewarding.
4. Use your experience to guide conversations towards challenges that your expertise tells you will be encountered. 
5. Gain an understanding of the dynamics of your team, their strengths and weaknesses, their knowledge of the tooling, and their reality of building an application day in day out. Help to structure your input on where it can add the most value, at the right time.
6. Become a relationship builder. Develop your soft skills to build a network, from the sales team to the product owner, from the engineering manager to the tech SME. Nurture and foster those relationships daily.

For the team:

1. Distill down your experience of using a tool and its advantages for non-domain experts. Bring them on a journey of understanding.
2. Use the architects’ vast experience to gain insight on a thought, challenge or idea you might have. They are part of your team now.
3. Present your ideas, their benefits and drawbacks transparently and simply; be prepared for open and challenging feedback. Help embody psychological safety.
4. Leave titles and egos at the door; embrace the team environment and learn from everyone in the room. The scope for you to influence direction is very real in how software is designed today. 
5. Grow your presentation, communication and mentoring skills and use them daily, information exchange in fast paced teams is crucial.
6. Do everything in your power to retain your architect. That deep rooted knowledge and expertise is invaluable to grow and empower your team; don’t make them feel isolated, make them feel part of the team and part of the future solution.

Conclusion

The role of the architect has fundamentally changed for the better for the software industry and more importantly for our customers. How we engage with customers, how we build, ship, release and support our software has changed. That change has empowered the overall development team and their previously considered support roles such as quality engineering / quality assurance. Now, every person has a voice, an opinion and a valid input in how a system grows and is supported over time. That has been complemented by two independent but related changes. Firstly, the change in end user expectations, where the demand for more rapid feedback and more imperfect services now exists in order to guide what they need and when they need it.  Secondly, a suite of tooling has emerged to support and enable developers in their day-to-day work. This brings about solutions to problems that were previously a consideration for architects only, and allows for more insight on performance, scale and design to naturally percolate among the teams. The result is a change in the foundational role that the architect needs to play. Their years of experience combined with their vast knowledge of best practices now needs to be reimagined into the daily flow of the team. This is a chance to level up the entire team's experience, creating a more diverse view of how we build our software. That change can be difficult; it requires support from management and the team. It also requires a willingness for the person in the role to want to evolve, to offer more value than ever before and to relinquish the prestige of the title for the betterment of the team, the product and the customers.