Two primary drivers are forcing ACME Corporation to move its data center. First, the current data center is colocated with their manufacturing and testing facility, and the constant explosions and accidents have compromised stability. Second, due to the successful breeding habits of roadrunners and bunnies, ACME has experienced tremendous growth in recent years. They projected they will outgrow their current data center in the next three years.
Where do you start?
This series of blog posts will break down this daunting project into smaller tasks. We’ll focus on items that need to be considered in each task to turn this mission from impossible to possible.
Gathering Requirements
Like many networks, ACME’s network exists for one reason: to support the business. The network has been operating admirably for years, and it would be easy to build the new data center network as a mirror image of the current one. However, this project provides the perfect opportunity to ensure all business and application requirements are met now and into the foreseeable future. The only way to gauge this opportunity is to gather requirements.
Business and Application Requirements
As expected, ACME hosts a variety of administrative, financial and manufacturing applications in its data center. Discovery meetings with the key stakeholders of each application should reveal when each application is most commonly used, application dependencies, expected uptimes, acceptable outage windows and the effects of an outage to the business.
These meetings should take the form of a conversation where active listening should be employed to discover any pain points that might exist. These pain points should serve as beacons to requirements that need to be met or ways that the current system can be improved upon.
Translating application requirements to network requirements is always tricky. One reason for this is that applications sit at the top of the IT stack while networks sit a few layers below, at the bottom. This gap means the groups speak different languages. Often it feels like a network architect needs to read minds to complete the translation.
Legal Requirements
Many industries are subject to legal compliance, which can have an impact on network design. Because ACME sells direct to its customers by accepting credit cards for payment, it must comply with the Payment Card Industry (PCI) standard.
To be sure that PCI is being interpreted correctly, ACME’s privacy officer, Daffy Duck, should be consulted.
Technical Requirements
Within the IT stack, servers, storage and middleware are layered between the applications and the network. The groups that manage these layers are also customers of the network and, as such, have their own requirements to be successful in supporting the applications and business. Cooperation with these groups will determine connectivity types, connectivity speeds, reliability and redundancy requirements.
ACME’s network monitoring systems provide detailed reports of bandwidth and traffic patterns. This information will help ensure that the network is sized appropriately for the projected growth.
Security Requirements
It goes without saying that security should be included from the outset. An insecure network puts the business, and many livelihoods, at risk. Striking a balance between usability and security is a difficult task, as new attacks are invented every day. There are always tradeoffs when balancing usability and security.
ACME’s Chief Information Security Officer (CISO), Yosemite Sam, is a “shoot first, ask questions later” type of person. He would like to see systems locked down as tight as they can be no matter what. It’s essential to have a conversation with him to soften this stance as it’s not very user friendly. What level of risk is Mr. Sam willing to accept on behalf of ACME Corporation to achieve balance?
Documentation
All requirements should be gathered in a document and categorized by type. Classifying each one as either mandatory or optional is also beneficial. Once created, this document needs to be approved and signed by all stakeholders. Signatures should in no way imply that requirements gathering is complete. Instead, requirements gathering should be an iterative process. You will undoubtedly have more questions that clarify some requirements, remove requirements or expose new ones. Being iterative also allows stakeholders to ask questions and provide more information, all with the intent of fine-tuning the living requirements document.
Constraints can be just as crucial as requirements and can be found in any of the above categories. Requirements typically consist of functionality that a system must-have. Constraints typically include limitations imposed on a system. As every project is usually tied to a budget, there will most certainly be a financial constraint.
It's Rewarding Work but Hard
Requirements gathering is hard work. Change can be scary and inaccurate requirements can be the result. Active listening during open conversations builds trust that helps to alleviate the fear of change.
It’s exciting to build a new network. It’s even more exciting when that network contributes to the success of the business. Requirements gathering isn’t glamorous by any means, but it is an important task to perform to the best of your abilities no matter the size of the network.
Read My Other Blogs in This Series
