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
- Exception handling versus status code
- Instrumentation /Logging
- 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)
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
If I missing some points or you want to comment on this. Please feel free.