Step 4: Architect

The make or break in development projects comes down to the fine details in infrastructure choices, team skills and overall costs to support new endeavours.

Proper architectural design in IoT can provide a preview of solutions before putting people to work. Highlighting risks early and uncovering opportunities to create sustainable development processes is a key success factor.

Architectural over-design can sink projects due to engineering aesthetics and so called ‘future proofing’, so where is the middle ground for projects on a budgets or a complex specification?.

THE RESULT: Architecture reviews provides a clear vision of the solution space for specialist engineers to ‘zoom-in’ at different topological layers of the ecosystem, allowing simulation and observation of functionality, form and fine requirements.

Who to involve

With a blueprint to get started, implementation plans can start. Naturally specialists in the ‘full-stack’ sense can focus on the various topological layers. This includes electronics, firmware, backend, frontend, mobile and test engineers.

Between the team they must bridge UI/UX, data management, network connectivity, business logic and security systems. Between each of these different areas, responsibilities of team members must be assigned.

With requirements, outcomes and milestones collected into the ‘Schedule of Work’ assignable to working groups to get started.

The sweet-spot between too much and too little preparation, all depends on how innovative the nature of the project is and the skillset of the team internally and the availability of external experts.

Tools

Such tools vary on the Project Manager’s team and proclivities. Our preferred options include:

• Physical networking Topology
• Network Topology
• Logical Topology
• Ecosystem map
• UI Design, and more importantly interactive UI Flows
• User journeys and user stories
• Concept specifications
• BOM
• API Specifications
• Protocol Specifications
• Testing framework

Why Architect?

Every project is different due to the requirements and resources available, but with a few detailed blueprints teams collaborate better, client communication is precise and a foundational structure can be laid for user support and continuous development, you’ve got a much better chance of succeeding with than without.

The approach is twofold – find the right level of detail for architecting a solution, and second breakdown requirements of different layers to select the technologies, connectivity strategies and interfaces. All of this needs to be clear enough to discuss within working groups.

This gives a clear road map for development tasks, outlining technical challenges and gives an understanding of the overall ecosystem of bespoke and third-party solutions that may be integrated.

This may come across as rocket science, but with our simple processes it allows manageable implementations. This gives a plan for the entire development and space for changes using an agile iterative process.

We need to know where every brick, every picture frame and every pipe goes – only then can proper resources be managed and costs calculated.