No Design up-front
Being an agile evangelist I keep pushing the “no design up-front” message constantly in my daily working life. Before you totally freak out on me let me just explain what I mean with “no design up-front”:
I am referring to the lack of effort put into “traditional” architecture exercises like component and class diagrams, collaboration or sequence diagrams etc - and particularly ER diagrams. Yes that’s right - no database design!
Having said that there are of course some fundamental decisions to be made before you start out: platform, frameworks, data access strategy etc. Do you have to put some thought into it to make these decisions? Absolutely! But with experience you will already know your options and be able to map them to the high-level architectural requirements.
To avoid a theoretical discussion let’s look at a real-life web application. When smartbeanz started out we did not have a full set of requirements - we just had a vision and a core road map. We also knew that the solution has to be modular as there will be continuous enhancements and additional features coming up. They had to be testable in isolation and of course we expected the database schema to change frequently.
With that in mind we made the following fundamental decisions:
- We use .NET 2.0 as a platform - it’s our area of expertise so there was never really a question
- We use the Web Client Software Factory (WCSF) as the application framework - we favored WCSF over frameworks like MonoRail because of our familiarity with other versions of the Composite UI Application Block (CAB) like Mobile Client Software Factory and Smart Client Software Factory
- We use NHibernate 1.2 as our database access strategy - ORM allows us to focus on domain objects with the ORM tool managing the database and schema
That’s it. Based on past experiences the main components were identified quickly and we could start addressing the actual business features.