Designing something from an idea, or as in many cases, from a problem that needs to be solved, is surely an exciting but not always an easy task. We architects have to make sure we design the best possible solution, meeting all the business requirements while adhering to global and organisational design best practices.
One challenge we commonly face is incompletely or ambiguously expressed requirements which turn the analysis process into solving a rubik’s cube problem while skydiving. Furthermore, as we architects are mostly the middleman between business teams and technology units, we have to carefully manage the perceptions and expectations while using the relevant language to our audience. And we have to do all of these within a deadline and a budget while ensuring enough level of security and compliance, performance and fault tolerance etc.
Luckily we are not alone in this journey. We have fellow “real” architects (people who design real buildings) which are facing similar questions on a different scale.
Farrow Partners is a Canadian architecture firm and they had coined a great and an elegant term for the design process they are following: Reliable Magic. The motto of the process is even more exquisite: Work with human nature, do not attempt to overcome it.
As the presentation suggests I also think technology architects can get some inspiration from this process and this blog post is basically my take on some of the practices of Reliable Magic.
Learn to appreciate uncertainty
This is actually the 6th practice on Farrow’s list but for me it deserves a higher attention. The most prominent value of an architect to the organisation is his/her ability to engineer uncertainty and known facts and define evolving abstractions out of them which gives business and technical stakeholders the common ground to build their work on. Architects use different techniques such as design thinking, layered modelling, transition architectures, discovery workshops and so on to turn an idea into a solution architecture.
Design with “not for” your constituents
There are certainly many different ways of designing a solution architecture. All would have their pros and cons. It is important to crisply articulate the solution and the rationale so that the audience truly understands what are we trying to achieve, and more importantly “believe” in the solution. Make sure you have the right material and artefacts which describes Why, What and How of the architecture in a simple, easily comprehensible way.
Every architecture consists of components where most of the times components are designed and developed by other stakeholders. The overall solution architecture can only be as good as the sum of its constituents.
Expect some resistance & Identify shared interests
In a pseudo-ideal workplace everyone would always be on the same page and agree on the same solution. That would indeed be a pseudo-ideal workplace as we all know from the science lessons at high school things only happen when particles collide. In case of conflicts of interests between the solution stakeholders an architect should be wise enough to identify the common interest and acceptable compromises to keep the wheel turning. At the end of the day, the show must go on.
Don’t jump to the end of the story & Don’t get too attached, too soon
It is very common in projects that people see things from their perspective and live happily with their misconceptions until they figure out they are on the wrong boat. One of the virtues of a good architect is his/her ability to easily mimic other people’s point of view, identify their misconceptions and bring them to back to reality. Above all, an architect should always preserve his questioning mode and do regular reality checks on his own conceptions.
Invite divergent thinking & Ask:what else can we see here
Having relevant experience on a particular solution area is a great advantage. However it can also blindfold you from finding a better and simpler way of doing things. Take every opportunity to reach out to other people and ask for their opinions and be open to suggestions and ideas no matter whom they come from (except that neigh-sayer person which God puts into each project to test your patience). A good architect does not create a solution architecture by himself but he/she facilitates the right conditions for the correct architecture to emerge.
Adopting ideas is a process, not an event
A good architect knows how to deliver complexity under layered architecture models and breakdown the end to end architecture into smaller, agile, easier-to-maintain architecture blocks.
I hope you will also find Reliable Magic as exciting as I did and don’t forget that Nothing is Higher than Architect.
Photo by George Becker from Pexels