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


835 views5 Comments

VP of Engineering in Banking, 201 - 500 employees
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.
2
Senior Director of Engineering in Software, 501 - 1,000 employees
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.
2
Chief Enterprise Architect in Finance (non-banking), 10,001+ employees
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
Owner, Self-employed

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.

Owner, Self-employed
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.

Content you might like

Limited understanding of benefits18%

Organizational silos61%

Unclear communication53%

Employee skepticism55%

Resistance to existing workflows16%

Unclear roles20%

Job security concerns4%


51 PARTICIPANTS

545 views

CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
46.6k views133 Upvotes324 Comments

Coaching and mentoring11%

Facilitating/scaling Agile46%

Removing impediments22%

Owning best practices11%

Leading Scrum meetings4%

Tracking progress2%

Sharing Agile knowledge across the org2%

I’m not sure2%

Something else not listed here0%


95 PARTICIPANTS

812 views

Director of IT in Education, 10,001+ employees
Learning, Pseudocode, Code completion, quick answers
1
Read More Comments
2.7k views2 Upvotes2 Comments