The case for firmwareplatforms: Requirements

When you start to think about building a platform it is a good idea to first get your requirements straight, as these – obviously – will have a huge impact on the design of the platform. You might be tempted to take a shortcut here, as your team will probably consist of a group of experts that have a tight grip on the current generation of firmware. However: Depending on the level of requirements you already have jotted down somewhere it is very wise to do a review of this documentation and:

  • Check if it is up to date.
  • Check if the level of detail is adequate.
  • Check if it is complete
  • Check if there are requirements that can be dropped for a new product.

The first few points are obvious in what they mean – this is basically bookkeeping and, if the people responsible for requirements in your organization have been doing their job well it will not take much time. I do have a caveat here however: I’ve been at the center of platform development where the core requirement was “it should do the same thing the previous device”, where “the same thing” was about as much as we got. Basically: There were little to no technical requirements available, because the firmware in question had been built in a very organic way, i.e.: Things had been added as needed with little to no documentation. This leads me to my first important point:

What to do if no requirements exist?

I don’t mean literally “no requirements”, however, we – as developers – often find ourselves in situations, where there are no formal requirements. While we can often get away with few requirements, if the whole team knows the application domain well enough, this is not the case when we design a platform. The reason being, that during the design a lot of stuff should be taken into account, so that we don’t meneuver ourselfs into a tight spot. So, if no formal requirements exist, the only thing to actually get development off the ground is to make them up based on your experience. That is, we should try to answer the follwing questions:

  • What are the core functions of the product we want to build?
  • How do the core functions interact with each other?
  • What kind of usecases should the product solve?
  • What are the ancillary functions of the product?
  • What would a minimum viable product look like?

Now, I sure as hell wouldn’t want development to do an excercise in full fledged requirement engineering. However: Since our stakeholders (be it product management or somebody else) apparently are not able to formulate requirements themselves, we have to provide some guidance here, and these questions have helped me when working with stakeholders, when trying to figure out what the final product should look like. They also help to do early classification of features into “must” and “nice to have” features.

What to do if too many requirements exist?

A staple of most product managers is, that a new device will have to have the same functions as the old one and then some. This is all too human, as it is the PM’s job to provide value to the customer. However: This approach all but guarantees, that the first release of your plattform based software will take way too long, or worse, it might compromise the project. Years ago I got to witness this, when the company I worked for tried to replace a legacy product with a more modern, built-from-ground-up software that was supposed to carry the company through the next decade. However PMs – being PMs – insisted that the new software would have to satisfy all previous usecase no matter how little use they saw in actual daily operation of the customers. In the end it took north of five years to produce the software and it still did not see widespread use when I departed the company.

I’ve touched on this point before: We need to manage expectations here. We need to get product management aboard. From an engineering standpoint, the most sensible approach would be to build a product that satisfies the major usecases and get it into market. This will of course pose a couple of obstacles:

  • As mentioned, PM will not be too happy about this.
  • Even worse: If your new product has to compete in a call for bids it might end up “checking fewer boxes” than the competition’s product (incidently this is something that will scare your PMs as well).

These two points obiously have to be adressed. The easiest way to do so is to identify the features used by your most important customers (this should be an easy job for your PMs) and first implement these features. This will allow you to gently introduce the new product with existing customers, without having to fear competition (Note that the feasibility of this approach will obviously depend on the product you’re building), while still being able to gain valuable experience in how your product performs. At the same time provide PM with a roadmap for the delivery of additional features.

Which parts of the problem warrant a platform?

Now, we’ve established a group of requirements, that – hopefully – paint a picture of the envisioned product that is clear enough for a rough softwaredesign. We should especially know if the requirements fulfill the following pattern:

  • Horizontal scale: We need to be able to cover several products
  • Vertical scale: We need to be able to scale down functionality, i.e. to provide cheaper devices with reduced capabilities
  • Functional scale: We need to be able to swap functionality depending on the concrete product
  • Nonhomogenuous hardware landscape: We need to be able to run on different hardware designs (most notably: MCUs!)
  • Nonhomogenuous execution environment: We need to be able to run on different execution environments (i.e. operating systems).

You might have come to an earlier conclusion that you need a platform, however: If you look at your requirements and find that they don’t suffice to tick most of the above boxes the invest of platform might not warrant the gain. Note that all the above points are a continuum and ultimately there is no dogma concerning the points. I do urge you however to review your requirements and check if you really do need a platform and can justify the effort needed to build one.

Leave a Reply

Your email address will not be published. Required fields are marked *