“Product Architecture” is one of the most misunderstood concepts in product development. Let me first define what I mean by the term:
Product Architecture is a definition of the functional and structural building blocks of a product (software, hardware or service) and a description of the interactions among them.
In an earlier blog entry (dated June 25, 2008), I identified the four main components of a good architecture:
i) Functional architecture: what does the product and its sub-components do?
ii) Design architecture: what sub-components does the product have?
iii) A mapping of functions to sub-components: what is the function of each sub-assembly and component?
iv) Interfaces: Identification of each interface between the sub-components.
Note that I replaced the word “sub-assemblies” with “sub-components” to avoid hardware implications. The same is true whether your product is hardware, software, service or, in most case, a combination.
Anyway, let’s get to the main topic of this blog entry: saving time and effort in R&D through good product architecture definition. Let me illustrate this through a case study. I was the main system-level product architect on a product aimed for the health science market. It consisted of hardware, software (both user-level and instrument controls), consumables, and service. Architecture development was a foreign concept at this company, which required both education & training in addition to the actual development of a sound product architecture.
The end result was a product architecture that captured the full complexity of the product portfolio, took into consideration future potential upgrades and improvements, allowed practical decomposition of tasks and simplified integration of the sub-components. And, it stood the test of time after more than eight years, by being a fundamental product description tool.
Putting the effort into a product architecture resulted in significant savings in the first and follow-up projects on the product platform:
1) Design effort for some sub-components were outsourced to subject-matter-expert companies. This resulted in higher-quality results without going through in-house learning for non-core competence areas,
2) Testing was done at lower levels and system-level testing was significantly reduced. For example, other instruments with similar complexity required 2-3 months of system-level testing while the product described here required 3 days (yes, days!) of system-level testing.
3) Last-minute changes could be implemented without triggered large-scale verification. All verification was limited to the changed components and their interfaces.
4) Design teams were smaller than other similar projects in the company. Each team focused on their sub-component and its interface functionality.
5) Concurrent development was effortless through interface emulators. The teams did not need to depend on the “other side” of the interface during development.
6) Follow-up projects were performed by much smaller teams compared to similar complexity upgrade projects in the same company. In some cases, upgrades and their testing was completed in less than half the time other projects required.
While it is almost impossible to accurately estimate the savings in the life of the product portfolio, here are a few numbers:
– The first project cost was approximately $4-million less than comparable projects in the same company.
– The follow up project cost was only 40% of what was originally estimated before the whole program started.
– The first project team, which developed the architecture, size was about 20% less than that of comparable projects.
– Follow-up project team size was significantly smaller.
I hope you find this posting helpful. I welcome your feedback and comments. You may reach me at ferhan.bulca@intrascope.ca.
Ferhan Bulca, Ph.D. 