Tuesday, 13 May 2008

Software architecture decisions


I recently had to give a definition of what a software architecture is . Not always that easy because Software Architecture is a much loaded term. If you want some formal definitions what a software architecture is , I recommend reading the information on http://www.sei.cmu.edu/architecture/published_definitions.html#Modern

General tone in these definitions is that you need to make high-level decisions about the system you' re going to build;
  • What style are you going to use? What is the structure?
  • How is it going to function? How do structural components of the architecture work together?
  • How does it meet the needs of all the stakeholders?

These high-level decisions have a high impact on the application. You can not change them easily if wanted or needed. Unless you’re prepared to put enough resources on the table.

In the bullets below I tried to sum up the different aspects of a software architecture. This list is not intended to be exhaustive.

  • Windows front-end or web front-end ( Rich Internet clients)
  • Layering, organization of code, separation of concerns,
  • Representing “business objects” persisted in a database
  • Exposed domain model or using Data transfer Objects / Presentation Model
  • DataSets versus classic classes
  • Organization of “back-end” logic
  • Organization of “Presentation” logic
  • Organization of “data-access” logic
  • Distribution or not
  • Remoting technology
  • Authentication, authorization, Audit
  • Data binding
  • Synchronous / asynchronous
  • ORM tools or raw ADO.NET
  • Multi-language
  • Exception handling versus status code
  • Instrumentation /Logging
  • Configuration
  • Caching
  • Database schema fixed or freely adaptable to need of design designs
  • Long-running “transactions” (conversations)
  • Reporting needs
  • Validation rules placement (Attribute based, Intra object based, Inter object based)
  • Etc.

It is important to take holistic approach towards the desicions. You will need to take some trade-offs and influencing criteria into account.

  • Kind of application built (taxonomy)
  • Tooling can constrain how you organize your application (code generators, frameworks, application building blocks, software factories ,etc)
  • Availability/knowledge of people can constrain the “feasibility” of your architecture
  • Process (top-down versus bottom up, behaviour-centric versus data-centric)
  • External / internal regulation can influence your architecture (SOX, internal Audit rules
  • Availability of reference architecture.
  • Non-functional requirements
  • Patterns
  • Time-to-Market
  • etc.

If I missing some points or you want to comment on this. Please feel free.

Best regards,


1 comment:

Anonymous said...

Check out our new social blog directory on the internet bloggersblaze . You can Browse, Search, Rate and Review various blog sites.