When you’re creating an agile architecture, how can you tell when you’ve built just enough?

Application Architecture Enterprise Architecture Engineering

915 views5 Comments

Sort By:

Oldest

VP of Engineering in Bankinga year ago

We should always think back from the first principle. Aim for using good enough architecture that can bring value to the users in a shorter feedback loop cycle. Evolve the architecture as necessary in each iteration.

Senior Director of Engineering in Softwarea year ago

I'm curious to know the definition of an "agile architecture"... But assuming that it is an architecture built incrementally I would suggest beginning with the end in mind.
The architecture should address a need / goal regardless of how it is built.

Chief Enterprise Architect in Finance (non-banking)a year ago

Architecture is about enabling change, understanding impact of change. Thinking about the vectors that enable change, to incorporate new requirements, ability to scale, add new user base, ability to promote change etc having those key factors in the Minimum Viable Architecture is important. Doesn’t mean you have to have all those addressed day 1 but creating that elastic scalable component architecture and then iterate. But foundation has to have the building blocks to allow for agility. MVA should also consider CICD for foundation of continuous architecture.

3 1 Reply

Please join or sign in to view more content.

By joining the Peer Community, you'll get:

Peer Discussions and Polls
One-Minute Insights
Connect with like-minded individuals

Ownera year ago

This is a really great answer. I have to agree that not every component of the change needs to be established ahead of time, but I think it's all too easy for an organization to spin up a new project without considering what the end result should enable them to do, or whether they have those building blocks you mentioned. Change is all about shedding past roadblocks, gaining new capabilities, access to new or broader sources of revenue, or just better efficiency. As long as the team keeps those main objectives in sight, making decisions about how to navigate unanticipated hurdles becomes easier. It's a fine line between being too cavalier and suffering from "analysis paralysis".
I'm going to stop now before I tangent into timeliness of change.

Ownera year ago

It's important to have a clear picture of the purpose of any new undertaking or change, agile included. In some cases, it can be so long overdue that the list of objectives is unwieldy and in other cases it can be so unnecessary that objectives look more like platitudes (increase efficiency, reduce redundant efforts). Planning ahead is probably the most underrated endeavor in any industry because it isn't glamorous, but it is very useful in helping an organization know when their objectives have been met.