Apstra’s Intent-Based Networking
If you’re in this industry long enough, you will eventually find yourself working on a deployment in which your production environment, your customer base, or your end user community is not ready for the technology you are about to unleash on them.
This lack of preparedness can be attributable to a variety of factors, including two common problem areas we’ll focus on here:
Most companies have a governance model that mandates a requirements gathering phase, and most projects tend to follow this model. However, too many project managers simply go through the motions so they can “tick” the box and say it’s done.
For expediency’s sake, it can be tempting to work backward — to “create” the project requirements by walking through a features list on a particular technical solution. Don’t do that.
I like to call this “artificial selection,” because it too often results from you being strung along by your hardware or software vendor (or reseller) to pick a solution that has 100% chance of benefiting them — and a very good chance of being a nightmare for you and your operations staff to execute.
Take the time to define usable requirements. Make sure you have an understanding of how these requirements align with your business’ goals and objectives. Ensure that requirements are clearly articulated, discretely prioritized, and consumable.
And of course, make sure your requirements are “complete” — that you can map all of them directly to one of the following:
This is a big one and it can get sticky to navigate. Before you can really understand the business impact of deploying a technology, you have to think about the consumer of that technology.
From the outset, it’s critical to identify the consumer’s need for the solution. Gain some understanding of workloads. Identify with the pains and understand the deficiencies of the existing processes you are hoping to optimize.
You should do all of this before you start talking about technology. How can you apply a solution when you don’t have an accurate understanding of the problem?
If you are even remotely serious about deploying a new technology, I suspect you have a high-level understanding of your interpretation of the problem. But, unless you have used focus groups that dig into adoption at each level of your organization, then I would argue that you don’t have an accurate or complete understanding of actual needs.
Remember, there are three basic elements of a use case:
Only one of these three basic elements can loosely be identified as “technical” in nature: the system, which will have technology and business processes commingled. While the system is central to the use case, it is imperative that you have a solid understanding of the consumers and their goals if you want to achieve sustainable success with your solution. Your architecture should be involved, and you should survey a representative sample of your end user community (i.e. operations, business lines, customers, etc.).
Create working groups around each line of business that would be affected by the change. Get input from the people who support each line of business and make sure that inputs, processes and desired outcomes are clearly defined. Your operations folks should also put some thought into how they plan to capture and measure key performance indicators, as that will come into play later on when you ask: “How has my business benefited from this new technology?”
In Part 2 of “Roadblocks to Avoid When Deploying Technology,” we’ll examine two other common problems: absentee architecture and improper understanding of the technology.
At NetCraftsmen we have experience in highly successful rollouts of new technology. Feel free to contact us to find out how we can help with your projects.
Apstra’s Intent-Based Networking
Silver Peak is Serious about SD-WAN
BlueCat: DNS, DDI + Visibility and Workflow Automation
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.