Software architecture decisions

Hello,

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,

Alexander