If you accept this fact—that the choices you make today will most certainly be wrong in the future—then it relieves you of the burden of trying to future-proof your architectures.
—Richard Monson-Haefel, author of 97 Things Every Software Architect Should Know
It continues to amaze how some agile advocates fail to recognize, and even deny, that when you put together something as simple as two objects, you've created architecture (definition: a description or specification of behavior, appearance, structure, and relationship of and among components).
Thus, when some agilists say they need not concern themselves with architecture, or that it is not all that important, I wonder what planet they are on. Attention: even if it's not written down, or put to powerpoint, a system (two objects, or more) has architecture, and their behavior jointly may well be important and worthy of evaluation.
And yes, I'm aware of this agile principle: "The best architecture, requirements, and designs emerge from self-organizing teams", though I'm not alone saying this principle is decidely limited to the small bore and fraught with scalability issues.
My attention was drawn to a posting by Phillipe Kutchen entitled "Agility and architecture koan" for two reasons:,
- I did not know what "koan" means; I thought I might find out.
- He quote a truly mindless statement from a LinkedIn group: “Self-organizing teams can decide everything by themselves. So they don’t need an architect.”
- The former means paradox, or non-sensical statement or question
- The latter is just mindless, but to give the widest possible latitude, perhaps the author was referring to a dedicated position called "architect" and not trying to say that team members should not be architects, or worse: there's no architecture per se.
And, of course, even unabashed and credible agilists like Dean Leffingwell, author of numerous well regarded books and articles on software practices in general and agile practices specifically, says that as a project becomes more than the scope of one team working:
And no less an eminence than XP's Kent Beck writes:For developers, architects, and businesspeople who have experience building large-scale systems and portfolios consisting of systems, products, and services—with the extensibility and scalability a successful solution demands—a solely emergent architecture is counter to our experience. We know that some amount of architectural planning and governance is necessary to reliably produce and maintain such systems. Individual teams, products, and programs may not even have the visibility necessary to see how the larger, enterprise system needs to evolve. It can’t simply emerge. Something has to tie it all together......
Even minor, system-level redesigns can cause substantial rework for large numbers of teams, some of whom would otherwise not have to refactor their module. It is one thing for one team to redesign their code based on lessons they have learned; it’s quite another to require ten teams to do so based on another team’s lessons learned.
Architects on an XP team look for and execute large-scale refactorings [and] write system-level tests that stress the architecture....
While the system is little, the architect makes sure the system has just the right little architecture.
In another space, Computing Now, Maurizio Morisio provides a half-dozen links to reputable thinkers about the role of architecture, architects, and the intersection with agile methods. Take a few minutes, and read all about it!
Source:
Chapter 20 "Agile Achitecture" from Dean Leffingwell(2010). "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise", Addison-Wesley Professional. Kindle Edition
Chapter 10, "The Whole XP Team" from Kent Beck (2004)"Extreme Programming Explained: Embrace Change" Second Edition; Addison-Wesley
Are you on LinkedIn? Share this article with your network by clicking on the link.
