Architecture again

Right after my last post (which I was on my mind because it happened to me a couple of times this year and the last year), I discovered (thanks to a post from a friend patterns & practices- App Arch Guide Pocket Guides) that MS PnP has some interesting stuff on this topic (shame for not looking recently on PnP).

Apart from the pocket guides, that I haven't looked into, what I found were some cheat sheets and diagrams.

PnP Application Architecture Frame Cheat Sheet describes architecture frames (authentication, caching, ... and 14 others), quality attributes (14) and the mapping between application types, architecture styles and the architecture frames (and the common issues). It's great stuff, and should be mandatory read for every developper. Shame that Microsoft only has teaching offerings around products (maybe that's what the industry cares about).

Another one is PnP Application Type Matrix Cheat Sheet that summarizes the main application types, their benefits, considerations, scenarios and solutions.

The last one is PnP Visio index Diagrams that MS makes available for modification and use to document our architectures. Even if only used for proposals, it's very good and allows reuse.

Marcas Technorati: Architecture,Programming

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