Digital Journey

“Architect must code. Manager must code. Scrum Master must code. Tester must code. Product owner must code. Developer can become architecture owner. Developer should become tester. Developer must understand customer challenges”

The way the debate goes, it almost seems like everyone is trying to do someone else’s job. And, this behavior gets justified as self-organizing teams.

In a real world, people have mustered skills and aspire to learn new skills. This is true for an architect as well. It’s very rare, that we are able to assemble the perfect team. Mature @ t=0.

It’s important to pull your weight as part of any effort/job. If coding is your strength, do it. If customer engagement is your strength, do it. If inspiring people is your strength, do it. If making choices (trade-offs) is your strength, do it. If you have multiple skills & you are ambidextrous, do it (lucky!). Just don’t burn yourself out, doing it all.

If the challenges for the team are not architectural (i.e. most architectural choices are made and time tested, or, team is mature and governance is not required), then the architect needs to pull his/her weight to address the challenges. This may mean coding, testing, and/or selling. If this type of work is not interesting (or boring or offending), it’s time to change than be a burden.

If the challenges for the team are realizing the architecture, and they look up to the architect for help, the architect MUST code to show how to get things done. It’s OK to ask for HELP, if you believe the architecture is right, but you don’t have the coding skills to get it done. It’s part of learning journey.

Winning is important. Need to give yourself permission to do the right thing. Sometimes, the right thing is to go up the Ivory Tower and preach. Sometimes, the right thing to do is go down the trenches and teach.

It’s a trade-off.

In this new brave world, anything can be said, done, and justified.

This sentence is complex. English! My god. Such a complex language.

• Continual = repeatedly (say the tv show is running continually)
• Continuously = non-stop (say the tv is running continuously)
• Emerge = come-out (say a baby bird emerges from egg)
• Evolve = grow-into-a-new-state (say a caterpillar evolves to a butterfly)

So,

• Continual emergence = A new architecture showing up repeatedly (every sprint or PI) for life.
• Continual evolution = A new architecture after emergence, evolves repeatedly to adapt to repeated change in requirements. The architecture continual evolution stops, when requirements continual evolution stops; i.e. Product is mature & moving to EOL (end of life)
• Continuous emergence = A new architecture showing up every day (or second) for life.
• Continuous evolution = A new architecture after emergence, evolves non-stop to adapt to non-stop change in requirements.

Practically speaking,

•  In the early stages of the project, the change in requirements that impacts architecture can be  continuous. Architecture also emerges and then evolves continously.
• In the later stages of the project, once requirement volatility has been addressed, the  architecture remains more-or-less constant (gets cemented) and changes are infrequent. Architecture is evolved continually to address new requirements that would have emerged requiring architectural change. This architecture change could be a costly (impact regression, $) project.
• The software does reach a state, where change in architecture, is hard to address certain types of requirements. At this time, a phoenix (re-birth) or hydra (supplement) type strategy is required.
• The software finally does reach a state, where disruptions and innovations in the industry, would have disrupted the value proposition, or architecture. This is the time to EOL the product.

In Summary, though anything can be done i.e. continual or continuous emergence or evolution of architecture throughout the product life cycle, it’s not the norm. Emergence happens early, evolves continuously till proven, has a few (less than 3) major continual evolutions during the life of the product.

Having the power to do something, does not mean it’s a responsible thing to do!