White Paper: Do you need a Network Assessment?

Networks play a critical role in every IT infrastructure and just like us humans they require a health check every so often if something goes wrong or when an event introduces new strains or changes the ways of working. For people, this strain could be training for a marathon or trying for a baby; for networks the equivalent could be adding or changing the application hosting or consumption landscape.

Conducting an assessment to investigate recent outages or known problems is a reactive scenario. The issues could be with the network as a whole, or with a particular network segment such as the data centre LAN or a remote access stack. To understand the root cause of the problem, the assessment will examine a full range of network aspects from the physical and logical design of the network, to the supporting contracts and SLA documents.

An example of a proactive scenario would be when a network assessment is conducted in order to prepare for an event, such as a new application launch or migration of a legacy application to a cloud based service. Such IT changes can be disastrous if there is an undetected network problem as research indicates that user adoption is low if first impressions are poor. Therefore, whatever the scenario, checking your network beforehand will give an indication of what the end user experience will be and whether any changes are required to optimise performance prior to the launch.

Companies move applications or launch new ones for several reasons, all of which can be undermined by poor network performance. Usually businesses are looking for lower cost bases, better performance and improved functionality. All of these elements are dependent on the experience of the end user, not just the application specification.

For example, if a network does not offer adequate bandwidth, end users will struggle to access the new application. If service policies are not up to scratch, or there is insufficient resilience and availability in the network, the result will be sub-optimal for the end user.

Without a network assessment, it is not possible to predict how a new or ported application will perform. If something does need to be changed or upgraded in the architecture of the network, it is much better to know this beforehand rather than try to fix it post-launch, both in terms of cost and operational continuity. It is all about readiness.

It might be that the check picks up something that has no bearing on the application in question, but would have other impacts. People often assume their configurations for things like IP telephony or video are correct, when in fact the configurations were not implemented properly in the first place. Equally, when there are problems people usually suspect bandwidth issues, but often the real causes are the policies for class or quality of service that have not been deployed or configured correctly.

Whether the network assessment is undertaken proactively or reactively, the procedure is much the same. It’s a five-step process: examine the network; perform a gap analysis comparing the network to best practice; look in depth at areas of concern and prioritise which issues are most pressing; produce a list of strategic recommendations; and finally create a roadmap of the exact steps needed to get there.

In some situations we use an automated discovery system for the first step, deploying tools that explore the network for us. This is particularly useful in finding out about end of lifecycle issues. It is common for some parts of a network to reach end of sale or end of support. When lifecycle issues arise, we can help customers by giving a clear picture of which products are out of support (or will be soon), with real market insight into solutions similar organisations have found to the same problems.

Automated exploration has its advantages but also its limitations, so wherever possible we prefer to rely on our own expertise. We interview people, review contracts, scrutinise network diagrams, check asset lists – an automated system simply cannot achieve the same understanding of the key issues and know which approaches have already been considered.

At The Network Collective we have developed a set of best practice principles around logical design, physical design and high availability design. We apply these principles to areas such as end of life and end of sale product specifications, creating a scorecard or gap analysis of the network.

The scorecard approach is really useful in ensuring we deliver a clear and helpful service. If an element of the network is non-aligned or only partially aligned to our best practice principles, it gets a red or amber traffic light. We back this up with an in-depth explanation of possible remedies, our recommendations and a roadmap for how improvements could be implemented.

Carrying out an assessment on your network is not an academic exercise – we do it in order to help you make changes that will bring real and tangible improvements. People sometimes ask how our service differs from the reports they receive from their regular service providers; many providers issue root cause analyses or outage reports. How does our service add value?

Independence is the most important element of The Network Collective’s service. We analyse the reports issued by service providers, identifying areas where we think the provider may need to be challenged. We also look closely at the recommendations made by service providers to determine if the suggested path is the best one, or if there are any other alternatives.

Where network problems are not related to service providers, we add value by lending additional support to in-house customer teams.

So many of our customers have now outsourced most of their technical support, they simply do not have the skills and capacity in-house to investigate issues around performance.

