Putting the A of Agile into Architects

Should we get rid of IT architects, or do we need them more than ever?-There are a lot of connotations when it comes to traditional IT architecture: 

• It is often characterized by a top-down approach.  
• It regularly creates artifacts that are either unneeded or don’t provide information that would be useful if it were there.  
• Traditional IT architects live in a world of their own, their ivory tower, and many of them are not very good at collaboration and reaching out.  

No wonder that traditional architecture has a bad name. 

So, should we simply get rid of architecture altogether? In this article, I will explain why I believe that is a bad idea and why we should better replace traditional architecture with something I call modern architecture, practiced by modern architects. 

My observation is that organizations disposing of traditional architecture without giving it any further thought will find that they lose the overview, control, and coordination of their activities. This is often noticed too late when difficulties start to occur in areas like: 

• Translating business strategy into domain changes (for example marketing, production, and distribution). 
• Defining and supporting changes required to the application landscape, which may take years to complete. 
• Large infrastructure changes. 
• Translating domain changes into changes to be implemented by multiple teams (when changes require a coordinated effort). 
• Ensuring a uniform application of organization-wide requirements concerning security, legal and regulatory, compliance and risk, and topics related to automation of the delivery process and the data center. 

It is better to avoid these difficulties. But how should that be done? This is where we need to assess the role of architecture in a modern, high-performance organization: we need to define an operating model for modern architecture.  

In my opinion, a modern architecture process must have the following characteristics: 

• It is, first of all, a means for change – a change agent. If your organization doesn’t change, you don’t need architecture. But if it does, you’ll need a mechanism to guide and support changes and stay in control. 
• It provides guidance. If you want to stay ahead of your competitors, you’ll need guidance in the evolution of relevant technology. Similarly, you’ll need guidance to reduce the risks and minimize complexity while implementing changes. 
• It ensures cohesion. You want to maximize business value and minimize waste. This requires organizational alignment and coordinated implementation of changes, so they reinforce each other. This holds on all levels: enterprise, domain, and application. 
• It facilitates teams. If organizational requirements extend across multiple teams, you want to provide them with architectural guidelines, so the teams can act in concert. Also, you want to enable flow by identifying and making cross-team decisions at the right moment.  
• It is partly intentional, partly emergent. Some things are better thought out before doing anything, but other things only become clear during implementation. Good architecture needs both inputs. 
• It is “just enough” and evolves. There’s no need for a big design upfront. An initial outline may suffice to initiate a change. This can be extended as needed and refined based on experiences gained. 
• It is fit for purpose. You only want to invest time and energy into things that have an ROI (Return On Investment). If you’ve determined that your staff has a really good use for overviews of business value streams, application landscape, and interfaces: go ahead and create them. But if that’s not the case, you don’t want to waste time on these artifacts. Same for knowledge sharing, training, and coaching of teams.   

When successfully engaging in modern architecture, it is also important that modern architects show the following traits: 

• They operate at multiple levels. This holds especially for enterprise architects, but to a lesser extent also to domain and application architects. Switching between management and DevOps teams with end-to-end responsibility comes naturally for the modern architect, they can “ride the elevator”. 
• They collaborate and reach out. They look at architecture as a team effort and invite stakeholders to participate and align. They actively promote the architecture that results from their efforts, for example by giving workshops. 
• They are curious and open-minded. They look for information anywhere it can be found, and they are open to suggestions and experiences from others. 
• They show leadership and promote best practices. They lead by example, showcasing lean thinking and agility, and they actively promote flexible design, reuse, design patterns, and engineering practices. 

Putting characteristics and traits together, it is clear that modern architects must have an agile mindset. This is a challenge if your organization’s attention for architecture has slipped, or if it still employs traditional architects. So, how to put the a of agility into your architects? There are several considerations that I believe are important to create your team of modern architects. This is by no means a complete enumeration, but it provides some pointers to get you started. 

1. Make sure that management understands the merits of modern architecture and commits to putting modern architects into place. This requires management to be educated (for example with one or more workshops) and then invited to make a commitment and communicate it. This way, modern architecture will be embedded in the organization’s goal set, and it will be clear to everybody that cooperation is required and expected.  
2. The second consideration is your organization’s starting point for this journey If architecture has disappeared from your radar, or when setting up a new business, you effectively have a greenfield. But if you have an established architecture department, you need to assess if its members are willing and able to make the transition to modern architects, or not, and act accordingly. This may imply moving people around, or even letting people go. It is, however, important to start with people that have a positive attitude towards an agile mindset in combination with architecture.
3. The third consideration is how to structure the architecture roles to facilitate agility. Assigning the responsibility for software architecture to DevOps teams is a no-brainer nowadays. DevOps teams know their applications and technology best. And being a software architect is a part-time role that can be combined with other DevOps-related work. In addition to software architects, the size of your organization determines whether you need separate domain and enterprise architects. Small organizations get away with a single enterprise/domain architect. But large organizations may need multiple domain and enterprise architects. Since these roles are essential to ensure the coordination of activities across an organization, having the traits of a modern architect is of special importance to the domain and enterprise architects.
4. The fourth consideration is how to implement the transition. This isn’t done overnight, especially if you choose to do it with your current team of architects. Bringing software architecture to DevOps teams isn’t trivial, as I have experienced in my embarrassment. In essence, the implementation is about a behavioral change, which takes time. A lasting change can only be achieved by repeated training and exercise in the traits of the modern architect. One-off trainings will not work, because they are often just an awareness raiser after which people return to business as usual. And a lasting change can only be proven by evaluating the services and work products delivered by the architects. This means that monitoring using a reference framework or metrics should be put in place.
5. The fifth consideration is how to create a constant value flow for the organization. The goal is to show the organization as early as possible that modern architects, their services and products deliver real value. After all: nothing is more convincing than showing results. This will help in creating a positive attitude and reinforce collaboration with the architects. After the initial results, it is important to deliver and receive feedback continuously and adjust the transition process as required.
6. The sixth and final consideration is who will guide the transition. You can do this yourself or with the help of external assistance. Both options have their pros and cons. You’ll have to be honest with yourself to determine the best option. If your organization has the skills and capacity, and a proven track record implementing organizational changes, doing it yourself may be the right thing to do. But if that’s not the case, getting external assistance is probably better. 

I believe these considerations are important to assess if you want to introduce modern architects to your organization. Of course, some details need to be taken care of, but that can be done as a part of the implementation, and in an agile way: when it is needed. In this way, you practice what you preach, and doesn’t that feel good?