[Interview] Part 1: Celso Mello, CIO of Chubb Security Systems

This is the next blog in the continuing series of interviews with leading professionals.

In this blog series, we talk with Celso Mello, a leading IT leader. I had the pleasure meeting Celso at the CIO and IT Executive Summit in Montreal.

Thank you and Enjoy!

Stephen Ibaraki, FCIPS, I.S.P., MVP

______________________________
Celso Mello: CIO, Chubb Security Systems shares tips about: MPLS, VoIP, 1000-user Active Directory, High Availability

Stephen: Celso, with your impressive background in the IT field, we are fortunate to have you doing this interview. Thank you for taking the time to share with our audience.

Celso: It's my pleasure, Stephen. I am a great enthusiast of this blog and CIPS, just to name a few of the outstanding initiatives you're associated with, so it is really an honour for me to have been invited to this interview.

Stephen: Can you describe your current role with Chubb Security Systems and how you will shape the company's strategies and objectives into the future?

Celso: I am a direct report to the General Manager of Chubb Security Systems, and as such, part of the senior management team of that company. In that capacity, my role is essentially about making sure there is perfect alignment between business goals and IT initiatives, and that actually leads into the second part of your question - as the company sets its goals for the future, a well-aligned IT strategy can play a key role in assisting with them. For example, our company has aggressive goals around profitability improvement over the next couple of years, so my 3-year IT roadmap contains a couple of automation initiatives that will significantly improve employee productivity. This "strategy collaboration" also occurs in the opposite direction: for example, IT has identified opportunities for new products/services the business can provide to its customers through minor changes to our people/process/technology environment, and these have been added to the company's strategy as well.

Stephen: Please take a moment to wear your consulting hat as an advisor to other managers who are considering similar projects like the ones you have undertaken. What suggestions would you make to them to save them time and prevent the pain you may have experienced in your projects? What specific challenges/barriers did you experience and the resulting lessons and useful tips from your implementation of:

Celso:

1. MPLS network:
   Due to the nature of our business (electronic security), network availability is critical to our operations on a 24x7 basis. Downtime is not an option for us. However, any major network change, such an upgrade to MPLS we undertook, is very likely to cause downtime. To mitigate that I recommend having redundancy for your critical network traffic during the transition and stabilization phases. In our case, we had as many as 3 levels of redundancy.
   The other important lesson I learned from this project is spending enough time upfront on negotiating your Service Level Agreements (SLA's) with your telecom provider. Make sure you understand how site availability (or uptime) will be calculated, the impact of maintenance windows to uptime, what Class-of-Service (COS) and Mean-time-to-repair (MTTR) are; but most importantly, establish right from the start SLA's that will meet your requirements.
   A final word of advice: upgrading your network is NOT a turn-key project completely performed by the telecom company - you'll definitely need your best network/security person driving it.
2. VoIP-national phone system:
   This was a great project and there are good cost savings that can be drawn from it. But to specifically talk about barriers, the single most important issue we had goes back to the network component: it is called Quality-of-Service (QoS). In order for VoIP to work well, you definitely need the ability to configure QoS on your network, which is essentially about dedicating a fraction of your bandwidth exclusively to the voice traffic. Depending on the type and complexity of your network, you may not be able to properly configure QoS, or you may be forced to allocate too much bandwidth to it, impacting other types of critical network traffic, such as email or application-based. So, in summary, before you embark on a VoIP project, I would suggest you understand your ability to properly implement QoS.
3. 1000-user Active Directory:
   The main barrier with this project was in the area of change management. Over the years, users tend to build their own setups and workarounds to overcome constraints, or sometimes they're given more rights than they need in order to perform their job functions, and they get used to that.
   First you need to bring it down to a level playing field and that requires a lot of internal communication and justification, or in other words, internal "selling". So, I thought about giving something in return to those users in order to achieve my objective: I had some of my best IT technicians travel to every remote branch and as they did the necessary setup on each PC to convert it to Active Directory (AD), they offered to solve any other PC-related matters those users might have. It may not sound as a fair trade, but it works much better than if you simply impose the change.
   Once you deal with the change management issues, you'll find the effort and investment well worth it, because AD gives you a logical network environment that is much easier to control and maintain, which greatly helps with your compliance efforts.
4. High-availability upgrade of your business critical application system:
   Every application implementation or upgrade is a bit different, so I'd like to focus on the high-availability aspect of this to talk about barriers. Because this particular application has a no-downtime nature (very much like our network), it was critical that the new version of the system we were upgrading to had the same level of reliability as the old one.
   To determine that, we used automated tools that simulated transactions and users on the system, starting from our peak historical volume and going up from there to identify bottlenecks. After addressing as many bottlenecks as practical/cost-effective, we arrived at a configuration we're confident that will handle our maximum historical load many times over. This is reassuring when you think a transaction "surge" could actually happen gradually as a result of great company growth (which we hope for), or abruptly due to a natural disaster (which we obviously don't hope for). Either way, now we know we're prepared.
   So, the lesson here was the value of "stress testing", which can reveal system bottlenecks which you can easily address if identified early on, allow you to properly size your hardware and give you "peace-of-mind" that the system will accommodate growth or unforeseen events. Note this applies even if you're not implementing a high-availability system.

________________________

Look for more with Celso in the next blog.

I also encourage you to share your thoughts here on these interviews or send me an e-mail at sibaraki@cips.ca.
________________________