Defining architecture

Other than discussing hardware product-design, I found myself proposing to prospective clients an additional (or alternative) way for working together. This turned out to be quite popular.

At the time of contact, clients are usually looking for someone to realise their ideas, seek authoritative advice and guidance, or take their prototypes to the 'next level'. It's at that moment in the project where an 'architecture definition' is a crucial document to have, and I offer to help them create it.

I first ask clients to tell me what they want to achieve. I explicitly ask them to leave out how they think it could be achieved since that is -- potentially and hopefully -- my job. That's what the architecture definition document starts out with. It sets the tone without burdening the imagination with technicalities, freeing us to be creative with solutions. It's the framing shot.

Source: http://www.digititles.com/movies/django-unchained-2012/photos/tarantino-framing-a-shot

We then work on an architectural diagram that encapsulates the interaction of all components of the system at a high-level. We also define all entities, along with their capabilities, purpose, and needs. Confusingly, we want to be specific and generic at the same time. For example, we might not know whether we'll use ZigBee or Bluetooth Low Energy (BTLE) at this point, so we might call that communication channel 'short range channel' or 'low power channel' -- this allows us to be flexible later on where we actually spec that comms channel. We may not know if the device is battery- or USB-powered, so we'll just say 'power source'.

This part of the document is important since here we give the reader -- and ourselves -- an overview of the system to come back to as a reference. This bit occasionally changes as the document fleshes out, but not by too much -- this is the foundation of the project, and changes here have a cascading impact on the rest of the document.

The next phase is dynamic and interactive. Here we spell out the possible ways for achieving the goals and functionality of the project. We might consider, for example, GSM as a communication channel, but indicate that this has power and connectivity implications. We may consider BTLE but note that bandwidth is very limited. We'll also discuss user-interface elements, such as the merits of a mechanical push-button versus a capacitive touch solution. We'll point out the merits of using a pre-packaged module compared to a complete OEM solution compared to the costs of a custom PCB. And what about certification?

This section changes a lot in the course of writing the document: what used to be an option may be stricken out because of a limitation, or cost. Or, a few positive considerations may tip over a solution to be the one that's the favourite. It's typical to have quite a few ping-pong rounds of edits between us and the client for this section.

In the process, many questions that must be -- at the least -- addressed invariably surface. These questions can be pretty tough for the client to answer. How do you choose, for example, between a non-replaceable rechargeable Li-Ion battery in an ultrasonically sealed case versus two replaceable AA batteries with their associated complexities of usability and an opening in the casework. We don't have to have the answers, but at least the questions and considerations are there. It can be overwhelming, but it's definitely good to have given these considerations a thought before the product has already been mostly designed!

At the the end we get a thought-out document that teased out a lot of detail. The client is now armed with a document that can be shown to an investor or design consultancy for a quotation. It empowers the client in future interactions about their product and allows the other party to quickly understand the project's goals and requirements.

Most importantly, we found that the investment of time early on to create such a document saves much more time later on the project!

Now, why would you hire Boldport for this job?

We bring a wealth of knowledge and experience to the process, and are able to advise and contribute way beyond the technical details. Other than experience in many technologies -- FPGAs, microcontrollers, BTLE, web, software development, manufacturing -- we're competent at advising on the security and privacy implications of your product. In authoring the architecture definition we also, of course, factor in cost, manufacturability, and usability considerations.

We work as if we're not the ones who are going to design the system -- and we may well not be. What you end up getting is different compared to what you'll get in a 'project proposal' from other consultancies, where they are naturally biased towards the solutions that they are already most familiar with. Those proposed technologies may not be the best for your product! We'll give you a document that you can take to these consultancies and have them justify why their solution may be better, instead of just taking their recommendations at face value.

Finally, we strive to give you value for your money. It's a great way to get to know us and how we work towards the success of your product. Writing a document like I described above typically takes one to three days. You'll get the document, of course, but also the benefit of knowing if we're the right choice for continuing to design your product. Also, be certain that if we feel that we do not have the expertise for completing your project in the best way possible, we'll tell you.

Finally, here's what Alex Nicholson from Sustainable Venture Development Partners said about a recent architecture definition project we've completed together

We engaged Boldport to support us with product development and to help us develop a technical specification. I was struck most by the creativity that went into the production of the specification, with nothing taken for granted. This, combined with punctuality in its delivery, made it a rewarding experience to work with Boldport. I hope to continue working with them in the future.

There are more testimonials here.

Please do get in touch if you think that an 'architecture definition document' could be useful to you.