University of Toronto Logo

Information + Technology Services

Small normal big

Assume.

Thinking Architecturally Blog by Frank BoshoffAssumptions, whether inadvertent or purposeful, are the bane of any project, no matter the resulting system or structure.  Imagine not trusting the structural integrity of your office environment, or the ergonomic design of your chair, or the fact that your automatic vehicle won’t roll forward when in park, or the security of your e-mail (actually, the latter two are fallacies if you happen to own one of several Fiat-Chrysler models, and your e-mail is not secure, period).  Part of what IT Architects do is to identify assumptions that need to be validated to reduce the acceptable risk of critical and/or costly IT projects. I’ll use a fictional scenario to demonstrate how we all make assumptions  in our daily lives – we wouldn’t be able to progress if we don’t.  

If, as a senior administrator in a University department, you need to provide students with their Cumulative GPA’s via a Web application, you gather the requirements for the CGPA calculation and find a developer to start writing code.  The process is fairly obvious, similar to baking a cake, which is not something everyone does everyday, so following a recipe is a good idea (tip: your friendly IT Architect has recipes for IT projects).  Whether writing code or following a cake recipe, a number of assumptions have been made:  

The recipe book author usually assumes that: 

  1. The baking utensils are readily available, 
  2. There is an oven available (in a kitchen…preferably inside a house), 
  3. The oven can maintain the required temperature for the required baking period, i.e. no power cuts, 
  4. The ingredients are readily at hand, 
  5. The container labeled “Sugar” doesn’t contain “Salt”, 
  6. The baker has the time to dedicate to the project (including clean-up), 
  7. The baker remembers to turn the oven off at the required time. 

The CGPA stakeholder may assume that: 

  1. The requirements are complete, clear and unambiguous, 
  2. The programmer knows how to calculate CGPA, 
  3. The students will find the CGPA feature easy to use, 
  4. The calculation will be available to as many students as needed, whenever needed, 
  5. Each student will be able to view only their own CGPA, and not those of their friends, 
  6. If there are any system failures, a backup can easily and quickly be restored, 
  7. The CGPA feature is impervious to attacks by mischievous  script kiddies (https://en.wikipedia.org/wiki/Script_kiddie). 

In the baking scenario, the assumptions are quite reasonable, but only because a small army of architects, designers and engineers, working within established standards and regulations, applied their craft beforehand to the final solution (i.e., the cake). The oven has to conform to numerous standards – known to and applied by the designers and engineers – before being allowed on the market. The house (and the kitchen) has to conform to building codes, of which the architect is knowledgeable and, conforming to a code of ethics, diligently applies to the benefit of the client. And the whole edifice has to have a building permit issued by a governing body, with several quality assurance checkpoints during construction, before the cake can be baked. Our cultural and social norms form a context in which cakes can be safely baked.  

In the IT scenario, the CGPA feature becomes part of an existing solution (e.g. ACORN – the oven, installed in the new Data Centre – the kitchen, located in McLennan Labs – the house), all designed to a set of established standards, providing a secure environment thanks to the diligence of a small army of skilled resources.  IT principles, standards and guidelines form a context in which IT solutions can be designed and built. Assumptions about the completeness of the IT context often impact a project negatively. The architects, designers and programmers, along with project managers, help identify and address assumptions to avoid any nasty surprises later in the project (management takes a dim view of surprises).   

While we generally accept the risks incurred by the assumptions required to bake a cake, we shouldn’t accept the risks of the IT assumptions – all of them need to be assessed for potential impact. The nasty ones need to be validated and potential mitigation strategies applied.  It takes a bit of effort, but identifying and assessing assumptions helps everyone on the project sleep better!