From Dwayne Wright PMP, PMI-ACP
Certified FileMaker Developer
I came across this post today ( Agile Architecture: How Much Is Just Enough? ) in my news reader and wanted to add some comments to my future self and the few others that might read this journal. In my day job, I'm struggling with a few projects because of their complexity, support debt of previous projects and some stakeholders that are adding more projects to my roadmap without due diligence of checking (respecting) my availability. It is a wicked collection but something that can always come about with a string of successes, lots of folks want a piece.
This is why I'm becoming more enamored with LEAN and utilizing some of its keys internally for my own needs. This is an edited list from ( Agile Architecture: How Much Is Just Enough? ) that I think I might bring to one of my key stakeholder meetings. By key stakeholders, I mean the users because I don't share the philosophy that upper management play much of a significant role beyond financing budgets. Here is the nugget ...
To put things in perspective, if we want to set guidelines on getting started with an Agile architecture, we can put down a few simple steps that will help us understand how we dive in:
- Identify business objectives.
- Establish architectural objectives.
- Identify key scenarios/actors.
- Draw an application overview.
- Identify design coupling points.
- Create candidate architectural solutions.
- Inspect and improve.
By all means, please read the entire article and I think you will understand why I think this content could be used to help guide the user / designer team a nice unified software tool creation process. It may become a key artifact in all kickoff meetings and perhaps even an internal roadmap for the team to follow.