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

How evolutionary trends like agile and tooling support are changing the way architects should work

This is our review of an excellent article published at InfoQ by some of our colleagues at Red Hat. See the references section at the end for the original publication, but this overview aims to give you all of the insights and more in just a few lines of text. Where applicable the content has been complemented with lessons learned from our own experience…

Who Should Read This?

Read this post (and the original article reviewed) if you are in one of the following situations:

• You are a traditional architect wondering how to make your work fit into agile processes and teams
• You are in an agile team and confronted with rigid architecture roles who don't really help the project
• You are a product owner or manager for one or more agile projects, wondering how to keep the architecture safe

Architecture: What Remains The Same?

Although the question is about what has to change for architects to combine well in modern projects, it probably helps if we start by saying what remains the same in "traditional" architecture and "modern" architecture.

Both traditional architecture and modern architecture are about the non-functional qualities of the project or product you are working on. That is and remains the focus of the architect role in any case.

So how can things be different (or change) then? Here is the thing: the big difference is in the way the final architecture is realised.

Architecture: What Changes?

As stated above: the big difference is in the way the final architecture is realised. But what does that mean?

In traditional projects, the architect was supposed to define a definitive structure for the project, before coding even began. In modern environments, the focus is on getting something that works, and (in each iteration or sprint) converging to something that more closely resembles (and supports) the final product vision as defined by the product owner.

But the key things to understand are the following:

1. Requirements Change

Requirements change (and so can - worst case - the vision). Gone are the days that big up-front requirement documents would describe everything. Really successful projects learn and adapt the requirements based on early user feedback. Early feedback means things are easier to change. Delivery based on priorities ensures that most of the business value gets delivered early on, rather than after the (usually late) delivery of a waterfall project.

So change is a constant. Therefore, successful architects accept this idea of change and embrace it. Their architecture focuses on making changes easier along the way, but nevertheless a good agreement on the vision (with the product owner) is needed to keep the right focus across iterations.

The fact that the architecture changes along the way (rather than staying with some up-front structure) also means that the architect should work more closely with the development team. After all, they have "lessons learned" to incorporate into the next iterations. Plus: the team needs to support the development of the architecture baseline for the next sprint(s). So architecture has become a team sport.

2. Tools Change

Development teams have better tools available, ranging from their development environment to automated cluster deployments. This means that certain insights and guidelines that were reserved for architects are now actually available more to the team than to one single architect.

This is yet another reason that architecture has become a team sport.

How Architects Should Cope With This

So architecture is now a team sport (if that is not clear then you should probably re-read the previous section).

How do you adapt to this new way of team-based architecture? Architects have to become better team players. That sounds simple enough but it can be challenging for sure.

Some concrete guidelines:

1. Embrace Iterative Improvement

• Make sure that the vision is shared between the product owner and the architect - so the vision guides the final architectural goal.
• Focus on what is "good enough" for now (but make sure it does not make the architectural end vision more difficult to implement) - so the team feels confident that the current sprint's work delivers technical progress.
• Guide conversations towards challenges you think will be encountered - so you can share concerns with the team and they can help achieve the goals.

2. Involve the Team and Keep Them Safe

Also, make sure that the team does not view the architect as a bully-ish impediment:

• Architects should look at failures as "opportunities to get it right", rather than incompetence - so team members feel safe enough to make mistakes.
• Architects should ask safe questions: NOT “why did you do that?” but rather “what made you decide on that approach?" - so team members don't feel attacked.
• "We are smarter than me": realise that two or more people always know and see more than just one - so you really value the input of team members (and maybe even get to learn on the job).

Summary: Be a Technical Product Owner

The architect role could (should?) probably be renamed into "technical product owner".

References

The original article can be found here. As stated earlier on, this review gives you a condensed view of all you need to know - with our own original insights added where possible.