Systems Engineering Life

I am sure at this point, you all have caught up on with this SD-WAN craze.  Some early vendors are now bought by industry giants.  Some have really cool cloud provisioning and management dashboards. Some claims that your edge has never been this simple to set up before. However, there are still a few concerns I have: VPN technology is a mature one by now.  There are vendors out there who can offload IPsec tasks and processes onto a hardware based processor.   Would these new "SD-WAN" providers give me the same throughput/granularity? How scalable is the solution? Applications - There are vendors out there who did WAN Optimization for living and have a very rich application signature database.  What about the pure play vendors? Same goes for routing.  can you handle complex routing? can you offload or optimize those touting decisions? What if I already have that infrastructure (VPN/Routing) in place? would your solution be a tunnel in tunnel? What would

"You need to have a collaborative hiring process." Steve Jobs I talk to my customers on regular basis and more often than not, the discussion about an available position comes up.  I also hear when engineers are looking for a new opportunity (for various reasons). I have to be careful with all the legal and political aspects of putting in touch my customers' engineers and hiring managers together. I have seen great success with these types of hiring (or match making).  As an unbiased 3rd party, I somewhat know who fits where and what type of training or coaching is needed (if any) for the candidate to flourish in this new environment. I have had friends asking for an introduction for a position which I declined because it wasn't a right fit. Sometimes, it is very hard to sift through resumes and find good candidates.  Sometimes, it is hard to make a resume standout and eventually get in front of hiring managers.  But asking someone who knows both parties to make

As a SE, I see successful roll outs and adoptions as well as botched ones.  When I go through post-roll out analysis and lessons-learned efforts, most of the time, I see the culprit right away.  Lack of knowledge and going through the project/roll out blind, usually sinks the ship. There are many reasons some customers skip training.  The first reason always points to budget.  I hear "We don't have budget for training" or "our engineers will figure it out" or the best one yet, "we don't see any benefit in wasting our engineers' time with training". The second reason is "ego".  I know we are all engineers and have been around security or networking products for a long time.  But implementing a new security platform in an enterprise will take some time to correctly configure, optimize and utilize.   a new centralized management system which requires some scripting knowledge alone  is an formidable undertaking. By blindly going throu

When it comes to firewall upgrades or refreshes, you need to know your: Current traffic volumes and mixture Session counts Number of users Current and future Internet or private connection pipes Current and future throughput requirements (VPN, SSL Inspection and decryption, etc...) Current and future unified threat management (UTM) needs Interface requirements  Number of IP devices LAG requirements  Future growth  I am sure you can come up with more variables and compare it to the vendors specification sheet in order to come up with an accurate size or model of a security appliance.  However, nothing beats a real/live test with a traffic generator.   When I usually size a box based on the customer's requirements, I also factor in real life examples, previous firewall implementations and what the Internet/application traffic trends. I have heard so many "oh we are not going to use such and such application" or "we will never use SSL inspection"

Does your product integrate with other security products? At this point, you should hate product silos (point products) as much as I do.   I understand and respect “divide and conquer” or “best of breed” strategies. I also understand having different security vendors at different layers of the network could possibly prevent an incident better (one vendor might not see/catch a vulnerability but another might have a signature or way of catching it). But isn’t it time to ask your vendors how and if they can work with each other? So what we (vendors) are competitors?   If by integrating with each other, we are able to increase the return on investment (ROI) for the customer, then why not (I know it might sound naive and unaware, but could you just imagine ). Vendors have application programming interfaces (APIs) for interaction with other platforms.   However, customers have to have application development resources to write code for these APIs, and that's not answer to a tr

Your vendors’ systems or sales engineers are a wealth of knowledge.  I don’t say that because I am one, I say that because we have been around various IT departments as employees or sales engineers.  We have seen different ways of achieving the same goals and can save you headaches or hidden roadblocks. It is mostly a myth that we only know the technology we are representing or selling.   First of all, we have to know our competitors’ technologies well enough to be able to differentiate ours. Second of all, we have to know enterprise IT applications well enough to make sure our products actually work in tandem. SEs also talk amongst themselves.   I might not know the project you are working on, but I am sure one of my colleagues do.   I work with a great group of engineers from different backgrounds.   They are sharp and always willing to help. I’ve worked in energy (both upstream and downstream) industry, healthcare (distribution and provider) as well as manufacturing (