If there is a prolonged outage, relations between senior managers and in-house ICT departments can become very strained. Bringing in external, independent expertise to either confirm the assessment of in-house staff or suggest a new way forward is a highly effective way to resolve the situation.

The Network Collective’s experienced team includes technicians who have worked in operational and architectural roles, giving them a firm understanding of best practice. The team also features consultants with experience of maintaining wide area networks (WANs), assisting with the design of international networks and local area networks (LAN) infrastructure. We work with a broad range of service providers and customers both in network support and procurement, giving us insight into market trends.

Another service that The Network Collective can offer is planning for different scenarios. This is a ‘what if’ analysis which gives an indication of how your network would respond in a particular situation. For example, many organisations are planning to move from an on premise exchange platform to Office 365, in order to benefit from its email and SharePoint services. This represents a major change for many customers; understandably, they want to know what impacts there may be.

The Network Collective can prepare a readiness report for organisations in this position. We have an advanced understanding of the optimum parameters for Microsoft products such as Office. We can map your existing network to test its performance against these parameters, reviewing variables such as users per site, bandwidth per site, applications types and information about key times and dates.

This mapping exercise reveals what the impact of the intended change is likely to be. If the test shows that the user experience will be unsatisfactory, steps can be taken to improve the network before the change is implemented. The same procedure applies for any number of new applications or services: for example IPT (internet protocol telephony). We can help you to identify weaknesses in your system that would impact the quality of the new app or service.

Very often, The Network Collective is asked to help solve a problem (provide a reactive service) that could have been prevented if a proactive assessment had been performed prior to deployment. The cloud was not in existence when traditional network systems were developed, so they often cannot cope with large-scale migration of applications and services to cloud systems.

Unfortunately, this can cause significant problems for businesses as they learn the hard way that their network is not capable of supporting a new application. We have known large businesses come to a standstill – from office environments to logistics operations – because their network went down.

Companies often do not appreciate that all of their applications run across a single network, so they simply cannot function without the network any more.

Just as it is better to find out about a heart problem in the doctor’s surgery than halfway up Mount Everest, it is better to have a network assessment before malfunctioning forces you to do so.

Real-life case study 1: Moving to the cloud

Problem: A global construction company was planning to move from a local exchange infrastructure to Office 365 cloud services including SharePoint. Would their international network cope?

Solution: The Network Collective carried out a readiness assessment. We assessed access circuits between the different offices in the Middle East, Australia and Europe and connectivity levels. Some round trip times were on the outer reaches of workable parameters for Office 365. We suggested overcoming this by using a separate tenant in a closer region and considering acceleration products and configuration changes.

Outcome: Our recommendations went forward to the board together with pricing options to show what they would cost. The proposals have been welcomed and are under review.

Real-life case study 2: End-of-support issues

Problem: A large global law firm had global LAN infrastructures, parts of which were approaching the end of support. The investment board asked us to recommend what should replace them.

Solution: The problem had two parts: the technical solution and funding. Rather than replacing like with like, our technical recommendation was to virtualise more of the network so less infrastructure was required. Using our commercial expertise, we also helped develop a funding proposal for the board, shaping it into a simplified request and demonstrating how it would save money.

Outcome: The investment board approved our recommendations. Our independent status gave extra credibility to the proposals.

Other than matters relating to The Network Collective, this research is based on current public information that we consider reliable. Opinions expressed may change without notice and may differ from views set out in other documents created by The Network Collective. The above information is provided for informational purposes only and without any obligation, whether contractual or otherwise. No warranty or representation is made as to the correctness, completeness and accuracy of the information given or the assessments made.

This research does not constitute a personal recommendation or take into account the particular investment objectives, financial situations, or needs of individual clients. Clients should consider whether any advice or recommendation in this research is suitable for their particular circumstances and, if appropriate, seek professional advice.

No part of this material may be (i) copied, photocopied or duplicated in any form by any means or (ii) redistributed without the prior written consent of The Network Collective Limited © 2018