Architecture & Process

Lately, I've been surprised by how little attention some developers pay to application architecture. By architecture here, I mean to say the high level decisions that crosscut all the application code.

Recently, during the transfer of an application from another team, I was shocked that there was no clear vision of the main decisions regarding some fundamental aspects of a web application (I don't mean documented, just a clear definition of the decision or the approaches taken in the implementation). Every web application should make explicit the major decisions (and the reasioning behind them) regarding:

• Logging (policy - how, when; and tools/code)
• Exception Handling
• Data Acess (ADO.NET, ORM, Linq)
  • Transaction Management (sharing the same transaction, creating and commiting transactions)
• Session Management (asp.net memory, DB, custom)
• Security (low-level - sql injection, cross scripting; high-level - isolate data between different users/entitys/geographically)
• Profiles and Permissions (management of users/groups and the corresponding permissions on application functionalities)
• Operation Auditing (especially in financial systems)
• Composition (tiers, layers, service oriented)
• Dependencies (3rd party tools, components, services)
• Patterns used (MVC, Singleton, Composite)
• Naming conventions
• Configuration management (reference tables, configuration values, connection strings, etc)
• Concurrency (synchronizatios, async callbacks, threading)
• ...

 

There's also other important stuff, more on the process/principles side, that gain by being defined:

• Planning, prioritization & risk management
• Organization (teams, projects)
• Tools
• Automation of tasks (building, testing, importing reference data)
• Testing and Coverage (unit testing, integration testing, coverage of significant program states)
• Refactoring
• Documentation (design, architecture, glossary, major entities, workarounds to problems)
• Bug/Incident tracking
• Version Control (tool, policy)
• Communication
• DRY
• Responsabilities (code & people) and Separation of concerns
• Coupling & Cohesion
• Done?

 

As with everything, there's also the risk of overdoing stuff, or doing it as an end (and not as mean to an end).

If just 1/3 of the list were implemented, maintenance would be such an easier job...

Marcas Technorati: Architecture,Programming