R – Making decisions about the architecture of your project; what is your decision process like

Architecturen-tier-architecturescalability

Many of us, who have designed and developed systems from scratch, have been in situations where you had to make tough decisions about the architecture of a project. Where did you, or would you, draw the line on taking the "next step" in building an architecturally sound, and scalable system?

I've built a large scale web site that was rather collapsed in terms of architecture. There was a web layer with the front-end code, then business and data layers that handled the real work to be done. The various layers of logical separation co-existed on the same physical machine. A physical, or even simply logical, separation could have existed through the use of a web services layer/tier. For various reasons, it wasn't implemented that way. Whether the decision was right or wrong is simply a matter of opinion. I've been in other situations where a relatively simplistic application was over engineered, from my point of view.

What are some of the factors you consider while designing the architecture for a new project? Do you have a consistent project design you often use, are you n-tier from the start, or do you evaluate as each project comes in?

Having these experiences repeatedly, I often wonder how others in the same position justify and make these considerations. I'm sure we all will have varying opinions, but I believe understanding the thought process behind the opinions will be enlightening.

Best Answer

The correct architecture for a given problem depends entirely on the problem. Your question is too general to offer a real answer, other than to say I keep the architecture as simple as I can to account for all known and expected requirements, but no simpler.

EDIT:

For "typical" business solutions, here are some of the factors that I consider:

  • UI

    • Can it be web-based? What are the user interaction requirements?
    • If a classic web interface is not sufficient, can I use a more interactive technology such as Sliverlight?
    • If it has to be thick-client (yes, there are still scenarios that justify that), how serious are the deployment challenges? Small user base, large user base? Do I need to include automatic updating? Does it need to be enforced?

  • Business Layer

    • Do I have performance/scalability considerations that require a physically separate business layer? (My business layers are always logically separate, and easy to physically separate if need be. I sometimes use CSLA to allow for that decision at deployment time when targeting Windows, but that's a heavy framework and not always appropriate).
    • How simple or complex are my business rules? Are they likely to evolve considerably over time? Is it worth incorporating a rules engine such as Drools?
    • Are there asynchronous processing requirements? Do I need a work queue system?
    • Are there external systems to interface with? What types of interfaces to they present? Web service, COM+, XML over HTTP, proprietary, DB, batch files, ...?

  • Data Persistence

    • What ORM choices are available to me given any pre-existing platform choices/constraints?
    • Will I benefit from extensive use of stored procedures? Will there be a DBA to maintain stored procedures and modify them over time? If no DBA, I only use stored procedures where really necessary for performance. If there is a DBA, more extensive use of stored procedures gives the DBA flexibility to manage the physical architecture independent of the application (but as with all added complexity, that comes with a cost).

  • Cross-Cutting

    • What are the security requirements? Is there an existing mechanism (Active Directory/LDAP/...) to be integrated with? Do I need to support role-based security?
    • What are the operational monitoring requirements? "Report this bug" functionality? Simple logging?
Related Topic