Requirements!
Following on from my earlier post about requirements, still remains as catchy as ever, I thought I’d try and cover off a quick example of what makes them and principles so important.
When working on any project, before commencing any kind of design work you should have a set of measurable requirements and principles to follow. I appreciate that these are not available in all cases. However, they do take away the guess work during design phases and help to keep everyone focused on deliverable.
As an example, working on a project with ill defined principles – you know the type, one word and that’s a meaningless buzz word or sales term with no expansion or explanation, things like scalable, flexible, agnostic or automated.
These words in isolation are not principles, they are marketing terms. setting a principle as automated doesn’t offer any guidance in real terms. To be of value a principle should also provide a statement, rationale and implication. For example automation could be expanded as follows;
Principle: Automated Technology
Statement: Technology designed for automation at the Network, Storage and Compute layers
Rationale: Automation augments the creation of a repeatable process and ensures that there is consistency. Automation ensures that technical resources are providing the most value, through the expedient use of time.
Implication: Infrastructure components (network, storage and compute) must support automation tools. Automation of tasks requires resources that understand the technologies and can produce automation scripts and code. The development of code requires the creation of code repositories for governance, version control and parallel working (code branching). Wherever possible operational acceptance testing is to be automated and continuous. Capturing when a device falls out of an operational acceptable standard.
When provided in such a format, principles provide meaning guidance to inform design work.
Similarly, requirements need to be well defined and ideally measurable in order to provide the maximum value to inform design work.
For example, Backup could be a requirement of a solution being designed. However, in isolation this tells an architect nothing about what needs to be provided. Backup can be taken in multiple ways, covering different components, can be copied to cloud services or USB drives. All of which you could argue will meet the requirement ‘backup’.
A better requirement would inform the architect what the service needs to provide, this still allows room for identifying opportunities for improvement, but does set a base expectation of what needs to be provided;
Backup
Recovery of individual files
Recovery of individual Databases
Recovery of application users (AD)
Recovery of entire machines
Recovery of entire services
Retention for X number of Days/Weeks/Years
Archive for X number of Days/Weeks/Years
Rapid recovery within 30 days
Compliant with documented internal security policies
Reporting on success/failures and partials
Key functionality provided to customers via a portal
Data at Rest Encryption
Data in Transit Encryption
It’s very easy to see that with principles set as single word marketing terms and requirements ill defined, an architect can produce a design that places the business at risk of not meeting goals or requires continuous input from sponsors and decision makers alike to ensure alignment. Neither of which is a productive use of time.
Simon