For those parents out there they will be familiar with the cry from the backseat of the car on a big journey, “Are we there yet?” Much like children Project managers have a need to know how far we have to go and more importantly are we there yet i.e. can I mark your task as complete.
Setting out on a journey from Melbourne to Sydney it is pretty easy to know how long the journey will take and more importantly how you are progressing and a fair idea of your estimated time of arrival.
Let’s say you were one of the early explorers and didn’t have a specific destination in mind nor an idea of the terrain between you and where you were heading. Pretty hard to know how long your journey will take or how you are progressing.
Solution Architecture can sometimes be like the early explorer scenario. It usually comes down to how many unknowns there are in the problem space you are working in. Stop and think about that for a tick the length of your journey is proportional to the number of unknowns. So if I can identify all the unknowns there are I will know how big the problem is and a rough idea how long it will take to solve.
This introduces one of my favourite concepts which are known unknowns. Now the first step isn’t to turn the unknowns into knowns but just to identify there is something you don’t know the answer to. A good way to track this is to group these unknowns. You can group them into problem spaces or along functional lines depending on the type of solution you are developing.
This grouping of the solution provides a good way to communicate progress of the design activity. This can be expressed as two components:
- Unknowns that I have discovered (Known Unknowns)
- A gauge of how many unknowns you think you have discovered i.e. a percentage or traffic lights (red, amber, green)
Just be aware that the role of the Solution Architect isn’t to identify every unknown and it isn’t to turn every unknown into a known.
Known Unknows well these are the points where you do your best work. If you deem the unknown to be architecturally significant you need to get down and turn the unknown into a known and find a solution. If the unknown isn’t architecturally significant at this level of design then you just capture it but don’t need to solve it.
Unknown Unknowns well you don’t know. Looking at your solution there is a cloud of unknowns surrounding it, it is just there. You need to assess all the areas of your solution and look for weak spots, areas that the unknowns can penetrate and invalidate your solution. At these points you can do one of two things
- You either do some more investigating and identify the unknown
- Or you put a risk or assumption that underpins your design decision. Kind of like an unknown force-field.
So how does that sound as a way of venturing where no Solution Architect has ever ventured before? Pretty simple really isn’t it. Identify the unknowns that will impact you solution. Turn the important unknowns into knowns and find solutions for them. How easy could it be? Now try and get a Project Manager to put those tasks into a project schedule.