• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
sharp shooter, and author
Posts: 1913
6
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic