GeeCON Prague 2014*
The moose likes Design and the fly likes Still on Software architecture: Does Agile imply you must not have all of the big picture Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Design
Bookmark "Still on Software architecture: Does Agile imply you must not have all of the big picture" Watch "Still on Software architecture: Does Agile imply you must not have all of the big picture" New topic
Author

Still on Software architecture: Does Agile imply you must not have all of the big picture

charlsy chuks
Ranch Hand

Joined: May 18, 2012
Posts: 79
After going through a bit of the article in that link, I need some clarification on some issues
namely:
1. Does Agile style imply you must not have all of the big picture sorted out before starting the coding part
since changes will definitely come up and the software needs to be delivered "on time"?

2. When the tools you use do not favour quickly scrapping and re-generating the database schema for instance if changes are to be made
what do you do since there may not be a complete design some where? What tools do you recommend for Java and .NET programmers?

Thanks again.
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
It's a tricky balancing act to be honest. Most agile approaches don't explicitly talk about "doing architecture", and this can lead to the perception that agile approaches are simply about delivering features and letting the architecture evolve. If you've ever tried this with even a small team (3+ people), you'll know that you still need to ensure that everybody is consistently heading in the same direction. This doesn't resolve the issue that you could still end up doing a large amount of refactoring if you forget to factor in a major cross-cutting concern, such as security or scalability. This is why I talk about doing "just enough" up front design and being able to communicate using a lightweight collection of simple sketches. It's all about technical leadership and understanding where to put the up front effort.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2383
    
  28

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.
charlsy chuks
Ranch Hand

Joined: May 18, 2012
Posts: 79
Hmmm,
Submissions that you two have made only make it more glaring that an architect must be a good coder to be able to see ahead and prioritize what A and B should be in Lalwani Jayesh's words. On the other hand with regards to tools and patterns, when the architect does not know much about a pattern like MVC and his team members are equally green horns but he insists MVC must be used because of the benefits, I think you have a recipie
for trouble because initially the team will be slow (opposite of agile) as they will be learning new stuff and coding at same time.

Indeed as Simon admitted, Software architect is more than just a role or title. It's huge. Thanks for the answers

Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
charlsy chuks wrote:On the other hand with regards to tools and patterns, when the architect does not know much about a pattern like MVC and his team members are equally green horns but he insists MVC must be used because of the benefits, I think you have a recipie
for trouble because initially the team will be slow (opposite of agile) as they will be learning new stuff and coding at same time.


Yes, that's right. This is why I promote a risk-driven approach to software development. We don't (and can't) know everything, so it's worth addressing the risky things that could force your project to be cancelled or you to be fired. Processes like the Rational Unified Process (RUP) have said this for years, but somehow the focus on risk has taken a back seat in our new world of agile approaches and delivering features. As always, there's a happy balance to be found.
 
GeeCON Prague 2014
 
subject: Still on Software architecture: Does Agile imply you must not have all of the big picture