The conflict between agile and architecture (part 1)

There is none

I've written about this before (Everybody is an architect, except when they're not), but let me start by saying it again - there is no conflict between agile and architecture. Even the most agile of projects will have architectural concerns of some description and these things need to be thought about up front. Agile projects therefore need architecture.

Where is the conflict then? Well, the conflict is between the desired outputs of agile versus those of big up front design. One of the key goals of agile methods is to deliver customer value, frequently and in small chunks. It's about moving fast and embracing change. The goal of big design up front is to settle on an understanding of everything that needs to be delivered before putting a blueprint in place.

Separating architecture from big up front design

"Architecture" is about the stuff that's hard or costly to change. It's about the big or "significant" decisions. It's the sort of stuff that you can't easily refactor in an afternoon. For example, this includes core technology choices, the overall high-level structure (the big picture) and an understanding of how you're going to solve the complex/risky/significant problems. Big up front design typically covers these architectural aspects but it also tends to go much further, often unnecessarily so. The key to just enough up front design is to differentiate what's important from what's not. Defining a high-level structure to put a vision in place is important. Drawing countless numbers of detailed class diagrams before writing the code most likely isn't. Understanding how you're going to solve a tricky performance requirement is important, understanding the length of every database column most likely isn't.

The waters are muddied in the real world

There's a part 2 to this blog entry but before that I want to try something. The problem with the real world is that it's less than ideal, particularly with respect to software projects. Unless you're incredibly lucky, there will always be real world constraints that prevent you from taking a text-book approach to solving problems. In his QCon London 2011 presentation entitled Why Don’t We Learn!?, Russ Miles explains that this doesn't really matter. And I agree - you just have to find something that works for *you* rather than jumping headfirst into "the next big thing" because "it worked over there for them".

So here's my challenge to you. Let's imagine that you've been asked to lead a software project to replace an ageing Internet Banking system. The key facts are presented in the image below. To constraint it further, let's say that rebranding the existing system is out of the question and you've been committed to a delivery at the 4 months point. After all, things like this do happen in the real world.

Conflict between agile and architecture

This is a fictional situation but it highlights some of the real world challenges that many software projects face. How would you approach this project? What would you deliver? Feel free to leave a comment or copy the image if you want to post something longer on your own blog.



Re: The conflict between agile and architecture (part 1)

I wrote a series of posts on evolving architectures and raises some similar points - which you might find interesting http://arnon.me/category/blog/featured-posts/agile-architecture/ Arnon

Re: The conflict between agile and architecture (part 1)

OK, I'll bite :). For me I'd go through an evaluation and prototyping process. I typically go through Matt Raible's 20 point check list for picking a web technology stack. If covers all sort of questions ranging from technical (does it support txns) to more cultural (does the tech stack fit in with the existing IT infrastructure, can you hire developers for this tech stack etc). I'd pick a couple of stacks to then prototype for 1 week each, tackling what I perceive to be the pain points for the application (tackle the hard stuff first). Given the fact that there's a short time frame, I'd also be pretty adamant about having a co-located team of users, business people, developers etc

Re: The conflict between agile and architecture (part 1)

Good stuff. So then, let's explore further ... you mention pain points; what might these be in this situation? And why tackle them first?

Re: The conflict between agile and architecture (part 1)

Off the top of my head (normally I'd sit down with the client/team to hash a lot of this out) I think the pain points are: * Transactional read/write access to the banks internal systems (is there a layer API already or do we have to build one) * Security (it's banking!) * Possibly the W3C stds, depending on which ones they mean. More importantly what browsers and clients are we expected to support? IE6 or a mobile phone browser could be a pain point. * Branding I'm not too concerned about depending on how far advanced they are with the design of the new brand. * Better usability I'm not so concerned about, I'd try to make sure we have a focus group of users + I'm assuming we've got a Ux/UI expert on the team + some enthusiastic end to end developers. If not I'll hire some :) * Last but not least, what features does the new system really need? Was the old site well thought out from a business perspective? If it was then we can focus on the technology, else we need to really get some core user stories worked out. As to the "Why the pain points first". You always want to identify (if possible) the biggest areas of risk, the items that are make or break for the project. For example, if one particular web stack didn't support txns properly, I'd want to find that out in my 1st week during a prototype, not in month 2 when the first user testing fails...

Re: The conflict between agile and architecture (part 1)

