Darwin Innovation

Darwin Innovation have years of experience in the architecture and design of computer systems and software - especially where these systems include networked, embedded, consumer electronic devices.

Past projects have included architecting complex systems including:

• digital set-top boxes and PVRs,
• in home media and control servers,
• mobile phones, including multimedia and TV on mobile,
• low power radio systems, including IEEE802.15.4 and ZigBee,
• advanced photo frame and PDA-like devices
• embedded Linux devices (for routing, relaying etc).

The role of the architect is seen as a key role required from the inception of a project. It requires an in-depth understanding of the project and the ability to capture and easily communicate the key features of the system whilst maintaining an eye on the details. The architect will drive the technical design of the system, usually working alongside the project manager. This can be done using a number of different development processes, including RUP and Agile. In general, the architect will be involved in the following stages:

Requirement capture

Working with the project sponsor, commercial and technical teams to capture all potential requirements for the system.

Requirement analysis

By carefully working through the requirements captured a product is defined that is commercially viable whilst being technically possible. Where options are possible these are explicitly explored in order to allow the project sponsor to make a rational, evidence based decision.

Requirement agreement

Although I have listed this as a separate stage, the majority of this is actually done during the previous requirement stages. However, within the project there should be regular occasions where the requirements are discussed and the project sponsor, commercial and technical teams are all in agreement with them. In most modern, iterative development processes (such as RUP or Agile) this will be done multiple times in each project.

Prototype and investigation definition

An early product of the requirements stage is a list of the 'unknowns' of the project, these may take the form of technical complexities, platform definitions, costs of different options, and user preferences. As all of these typically represent the top risks of a project it is imperitive that they are studied as soon as possible. An architect, together with the project team, will define how each unknown will be studied and pinned-down. This may take the form of building prototypes; identifying, obtaining and analysing relevant currently available information; defining and participating in market research; top level cost analysis; and, participating in early discussions with potential suppliers and partners.

Top-level system architecture

I have found it invaluable for projects to generate a high-quality 'System Architecture' document. This serves multiple purposes, primarily it is the top-level analysis and decomposition of the network, describing the devices, networks, hardware and software that shall be employed. This is not a long, complex document - ideally around 20 pages long - with a heavy emphasis on the different graphical ways that the system can be described. In this form the document becomes a quick-start guide and reference for the technical staff of the project, providing a common understanding and terminology for the project. However, and often more importantly, it becomes an introduction to the technical side of the project for all levels of management and often provides financiers with reassurance that the technical side of the project is well thought-through. As a project progresses the system architecture should be updated to reflect any major changes in the system.

System design

The meat of any project is of course the design and implementation. I have found that the role of an 'architect' during this phase is heavily dependent on the type of project, the experience, size and locations of the members of the team, and even the development process that is used. In some small projects, there may be no need for an architect to perform the design. However, they can be invaluable in performing reviews of the design - as the top level of the architect can spot potential problems (before they are put into code), and provide a mechanism to maintain style across a project.