posted 10 years ago
The way I've done it is done architecture iterations that work ahead of development iterations. So, let's say you are completely "greenfield". People are coming to you "Go build this for me. Tell me what you need. I will get it for you. Tell me how long you will take. Build it anyway you want. The only condition is we want frequent releases so we can adjust as we go along" Fine! An agile developer's dream project, right?
However, from an architecture POV, it presents a challenge because it's all greenfield. There's nothing you build upon,. SO, you have to select all the tools, open source libraries, blah blah in addition to designing your application. You have to figure out what kind of security you want, what kind of monitoring you want yadda yadda. It;s actually a lot of design work. At the same time, you don't want to spend 3 months doing "architecture" because it's not very agile. Your client is getting pissed off because they don;t see nuttin, and in the meantime, they have gone ahead and changed requirements on you. Now, you are redoing your architecture work playing ketchup.
So, this is what I've done:- Break down the complete functionality into parts. Go back to your client/manager and ask them Out of these 5 things, what adds most value to you if it's delivered first. Then you add your own things to the list (security, auditing, monitoring) and rebalance the priorities with the client's priorities. You might have to rebalance the priority list once again because it might "make sense" to build a lower priority functionality before a higher priority functionality because the higher priority one "builds upon" the lower priority one. Anyhow you do it, you get a list of the functionalities (business and technical) in a prioritised list. Then you pick the top ones. You might say "For the next 3 months, I will focus on building A and B, and make sure the platform is stable. I won;t worry about functionality C and security right now".
This tells you what you will design for in the first architecture iteration. You design the system for A, B and stability while keeping C and security in the back of your mind, but not completely focusing on it. When you do the design, you keep the big picture in mind, and you come up with the target state of what it might look like if. Then you "plan out" the next let's say 3 development iterations by breaking that design into steps that start moving you towards that target. Planing the next 3 iterations doesn't mean that you will stick to the plan exactly. It just means that you are planning with the big picture in mind. You are deliberately preventing yourself from being myopic by looking at the more than 1 iteration.
This tells you what your team is doing in the next development iteration, and what you might do in the 2 iterations after that. Now, as the development progresses, you help out where you can, check the health of the project, check what crazy ideas those crazy business side people come up with, and start designing for the 3 iterations after the end of this one. So, it;s really architecture for future iterations going on in parallel with this iterations.
Things change in middle of your iteration? No problem, you don;t change the development plan for current iteration, but you change your architecture for the next 3 iterations. By limiting yourself to plan N number of iterations ahead, you are forcing yourself to consider a larger picture, and at the same time preventing a situation where you fail to design iteratively.
1