Grr, formatting fails for comments on this blog for me :(

Re: The conflict between agile and architecture (part 1)

Honestly, I think I would say no to any "Death March" [Yourdon 2003] and just change gigs. @Verburg Could you cite the 20 point checklist? Apparently, my google-fu is weak as I can't find them :(

Re: The conflict between agile and architecture (part 1)

@Mike, here's the list, apologies if the formatting is out.
  1. Developer Productivity
  2. Developer Perception
  3. Learning Curve
  4. Project Health
  5. Developer Availability
  6. Job Trends
  7. Templating
  8. Components
  9. Ajax
  10. Plugins or Add-Ons
  11. Scalability
  12. Testing Support
  13. i18n and l10n
  14. Validation
  15. Multi-language Support (Groovy / Scala)
  16. Quality of Documentation/Tutorials
  17. Books Published
  18. REST Support (client and server)
  19. Mobile / iPhone Support
  20. Degree of Risk

Re: The conflict between agile and architecture (part 1)

Many thanks for another great post, and once again really useful in my main field of enterprise-architectures. I addressed some closely-related issues in a recent post of mine, 'Agility needs a backbone' - compare and contrast, perhaps?

Re: The conflict between agile and architecture (part 1)

when I seen title I was interested to read but same time curious about why , but as I read through I find that you come to the point where agile and architecture complement each other. anyway nice post. Javin How Synchronization works in Java

Re: The conflict between agile and architecture (part 1)

A few consideration that I put on my own blog: http://chmeee.dyndns.org/blog/Kero/20110509-000840-Kero_four-months-to-improve-a-banking-system After writing, now reading comments, good to see additional stuff from Martijn and others.

Re: The conflict between agile and architecture (part 1)

One of the first tasks for me is determining scope, if you have a fixed delivery, and fixed resource, then you cant have fixed scope. One of the three variables has to give. So establishment of scope even at a high level is important to establish the feasibility of delivery. On a 4 month project the feasibility of parachuting in extra resource is low, given the warm up time for a resource. Its also important that you have an active engagement with the product owner/client from the start, and that they are continuously engaged. The importance of a scope stack that is adequately prioritized is important. We use a set of standards for code construction, and once the scope has been determined the first task we normally undertake is setting up mock objects, unit testing and CI. Getting this right from the start greatly eases the flow of the project.

Re: The conflict between agile and architecture (part 1)

Why is rebranding out of the question? It seems to be the only point actually creating a time-constraint.

Other than that, I'd probably start with figuring out what is the most uncertain and risky. If people are already familiar with some web-stack, focus on some of the other things you know less about. Build skeletons and fake out the stuff you feel you already know enough about and learn the stuff you don't.

Re: The conflict between agile and architecture (part 1)

A very practical scenario that happens over and over everywhere. ok ... so there is 16 weeks ( 4months) available. Fixing the Scope is the single most difficult as well as the critical piece. Scope shall then dictate the work breakdown ( Sprint plans ). If we assume it takes 2 weeks to nail down the sprint and 2 - 3 weeks of testing, it would leave us with 10-11 weeks. That's about 5 spring cycles ( 2 week each ) What goes into fixing the Scope ? 1. Gap analysis ( what is there and what is needed ). Debate around the need for all the features ( like whats wrong with Read-only DB - it may perhaps improve performance - provided it meets all business requirements). 2. Prioritization of Gaps. 3. Technology Choice ( I would go for GWT kind of technology ). 4. Usability - Wireframes by a Usability Group ( or use commonsense and come up with one ). 5. Technical changes - Transactional, real time could mean either connecting to the production DB or hot replicated slave. 6. Skill set of available team Vs recommended technology choices ( like if no one is comfortable with GWT, then settle down to struts 2.x) or so. Once Scope is thus frozen, create the product backlog and sequence the sprint plans. Plan for 2 sprints at a time and then keep making minor adjustments to the plan on a continual basis. 4 months is still a tough ask, But by proper scoping and prioritization, it doesnt have to be a big deal.

Re: The conflict between agile and architecture (part 1)

Very interesting challenge! I assumed a much larger financial institution than others and added some assumptions based on my career in and out of banking. I responded in detail on my blog here: http://bit.ly/itesSP Thanks for the posing this challenge!

Re: The conflict between agile and architecture (part 1)

I would also use checklists. I would make sure my team is ring fenced because this is one of the hardest things to get upper management to agree upon in my experience. I would bring us into a small working area and we would hash out the stories (I would use SCRUM) and our current progress would be displayed on a white board with stickies. I would get test involved early as a member of the team. If I could do this, I would be successful. The problem is it is hard to get this all.

Add a comment Send a TrackBack