I like IKEA. I like saying the name: i-KEY-yah. I like saying the name of it’s products–BROGRUND! GRÖNKULLA! FLÄRDFULL! But what I like best is that I can assemble the products myself. Doesn’t matter whether it’s a sectional sofa or a bathroom do-dad to hang towels on–I just follow the instructions, and SMÖRBOLL! it’s built and ready to use.

How is it that I can build this stuff myself? I am certainly not an accomplished carpenter (ask my wife!); and I have no clue what a mitered joint is. Yet, a few minutes with the IKEA instructions and an hex key, and there it is in all its glory–a Knutstorp, assembled and ready to recline on. The secret is, the geniuses at IKEA have done the heavy lifting before I ever entered the showroom. They have figured out the best way to do the technically-challenging work; and have done this ahead of time so that, when I enter the picture, I just need to bolt the pieces together*.

What if we were to apply this same technique to software development–figuring out how to do the complex stuff up front so that putting it all together becomes almost a rinse-and-repeat exercise?

In fact, we do; it’s called architectural prototyping. Just like IKEA, the idea behind architectural prototyping is to reduce technical risk by building and testing the technically-challenging pieces of the architecture early in the project in order to prove whether developing the overall system is viable (or even possible). If it is, the actual building process becomes a repeatable process that relies on a proven, stable architecture; if it’s not, we have an opportunity try another approach (or stop the project altogether) before significant time and funding have been consumed.

The objective of architectural prototyping is to create a proof-of-concept (POC) that:

• provides a solid base upon which to build the system/components;
• proves the technical risks have been addressed before gobs of time and effort are invested;
• provides an opportunity to test the approaches and estimates that will be used when building and testing the system;
• communicates to stakeholders how their vision will be realized (or not) while demonstrating value early since the the pieces of the architecture that have been built are not throw-away; the POC results in usable components.

Of course, creating an architectural POC comes with a price; and you will need to make a judgment call as to whether the benefit justifies the cost. Two factors to consider are:

• How great is the risk–From a technical perspective, are you venturing into the unknown? What’s the probability you’ll get the architecture right without prototyping (believe it or not, winging it sometimes works)? What will be the impact if you get it wrong? What’s the best way to address the risk–maybe it’s better to buy rather than build?
• How well do you and your business team understand what you are trying to build? Beyond reducing technical risk, a usable architectural POC may help your business team refine requirements because it provides an opportunity for them to see working pieces of the architecture, and re-imagine requirements to help ensure what’s being built is what they really need.

So, there it is: The IKEA secret revealed. Something to consider as you bolt together that Gotterdammerung (okay, that’s not even Swedish; borrowed it from Wagner because it’s also fun to say).

*To be fair, there’s a middle layer, between me and the IKEA brainiacs, that designs, builds and pre-assembles many of the pieces; point is, the work that goes on in this layer is less complex because someone has figured out the best way to design, build and pre-assemble ahead of time.

Find more tips like this one at Professional Services Plus