AgileTHIS

One of the less understood and hence less discussed topics of Agile software development is Architecture. Traditionally architecture is seen as an involved process (if done) done by some elite group of technologist called "Architect." They create these blueprints and visions that are very difficult to understand and hence probably unrealistic to implement. That is why Agile community probably carefully avoids talking about it. We cannot ignore it, yet we cannot live without it. If we do it the traditional way, we cannot be Agile. This has created a misconception among many that Agile community has discarded architecture. This cannot be further from truth.

Having practiced Agile/Scrum on small and large projects for last few years, I thought about collecting my thoughts on Agile and Architecture. So, I figured the best way to create some guideline on Agile architecture is to create a test to determine whether an architecture is Agile or not. Here is the "Agile Architecture Test,"

1. Can you describe your solution using standard well-understood solution concepts (i.e., CRM, ERP, DW, e-commerce, etc.)?

2. Can you describe your solution in terms of one or more well-known architectural patterns (i.e., MVC, Hub and Spoke, Pipe and Filter, etc.)?

3. Can you describe your solution in terms of COTS/Standard products/components (Web Server, Application Server, Integration Server, ORM tool, Database, framework etc.) using a simple block diagram?

4. Can you describe your solution in terms of a domain specific framework?

5. Do you estimate features in terms of components of the framework (domain specific) needed to be modified and/or added?

6. Do you build and run regression test as often as there are changes committed to the system?

7. Can you deploy your entire solution at the push of a button to any environment (i.e., test, integration, production, etc.)?

8. Can you determine the health of your end-to-end system at any point in time in a minute or less?

9. Does your system notify you when something is not working?

10 Can you determine cause of a problem in your system in less than 30 minutes?

9. Can you run multiple versions of the solution in the same physical environment?

10. Is your test environment an exact replica of your production environment?

11. Is your dev environment an exact replica of your test environment?

12. Can you define your production environment as a multiple of your test environment in terms of deployment footprint?

13. Can you do load testing at will?

14. Is your solution database independent?

14. Is your solution, if applicable, supports all browsers?

15. Can the deployment footprint of your solution grow and shrink with the load?

Some of the questions are more geared towards solution using cloud computing environment like Amazon Web Services. I believe cloud computing has greatly enhanced the agility of a solution architecture.

If you spend more the two weeks (sprint 0) on architecture, then you are over thinking it. Jeff Sutherland and Ken Schwaber echoed the same at the Fall Scrum Gathering in Stockholm last year. If you have an enterprise architecture guideline, that is even better. Some of the decisions have already been made for you. Architectural constraints can be liberating.

OK, I might be oversimplifying here. Sure, there are edge cases. But, the point is that most systems do not fall under the edge cases. I will be interested to know what you think of this test of agility of a solution architecture.