What Does A Solution Design For Internet Of Things Look Like?
In my last post, WLAN configuration for Internet of Things capacity, I provided a reference for the products, features, and components that can help optimize the provisioning and configuration for your design which become the functional specification. (Note: Although this solution design is based around IoT it can also be applied to almost any other type deployment).
So the hard work is done. You have defined your requirements, performed a desktop survey or site survey, and taken into consideration the capacity required in the WLAN and built the configuration. Now it’s time to bring this all together into a solution-design document.
What is a solution design anyway?
A solution-design document pulls together all the elements we have discussed into one document. The goal is to provide an overview of how the various devices and components of the system fit together based, of course, on the original requirements set out.
From my personal experience I have found that breaking down the solution design into manageable sections helps identify all the required steps needed to fulfill the design. My belief is that the solution-design document might change, so it can really be considered a living, breathing document.
Where do you start?
It’s always best to give readers context around what your document is about as well as what its purpose is. These are normally the questions I look to answer:
- What is the purpose of the document?
- What does the document include?
- Who should read it?
- Who has had input to the document?
- What are the next steps after this document?
Once you have opened the document and given your audience some context around what the purpose of the content is, let them know what’s included.
It is important, from my experience, to provide background into what is already in place or what the reasons are for this project to take place. Although this might seem obvious, it just allows you to highlight the reasons, and importance of, why you decided to take this project on. These are normally the questions I look to answer:
- What is the historical context of this project?
- What is used at the moment (hardware/ software etc.)?
- Where is it used?
- What does it do?
- Where is the pressure coming from internally?
Now our reader has a good idea of the context of the project and the background to back this all up.
So what comes next?
Here is where we document the business requirements. What are the reasons the business is embarking on this project and why? What does it accomplish? If you have followed the approach (see previous blogs in this series) so far, this will be much easier to complete. These are normally the questions I look to answer:
- What does the business want to achieve?
- What does the business gain?
- More efficient
- Less cost
- Lower OpEx
- Less support
- What functions need to be performed and by whom, how important are these
The next section looks to build upon the businesses requirements and asks some questions about what the current problems are and how will the new solution solve these and how quickly.
It is important that the new solution is actually providing some benefit to you, otherwise why are you doing it? Problem identification would normally consist of asking such questions as, “What problems has the customer identified that need to be solved so functions can be carried out or carried out more efficiently?”
The required gains would then be, “If we can take away the problem what would it enable individual to do? how much? how quick? Then, what is preventing them from solving the problem now? As you can see we have given some real thought into what the problems really are and what tangible gains we are likely to see should the new WLAN be installed.
It’s time now to explore the requirements in the actual solution. This is where, at a high level, which functional, technical, security, quality requirements will be required.
Typically these can be characterized as:
- Manageability of the solution?
- Performance and Connectivity of the solution?
- Wireless services required for different types of users?
- Scalability and flexibility requirement?
- Is redundancy needed? To what level?
- The capacity needed to support IoT, BYOD etc?
- What are the requirements around security – encryption, network protection, network security, client security?
- What availability is needed?
At this point we have set out what the goals of the document are and defined the requirements from both a technical and business perspective. We have also detailed our proposed gains.
Now it is time to identify what element of the solution we are directly responsible for: How does this connect to wider network?
In my experience the goal is to determine boundaries for the project and the interfaces to external systems. In most cases, the best way to illustrate this is by creating a diagram that shows the all internal and external systems that interface with each other, identifying which are in the scope and which are outside.
An example of this is a wireless infrastructure could be in scope of the project, but RADIUS might not. However the WLAN needs to interface with the RADIUS server to provide authentication. Therefore, there is a relationship between the sub-systems (WLAN and the RADIUS system) but there are clear boundaries of what is in scope and out of scope.
Now we go into some of the details around the design at a high or low level, depending on the audience of your document. The goals here are to provide some context into why the WLAN has been designed in the way it has. I like to use the terminology here “design philosophy.”
This means, ask yourself what was the thinking, ideas, logic, and viewpoint on the design? Also, ask how we have used this to satisfy requirements? For example, we might have architected the system to be state of the art and to support fully VoIP, BYOD and IoT, or we might have had to sacrifice some elements due to cost.
These are normally the questions I look to answer:
- What elements of the Aerohive portfolio are used to create the design?
- What is the purpose and function of each element?
- How does each element interface to wider solution? (e.g. L1-3)
- What dependencies does each element have (e.g. PoE, Ethernet, DHCP)
Next, once we have provided the required detail to our design approach and philosophy, it is important to show how the new WLAN will interact with other systems in your network. The best way to provide this level of detail is via a network schematic. This will show how the WLAN integrates into the LAN and WAN. This is best illustrated as a diagram or set of diagrams detailing network flows and interconnects.
Within the wireless services and dependencies section we look to provide a list of wireless services to be deployed. Based on experience, this is normally done for each user type. Here is where we will detail the wireless connectivity that specific devices will have, what wireless security protocols will be used (e.g. WPA2, RADIUS), what role based access and QoS will be used, what VLAN the user device will be placed in, and finally what network services will be provided.
Then, once this is detailed, it’s a good idea to provide the dependencies required for each service. This will be a list of elements such as switches required and services (e.g. PoE and VLAN tagging), logging needed, reporting required, other backend systems or facilities (e.g. RADIUS), dependency on hardware (e.g. APs), and connectivity to management or control systems. This section might require you to complete the same for the wired network as well, if in the scope of your project.
Another important section to include is the survey results and capacity planning results.
This is a piece of work we have already conducted, and provides some valuable information as to why the WLAN has x number of APs in x location. But why does this matter? Only through the use of good requirements gathering, network design, configuration, and optimization can wireless networks meet the demands of dense user and device populations such as IoT. Therefore, it is key to highlight this in the solution design, giving readers context around why, for example, you choose to install four APs in a dense location, when from a coverage perspective one would have be suffice.
We are almost there, I promise!
Other important elements to consider are how our hardware (e.g. APs) and software (network management) elements are connected. This needs to be thought of in a multitude of ways, for example for the APs we would need to consider and document:
- The Physical connection of the AP to switch?
- The Co-operative control protocol connection and required open ports?
- What is the Management VLAN assignment?
From a software perspective, in this example of Aerohive’s HiveManager NG, we would need to consider and document:
- How network management will be provided (e.g. Cloud or On-Premise)?
- What is the location of the HiveManager?
- What ports are required open on the firewall to view the web interface?
- What access is required and by whom?
Finally, we are here at the end! We have now been through all elements of the design and have documented how the WLAN should be designed. All that is left if to include a list of all hardware and software that is being proposed. This is usually referred to as a bill of materials.
If we bring all this discussed content together in the format of a list, it would look something like the following:
- Introduction to the project
- Background of the project
- Business requirements
- Problem identification
- Required gains
- Solution requirements
- Scope of the solution
- High Level or low level design
- Design Philosophy
- Network Schematic
- Wireless services and dependencies
- Hardware connectivity
- Software connectivity
- Bill of materials
- Capacity planning and survey results
Next in the series we will look into WLAN deployment. This is arguably the easiest of all the stages, but for some reason the one many professionals put the most energy into! Stay tuned…..
All posts in this series: