Figure Out What the Customer Really Needs

One of the toughest challenges you can face as a networking engineer is trying to understand what the customer really needs (as opposed to what they think they’re telling you they want).

For example, the server team comes to you saying “we need 5 VLANs between these 3 data centers”. What do you do?

The correct approach is to figure out what problem they’re trying to solve, work with them to understand the limitations (from application architecture, database setup, storage replication…) and finally propose a solution that’s close enough to what they think they need but doesn’t compromise the network stability.

To do that, you have to understand a bit about the application architectures, and that’s what I’ve tried to explain in the Designing Active-Active and Disaster Recovery Data Centers webinar and numerous other webinars, as well as in the university course I’ve been teaching.

I can’t tell you how delighted I was when I received this email from one of the engineers watching my webinar:

We have a customer and he wanted to migrate his application from active-DR(manual) into active-active or active-active-active and introduce cross-DC load balancing and VLANs everywhere.

So I used the information and guidance based on your webinar to stop this approach (for now, waiting for answer to my feedback) and hopefully it will be changed to proper swimlanes in each DC and DB replication based on their requirements.

So the webinar was very useful, full of ideas and recommendation, and I am satisfied and happy because it helped me in real life. But fight is not finished yet…

I can only wish him luck ;)

More information

Want to be like that engineer? Here’s one potential path to take:

You get access to all these webinars (and over 60 more) with the ipSpace.net subscription.

Finally, when you’re ready for the big challenge, take the Building Next-Generation Data Center online course.

6 comments:

  1. "The correct approach is to figure out what problem they’re trying to solve, work with them to understand the limitations (from application architecture, database setup, storage replication…) and finally propose a solution that’s close enough to what they think they need but doesn’t compromise the network stability."

    I think you are confusing the role of "Enterprise Architect" and "Network Engineer" a bit here. If the Network Engineer needs to figure these requirements out, the Enterprise Architect is not doing his job.

    I agree that many EA's don't know the first thing about networking principles, but if you want to solve this problem fundamentally, you educate your EA, instead of re-engineering the requirements of every IT application.

    Automation does not stop at OSI layer 7 ;)
    Replies
    1. While I agree with you, in practice there's a huge gap between theory and practice, ranging from "what's an Enterprise Architect" to "Enterprise Architect doesn't need to know the dirty details" ;)

      Also, since my blog is way below the radar of Enterprise Architects, the best I can do is to educate the people who have to deal with the consequences.

      Anyway, IT is not the only discipline where architects live in rainbow-colored clouds. I had the dubious "privilege" of being involved in a few building projects...
    2. Well, whether it's a building or a network, as far as so called "architects" are concerned, it's the same:
      Don't approach any project without having a structural engineer involved - the only difference is, that in IT this job is called "network engineer"...
    3. I think that's not an education problem, it's impossible to have the knowledge of a senior network engineer without years of hands on experience (I recall Ivan had a good post about this but couldn't find it).
      IMHO a good architect should create the plan and peer review it with the stakeholders, network and systems engineers, ... "there's a huge gap between theory and practice" that you can overcome with this practice.
  2. This comment has been removed by the author.
  3. In my opinion an Enterprise Architect is a translator. Someone who can take the high level business requirements from the business and gather the correct technical groups and present them with the requirements in semi-technical terms. In my experience they devote the majority of their time dealing with the business than with the technical teams.
Add comment
Sidebar