Re­view: Go­ing from Ar­chi­tect to Ar­chi­tect­ing: the Evo­lu­tion of a Key Role

How evo­lu­tion­ary trends like ag­ile and tool­ing sup­port are chang­ing the way ar­chi­tects should work

Er­ror: im­age not found

This is our re­view of an ex­cel­lent ar­ti­cle pub­lished at In­foQ by some of our col­leagues at Red Hat. See the ref­er­ences sec­tion at the end for the orig­i­nal pub­li­ca­tion, but this overview aims to give you all of the in­sights and more in just a few lines of text. Where ap­plic­a­ble the con­tent has been com­ple­ment­ed with lessons learned from our own ex­pe­ri­ence...

Who Should Read This?

Read this post (and the orig­i­nal ar­ti­cle re­viewed) if you are in one of the fol­low­ing sit­u­a­tions:

• You are a tra­di­tion­al ar­chi­tect won­der­ing how to make your work fit into ag­ile process­es and teams
• You are in an ag­ile team and con­front­ed with rigid ar­chi­tec­ture roles who don't re­al­ly help the project
• You are a prod­uct own­er or man­ag­er for one or more ag­ile projects, won­der­ing how to keep the ar­chi­tec­ture safe

Ar­chi­tec­ture: What Re­mains The Same?

Although the ques­tion is about what has to change for ar­chi­tects to com­bine well in mod­ern projects, it prob­a­bly helps if we start by say­ing what re­mains the same in "tra­di­tion­al" ar­chi­tec­ture and "mod­ern" ar­chi­tec­ture.

Both tra­di­tion­al ar­chi­tec­ture and mod­ern ar­chi­tec­ture are about the non-func­tion­al qual­i­ties of the project or prod­uct you are work­ing on. That is and re­mains the fo­cus of the ar­chi­tect role in any case.

So how can things be dif­fer­ent (or change) then? Here is the thing: the big dif­fer­ence is in the way the fi­nal ar­chi­tec­ture is re­alised.

Ar­chi­tec­ture: What Changes?

As stat­ed above: the big dif­fer­ence is in the way the fi­nal ar­chi­tec­ture is re­alised. But what does that mean?

In tra­di­tion­al projects, the ar­chi­tect was sup­posed to de­fine a de­fin­i­tive struc­ture for the project, be­fore cod­ing even be­gan. In mod­ern en­vi­ron­ments, the fo­cus is on get­ting some­thing that works, and (in each it­er­a­tion or sprint) con­verg­ing to some­thing that more close­ly re­sem­bles (and sup­ports) the fi­nal prod­uct vi­sion as de­fined by the prod­uct own­er.

But the key things to un­der­stand are the fol­low­ing:

1. Re­quire­ments Change

Re­quire­ments change (and so can - worst case - the vi­sion). Gone are the days that big up-front re­quire­ment doc­u­ments would de­scribe every­thing. Real­ly suc­cess­ful projects learn and adapt the re­quire­ments based on ear­ly user feed­back. Ear­ly feed­back means things are eas­i­er to change. De­liv­ery based on pri­or­i­ties en­sures that most of the busi­ness val­ue gets de­liv­ered ear­ly on, rather than af­ter the (usu­al­ly late) de­liv­ery of a wa­ter­fall project.

So change is a con­stant. There­fore, suc­cess­ful ar­chi­tects ac­cept this idea of change and em­brace it. Their ar­chi­tec­ture fo­cus­es on mak­ing changes eas­i­er along the way, but nev­er­the­less a good agree­ment on the vi­sion (with the prod­uct own­er) is need­ed to keep the right fo­cus across it­er­a­tions.

The fact that the ar­chi­tec­ture changes along the way (rather than stay­ing with some up-front struc­ture) also means that the ar­chi­tect should work more close­ly with the de­vel­op­ment team. After all, they have "lessons learned" to in­cor­po­rate into the next it­er­a­tions. Plus: the team needs to sup­port the de­vel­op­ment of the ar­chi­tec­ture base­line for the next sprint(s). So ar­chi­tec­ture has be­come a team sport.

2. Tools Change

Devel­op­ment teams have bet­ter tools avail­able, rang­ing from their de­vel­op­ment en­vi­ron­ment to au­to­mat­ed clus­ter de­ploy­ments. This means that cer­tain in­sights and guide­lines that were re­served for ar­chi­tects are now ac­tu­al­ly avail­able more to the team than to one sin­gle ar­chi­tect.

This is yet an­oth­er rea­son that ar­chi­tec­ture has be­come a team sport.

How Ar­chi­tects Should Cope With This

So ar­chi­tec­ture is now a team sport (if that is not clear then you should prob­a­bly re-read the pre­vi­ous sec­tion).

How do you adapt to this new way of team-based ar­chi­tec­ture? Ar­chi­tects have to be­come bet­ter team play­ers. That sounds sim­ple enough but it can be chal­leng­ing for sure.

Some con­crete guide­lines:

1. Em­brace Iter­a­tive Im­prove­ment

• Make sure that the vi­sion is shared be­tween the prod­uct own­er and the ar­chi­tect - so the vi­sion guides the fi­nal ar­chi­tec­tur­al goal.
• Fo­cus on what is "good enough" for now (but make sure it does not make the ar­chi­tec­tur­al end vi­sion more dif­fi­cult to im­ple­ment) - so the team feels con­fi­dent that the cur­rent sprint's work de­liv­ers tech­ni­cal progress.
• Guide con­ver­sa­tions to­wards chal­lenges you think will be en­coun­tered - so you can share con­cerns with the team and they can help achieve the goals.

2. In­volve the Team and Keep Them Safe

Also, make sure that the team does not view the ar­chi­tect as a bul­ly-ish im­ped­i­ment:

• Ar­chi­tects should look at fail­ures as "op­por­tu­ni­ties to get it right", rather than in­com­pe­tence - so team mem­bers feel safe enough to make mis­takes.
• Ar­chi­tects should ask safe ques­tions: NOT “why did you do that?” but rather “what made you de­cide on that ap­proach?" - so team mem­bers don't feel at­tacked.
• "We are smarter than me": re­alise that two or more peo­ple al­ways know and see more than just one - so you re­al­ly val­ue the in­put of team mem­bers (and maybe even get to learn on the job).

Sum­ma­ry: Be a Tech­ni­cal Prod­uct Own­er

The ar­chi­tect role could (should?) prob­a­bly be re­named into "tech­ni­cal prod­uct own­er".

Ref­er­ences

The orig­i­nal ar­ti­cle can be found here. As stat­ed ear­li­er on, this re­view gives you a con­densed view of all you need to know - with our own orig­i­nal in­sights added where pos­si­ble.