A comment came recently on one of my posts from someone who I respect greatly, Konstantin Ignatyav:
Do not you think that Architects actually have different reading of YAGNI: You Are Gonna Need It?
Architecture is about making solid foundation that will withstand time and carry the entire building along with unanticipated enhancements and additions. But Agile seems to favor short term benefits over long term ones, while architect values long term benefits over short term gains.
In the world short term benefits can be quite disastrous in the long run. Like our 200 years old industrial revolution seems to be destroying and poisoning our habitat now.
I agree that having a vision of architecture is needed for complex projects with heavy integration into the larger enterprise architectures. Understanding the business vision and a reasonable roadmap of technology is helpful in guiding product delivery. Also, you can’t beat having good people making good decisions when developing software. When does this happen? All the time, not just at the start of the project.
I would say that it is incorrect to say Agile favors short term over long term benefits. Actually, Agile is about proving the vision continually using real world examples and then applying the best one to the situation at hand. Agile does not dictate the use of any specific tools for this cycle but there are multiple concepts which are used in Agile methods and practices:
- Metaphor (XP)
- Refactoring (Fowler)
- Domain-Driven Design (Eric Evans)
- Inspect and Adapt
- Continuous Integration (XP)
- Product Vision
- etc…
All of these have potential need for the inclusion of knowledge that would usually reside with a true software architect role. In fact, Lean Software Development discusses the technology leadership role on teams and how important they are to project success. Some of us are able to view a project better from a high level business vision to a sound structure and ultimately an enterprise integrated solution. There are many ways to do this and I would not prognosticate that Scrum, XP, or any other Agile methodology is a silver bullet.
I do believe, however, that the basic values and principles of Agile can be used by people to develop processes which work best in their environment. I also believe that they must continually improve those processes to make sure they continue to be the best for the environment.
In the end, a great team and great business guidance must not be under valued. If we do not develop products which are easily deployed, maintained, and integrated effectively then there is improvement to be made. If we do not have a true product vision with high value prioritization then the ROI of our product will not be optimal.
Currently, at the team level, I expect ‘integrity’ to be built into the product from the beginning. The definition of ‘integrity’ is “free from flaw, defect, and decay”. Here are the tools which we use at SolutionsIQ to build integrity into our deliverables:
- Free from “flaw”: Automated Acceptance Tests (Executable Requirements)
- Free from “defect”: Test-Driven Design
- Free from “decay”: Continuous Integration and Refactoring
As ‘integrity’ is built into the product, we can also make sure that “architecture” is visible through the acceptance criteria of PBI (product backlog items) as they are moved to the sprint backlog. You may have different definitions of “done” for each PBI and quite probably architectural constraints for it based on the organization, product, and domain.
This is such a fascinating subject to me that I would like to keep going but I think it would be best if I tried to get some sleep now. Can’t wait to talk with you more about this over a pint, Konstantin. I am sure you will enlighten me on some things and I hope that I am interesting, as well.
