Be An Effective Change Agent – Four Tips From a Software Architect
Key practices for software architects that enable business agility, accelerate innovation and future-proof market relevance
Join the DZone community and get the full member experience.Join For Free
A primary requirement for a software organization today is to be able to introduce and maintain change at the speed of business. Driving innovation for any organization is no mean feat, but as holders of technical roadmaps, design patterns, and engineering practices, it is central to an architect’s role.
The ability to change software is holistically dependent on the software design as well as the systems, processes, and teams responsible for delivering it. Architects must consider how to innovate across this landscape. That requires an understanding not only of the technologies and processes that can enable change, but also the complexities of adoption, both from a technical and organizational standpoint.
Why Is This Important?
If a service does not have architectural participation that empowers change, it will bleed market share to more agile competitors. Lead times for new features will expand, bottlenecks will increase (as will remediation costs), slowing down innovation and decreasing the value of the offering. Maintaining the ability to introduce and manage change is essential to survival. Other considerations—from performance to scalability to the adoption of new technologies—can be addressed over time, as long as the architecture, and the architect, enable change effectively.
We might focus on architectural patterns to preserve changeability in a system, or governance processes to decrease friction in the lifecycle of change adoption. First, though, architects must adopt the right mentality and approach to deliver change. With this in mind, here are four tips for architects to serve as effective change agents.
1. Build a Bridge To the Future
One of my colleagues, an effective change agent himself, says that a key role of software architects is to “build a bridge to the future”. I believe it is an apt analogy, useful for envisioning the holistic set of changes that an architect fits together into a cohesive roadmap, so I will use it here. An architect for a physical bridge will follow the latest materials and design research to understand how technology is changing what is possible for his designs to accomplish, and at what changed cost implications. He will also follow how other bridge designers are incorporating these developments into their own structures and engage in prototyping activities himself.
Similarly, if software architects are to stay ahead of the curve when it comes to delivering change, it’s essential to track and understand the trends developing in our respective industries, as well as the maturation trends in the tech industry at large.
The gravitational pull of general trends can often be inescapable. Examples from the last decade include the uptake of continuous delivery, DevOps, and microservice architecture patterns—all of which continue to be priorities for software delivery firms. However, to identify technologies and tools to utilize specifically, we must scout out the terrain ahead. Scouting activities include following innovation centers such as the Cloud Native Compute Foundation, attending both industry conferences and local meetups, and understanding partner or vendor roadmaps. Most important, though, is direct experimentation. This is an essential part of an architect’s role.
Empowering technologies don’t just fall into our laps, and it’s not a given that we’ll use them effectively. It is incumbent upon architects to both identify those technical advancements and understand their appropriate use cases.
2. Get Buy-In For Your Bridge
The bridge architect must persuade stakeholders that his bridge, out of whatever other designs are considered, is not only compelling for its design aesthetic and capabilities but also worth the investment and technically feasible. This requires wearing many hats, convincing people with entirely different perspectives.
As software architects, we must be able to effectively communicate the benefits of reaching across the divide that spans where we are now and where we want to be—or rather where the business wants to be—to both investors and technicians. Business goals, such as improving the speed of delivery, driving costs down, and creating opportunities in new markets, are grand themes. Our task is to understand the specifics of how a certain technology, or the introduction of a new architectural pattern, will help the business reach these goals.
Achieving buy-in for new technologies often means formulating a business case for the technical change, then rolling up our sleeves and testing that case with a proof-of-concept project. This requires a significant investment of time, as we learn the tooling, assess the potential pitfalls and vet desired benefits that will be delivered. We must also ensure that we are not working in a vacuum so that we don’t run into roadblocks trying to integrate this work into the formal business planning process. It is critical here to maintain a close working relationship with the delivery teams and I recommend leveraging a methodology that builds architectural involvement into team processes. For example, with the scaled agile framework (SAFe), bridge building and evangelizing can be incorporated into program increment (PI) planning and architect workshops.
Part of plotting a course to successfully adopt a new technology or pattern is understanding the problems teams will face as they progress along their path to production. This understanding is informed by real-world experience, and we should work with teams to specifically address such problems during the PoC stage through rigorous testing and experimentation. Examples of this might include measuring and decreasing outages when introducing a code change or deploying a new version, scalability of the solution, observing and troubleshooting the solution during failure modes, ensuring automation or operational processes, from testing to deployment. If we know what’s on the horizon for developer teams, we can plot our production roadmaps with these considerations in mind.
3. Don’t Overload the Bridge During Construction (or, Understand Complexity Before Adding More)
Software architects are fortunate to have more freedom than our counterpart real-world bridge builders to apply design patterns quickly, or introduce the latest, greatest technology the week after v1.0. However, we must be careful to consider the implications to our implementing teams.
A new technology or architectural pattern should not be introduced before the complexity of the domain, service usage patterns, and implementation tech stack is understood through real-world usage. As an example, breaking down monolithic applications into smaller components is a worthy tactic on the path to preserving changeability and improving change velocity. However, in this case, delivering an application as five different services create five new delivery pipelines, increases operational complexity, and necessitates implementing a well-known set of patterns for distributed systems and patterns for making each delivery pipeline independent. Such changes add complexity and cost to implement. That is why it has been said that firms “must be this tall” to operate microservices.
Before splitting an application into separate services, technical teams should have reached a sufficiently advanced level of understanding of the subdomains that will become these services. In effect, they should become specialists who understand how these components need to behave independently, as well as how they interact, in the production environment. From API usage to test design to deployment automation and database migrations, understanding the dependencies between components that will facilitate or encumber change is essential.
For greenfield development, it is likely a mistake to architect a service with a sophisticated level of modularity from day one. A sensible pipeline for a new application is as follows: establish the minimum viable product > build it > test it > release it > iterate based on production feedback, including iteratively adding complexity to the architecture.
It can make sense to start with a more monolithic design using a modern tech stack, rather than orchestrating a microservice system straight away. Development can then progress with governance to maintain loose coupling between internal application components and comprehensive acceptance tests so that the monolith can be more easily broken down in the future.
With this tip and the next, we should strive to leverage the freedom we have as software architects to incorporate iterative, agile processes into our architectures.
4. Build the Right Bridge
To effectively innovate, we must work iteratively with engineering teams and incorporate feedback into our systems and processes. They are our internal customers and we should validate we are solving their problems and empowering them. Are we measuring delivery and reliability goals with a DevOps dashboard? We might also try soliciting high-level feedback with net promoter score surveys for a given process, or use another customer sentiment measurement.
However, an internal-only or development-only feedback loop should not be our first priority. Our first priorities are to support market validation with real customers and learning from real production operations. Our architectural proposals and decisions should prioritize getting that feedback as quickly as possible, to use in the next iteration of the technical roadmap.
Speaking from experience, the first version of any application or new pattern (and the second and third versions, too!) will fall short of the customer value envisioned at the start. We can deliver that value, though, through effective experimentation, incremental improvements, and customer validation.
As software architects, we are important to change agents in our organizations. If we’re effective, we serve a valuable role in supporting business agility and maintaining market relevance for our products. An architect should be proactive in keeping abreast of technical trends, but this must include understanding when and how to apply those trends. Just as essential is our ability to measure and communicate the value of adopting certain technologies or architectural patterns to business and engineering stakeholders. We must work closely with development teams from experimentation and design to production usage, and not overburden them with complexity too soon. If we embrace feedback and have the courage to adapt accordingly, we can be effective change agents—keeping our organizations on a reliable, sustainable technical bridge to the future.
Opinions expressed by DZone contributors are their own.