Whenever you start a new project, even if you think you start for scratch – you don’t really start from scratch. You always bring your past experience into the fray. Developing an architecture for a project is not different. the “Principles” stage of the SPAMMED Architecture Framework (SAF) is about bringing in your “lessons learned” and “best practices” as baseline rules or starting point for the architecture you are trying to build. laying down a good set of principles will help you limit the scope of the solution and focus on proven tactics.
It is important to note that principles you set should be treated as recommendations – the main reason for that is that they are based on past requirements and experience and not on current requirements.
An example for a principle may be “use layered architecture” Layered architecture is the practice where you define several level/areas of processing and limit the communication paths between them (common patterns are: layer can talk to the layer just below; layer talks to any layer below it etc. – the important characteristic is that communication is restricted). Layered Architecture brings a lot of benefits especially in promoting flexibility in deployment, modifying implementation etc. some of you reading this may think this is a trivial principle – however, sometimes it is good to put even trivial assumptions on the table, furthermore not everybody agrees that it is always needed see this for example. Lastly using a layered architecture has its risks for example the different layers can’t scale to the same extent you may find yourself with scalability issues down the road. (I’ll give more detailed examples for principles in the next post on this subject)
A similar notion to principles, in the sense of limiting the solution scope is constraints. However, unlike principles, these are not recommendations but rather these are limitations you have to follow. Constraints are set by stakeholders (their origin may be company standards, customer standards).There are several types of constraints:
- Technical – limit platform, reuse existing system/solution/component, follow a particular standard e.g. use Windows, .Net (alternatively use Linux, Java), use Web-services
- Organizational – follow a particular process, availability of the customer e.g. use RUP , MSF, company standard # 15 ..
- Business – time/money (deadline, budget). Another interesting example for this is “application freeze” – when an organization forbids change for a period – something some organizations did just before Y2K. [thanks to Andrew Johnston from www.agilearchitect.org for this one]
So how does it works – well, you bring in your architecture team along with some of the technical stakeholders – go through one of those “brainstorming” meetings and come up with a list – e.g.:
- Build on Open standards
- Reuse
- SOA
- Layered Architecture
- support scale-out
- …
Wait, what’s wrong with this picture – well, for one it is too simplistic view (it doesn’t say much) and even more importantly it not accurate (i.e. it can mean different things to different people) – on the next post on this subject I will show a better way to document and understand principles along with a few examples from real projects.
