DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Comparing Cloud Hosting vs. Self Hosting
  • Five Java Books Beginners and Professionals Should Read
  • Alpha Testing Tutorial: A Comprehensive Guide With Best Practices
  • Hiding Data in Cassandra

Trending

  • Comparing Cloud Hosting vs. Self Hosting
  • Five Java Books Beginners and Professionals Should Read
  • Alpha Testing Tutorial: A Comprehensive Guide With Best Practices
  • Hiding Data in Cassandra
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Conflict Between Agile and Architecture

The Conflict Between Agile and Architecture

Simon Brown user avatar by
Simon Brown
·
May. 28, 13 · Interview
Like (0)
Save
Tweet
Share
10.01K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile Architecture

Published at DZone with permission of Simon Brown, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Comparing Cloud Hosting vs. Self Hosting
  • Five Java Books Beginners and Professionals Should Read
  • Alpha Testing Tutorial: A Comprehensive Guide With Best Practices
  • Hiding Data in Cassandra

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: