A few years ago I was thrown into the deep end and was put in charge of some really large systems. Up until then I had primarily been working in development teams on very large systems that required teams of up to 50 people across all boards. Realising how large and technically complicated those systems were and how incredibly stressed most of the stakeholder and team leaders were I began to think was this really the job for me. Being the incredibly chilled person that I am I started to realise that this enterprise software world was not as chilled as I am and for a while wondered if it ever would be.
Until somebody gave me a book to read “Patterns of Enterprise Application Architecture” by Martin Fowler this book save my life and it instilled a belief in me that large enterprise applications development need not to be a difficult and stressful process and by following some basic values , methodologies, principles and with the help some very clever tools we could tame this beast called enterprise applications and together the beast and I could sit back and CHILL and develop something special and at the same time keep the stakeholders happy.
Martin Fowlers laid back style of writing and his constant re-iteration of a “KEEP IT SIMPLE” approach and together with a “BEST OF BREED” methodology made me realise that application architecture need not be the stressful part of application development.
In this book his recommended architectural design pattern for an ASP.NET Web application development was the Table Module Architectural design pattern.
This statement causes quite a stir in the development community between the DDD (Domain Driven Development) /nhibernate followers and the MDD followers.
Personally I feel that MDD is the only architecture to go with when developing web applications.
Being predominantly a web application developer and a Microsoft junkie I began using the Table Module Architectural design pattern and started adopting a MDD (Model driven development) approach to architecture. Then a natural progressions lead me to an AMDD style of development. And by adding a little fun to it I developed the AGILE DISCO BALL methodology. I will go into more detail about the AGILE DISCO BALL in future blogs.
After adopting these methodologies I notice an immediate result, I began enjoying the world of software again and notice a huge success rate when delivering large scale applications.
My world was CHILLED once again.
But at the end of the day it comes down to personal preference. I believe if you are going to be using agile methodologies in your development environment apply some of the same values when choosing your architecture.
1. Simplicity. “KEEP IT SIMPLE.80% of web applications outlive the developers working on the project .A simple architecture allows for easier handover, future scalability and ease of use. I will go into a lot more detail about simplifying architectures and tools that can be used in the development process in future blogs.
2. Courage. Choosing an architecture for a large enterprise is a huge responsibility. And by sticking to what you know and by playing on your strengths you will have the confidence to choose the best architecture to suite your style, personality and skill.
3. Humility. “DON’T BE A SMART ALEC” The best developers today are not afraid to say that they are wrong nor are they afraid to ask for help. However smart you think you are there are people out there that are smarter and no matter what problem you have there are people out there that have solved it. Another thing that Architects must realise that the people that are going to be doing the development on your project are not as experienced as they are and the people that might be taking over from you might also not be as experienced. So when developing an architecture, develop it in a way that you are NOT going to be the only person in the world that is going to understand it.
By following some of these basic values when designing and choosing a web application architecture, I believe that you will have a better success rate when developing systems and will more have time to argue with stakeholders whether the font should be pink or blue.
Please join me for my future blogs where I will be discussing why I think projects fail, Agile modelling, MDD and some of the fundamentals of building a successful web application. I will also be going into more detail about my AGILE DISCO BALL THEORY.
Hi there my name is Stanton Roux. I have 12 years experience in developing web applications. I have my MCSE and MCSD.NET and I am currently working as senior software engineer for WebNow.