This is part II of P is for Principles (and Guidelines and Constraints…) – Iteration I
In the previous entry I’ve said that it is helpful to provide a list of constraints and principles as it helps in limiting the scope of the solution and directing it toward good (and/or required) practices (Architectural, technological or business aligned). However, I also claimed that a simplistic list is problematic – I’ll try to demonstrate this through a couple of real-world examples:
I recently reviewed the software architecture document (SAD) of a rather large software project, I saw that they it is mentioned that the project uses “service oriented architecture” – reading on, I saw the architecture builds on a distributed “shared memory” where every client and server has a full image of all the data entities, further more data entities are intertwined without any boundaries whatsoever. when I asked what’s service oriented in that, I was told that the underlying distributed “shared memory” engine provides several services like dissemination, scheduling etc. The point here is that a catchy name can mean different things to different people.
On another project some of the stakeholders mentioned it is important that the solution would have an “Open Architecture” – sound good to me, but what the hell does that mean? based on open standards? promote extensibility (easy to add features)? promote replacability (easy to replace components)? all of the above? something else?
Furthermore if you don’t understand the implications behind each of the principles you name – it gets very tempting to create a “Buzzword Oriented Architecture”- we want SOA, AOP, Software Factories, Smart clients, GRID, fault tolerance and whatnot… (Note – It is recommended to proceed with caution if you see too many buzzwords in your guidelines/goals. You might be trying to accomplish too much and/or you have too much marketing influence).
So what makes a good (or at least better) description for a principle?I currently use the following template:
Name – something easy to remember (e.g. SOA, Layered Architecture etc.)
Description – What does it mean
Rationale / Benefits – Why do we want to apply this principle
Implications – What does it mean to use it
Alternatives – What else – What are the other options we considered and why we didn’t use them.
Scope/Exceptions – when and where does it apply
Note: I used to use a simpler template (whiteout Implications and Scope) the current version is based on a template by Ilia Fortunov from Microsoft UK. I can explain that further but it will probably be easier to understand through examples – so here are a couple from projects I worked on:
Principle Name: Code Generation
Description:Generate specific implementations and allow users to configure generated code via designers.
Rationale/Benefits: Increase longevity of the domain model (help separate from technical implementation). Reduce bugs via use of design tools.
Implications: Need to “templatize” solutions and develop code generators (need to check commercial solutions)
Alternatives: 100% object orientation and generic implementations. rejected due to tight coupling to technology, performance implications and impact on code readability.
Scope/Exception: Domain entities and any “aspect” related implementation (logging, security etc.)
Note: this is for a solution that has to use .NET 1.1 – had it been for a solution that relies on .Net 2.0 Another option – using Generics might have been a viable solution
Another example:
Principle Name: Distributed Database
Description: Each site shall have a separate independent copy of the DB and will have to synchronize its data with connecting sites (Note that I use the term synchronize and not replicate – as replication is a specific technical solution)
Rationale/Benefits: The inter-site communication medium is unreliable plus sites has to maintain autonomy.
Implications: The system has to cope with partial data. There’s a need for conflict resolution policy. We need to consider idempotent messages for inter-site communications. Need a distributed primary keys management scheme.
Alternatives: Federated database – problematic since (some of the) data will not be available when sites are disconnected. Another solution weighted is a combination of centralized server and “off-line” capabilities upon disconnection – rejected as it would be more complicated (based on past experience) and have high-dependency on bandwidth (for on-line work)
Scope/Exceptions – Database layer and inter-site communication.
The next thing we have to deal with are constraints.As I’ve said in the previous post constrains originate from the different stakeholders and limit the scope of the solution. To document the constraints in a meaningful way I use the following template:
Name: something easy to remember
Definition: What does it mean
Implications: What does it mean for the architecture? what are the limitations it places.
Scope: where will we feel the impact
Origin: who placed this constraint and why
Again, lets look at a couple of examples:
Name: Use .NET 1.1
Definition (pretty obvious…)
Implications: use tools/products compatible with .NET 1.1; don’t relay on .NET 2.0 capabilities (important for the mapping stage of the SAF)
Scope: All the system
Origin: using .NET is a company policy; we need .NET 1.1 since all the existing tools (e.g. ClearCase, XDE) only support 1.1
And another example:
Name: Deadline
Definition: We must have a working deliverable in 5 months.
Implications: Strive to reuse existing assets; try to migrate code from legacy version; try to model (an extensible) simple architecture (don’t try to solve everything now – but try to leave flexibility for future growth)
Scope: Mapping stage; Architecture documentation; quality attributes of the solution
Origin: Customer (time-to-market)
One thing important to remember is that we are not interested in all the project’s constraints (we are- only not in this context). The meaningful constraints are those that have implications on the architecture.
To summarize. Principles and Constraints help you limit the scope of the intended solution architecture. Principles are based (mostly) on past experience, constraints must be followed (and are originated from the different stakeholders). Using only a catchy phrase to describe either of these (Principle or Constraint) can prove to be problematic (creates confusion, doesn’t really add anything etc.) and it is better to think about the implications of applying the principles and constraints. Lastly, principles (at the first stage) should be taken with a grain of salt – as they may not be suitable for the current requirements – you should be ready to reiterate and update them once you know more about the requirements (The end result would be to have a list of guidelines which are actually used for the solution’s architecture).
Both templates (principles and constraints) are available for download on the template section of the SAF page.
