Myth: Architecture in an agile project can be continually (or continuously) emerged & evolved

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!

Myth: Software Architect is a Technology Expert

I was reading a story to my two year old, “Some Dogs Do”. It’s a story about “Sid” a dog that can fly! A video description is available here.

On similar lines, “Some Architects Do”, rings a synonym bell to the story above. It’s the story of an architect that has multiple subject area expertise.

It’s hard to be an expert at everything. Full Stack Architect! Expert Architect.

In Trump style … It’s true. I know it. Look, expertise is godly. My mentor was an expert. I loved him. Very smart. It’s in the genes. My mentor could explain everything, he knew everything. If he was a she, she would be a smarter he. Trust me. It will take only 150 years to build expertise in everything – mark my words – do it. The engineers and managers are doing it; it will make you money. It will make you famous. Become an expert architect. It’s the only thing you have been born to do. I will invest in you. Go for it. Build universities to create expert architects. We will make architects great again! God bless architects!

The pursuit to expertise (one or two domains) is a good one. However, a better skill to have is to lead different experts to realise your architecture.

Hmm, that said, an architect will be called upon, to solve a tough problem (or a trade-off) as an architect.

  • A Database query is taking long time. How do I fix this Mr. Architect?
  • Which programming language should I standardise on? Python, Julia, or R? I hope the one that you choose, is comprehensive, trustworthy, and you could be called upon for your expertise, when we need help. Ok?

A call for help is usually a call for help. Phone numbers of experts to reach out is a good tool to have for an architect!

Some Architects Do.

Why this series of Blogs?

Never expected that I would land up as a Software Architect in my career. Did not pursue the discipline academically or systemically. Most of my career insights were obtained by:

  1. Being ‘present’ in architecture reviews of software products. Intellectuals brainstorming.
  2. Being a software engineer (designer, developer, tester) in my early career. Construction, Execution and Delivery of software products.
  3. Being a husband to an Architect. Observing the discipline of my better half.
  4. Being a coach/mentor to other architects. Being a mentee.
  5. Being a leader for an architecture community; internal to the company that I work at/for.

The internet is full of opinions and counter opinions; and I am in a position where I feel that I should simply write down my key insights for both my benefit (intellectual), and for any reader of this content to either appreciate and/or critique and/or build around.

Why this feeling? Don’t know.

My current target is to write down, at-least one blog (architecture insight, architecture anti-pattern, architecture pattern, architecture myth, architecture skill, …) on architecture everyday.