Nameer Kazzaz, CTO of Blueface
Blueface’s CTO talks about the importance of having a plan A, B and C, owning the code, and developing with a crystal ball in hand.
Can you put in context how extensive Blueface’s IT operations are?
From a point of view of infrastructure, we’re a typical carrier in every sense. Obviously, our core business is voice, so all of our engineering resources are about building a resilient carrier network. We have interconnects with all of the big carriers and our key targets are to make sure that’s as resilient as can be.
Because we’re OTT (over the top – delivering services across IP networks), our infrastructure is pretty much at the top and everything after that is IT-based. We currently don’t have infrastructure like copper lines. We don’t unbundle the local loop: we deliver the service over broadband, IP feeds, fibre, whatever that may be. In some cases, we do partner up with infrastructure carriers, predominantly for the service level agreement needs of the customer.
Does the way you’re set up make the infrastructure that you manage more complex or less complex?
To be honest, it’s a combination. Sometimes when we come up with product ideas, it initially sounds simple but as you build in resilience, scale and billing, and including the cost, that becomes a fairly big process.
Because we sell to businesses, the service has to be 100pc available. As an OTT, because you’re reliant on third parties, you have to have a lot of A plans, B plans and C plans in place.
What does that involve in practice?
For example, if we’re deploying a voice solution for a customer and you need a DR [disaster recovery] option, you could quite easily just replicate what you build on their main site on their B site. We’re proactive, we move them regularly from the A site to B site to test.
In a sense, we’re constantly using both. From a delivery point of view to the customer, the voice service is always available. Plan C is where they could need even more than that – maybe we could use backup mobile services where there’s not enough connectivity to the site.
Do you bring that point of view of always needing a good backup plan to your job?
It’s definitely something we bring in to our sales meetings. Our sales team has to be technically savvy, we have to be different. We have an MVNO network. People assume we’re running a VoIP app but it isn’t – we have interconnect. The sales people have to be able to field those questions from customers.
Given that you’ve been providing hosted services, do you consider Blueface as a cloud company?
Nowadays, you could call OTT hosted or cloud; we’ve always hosted voice. What we’re doing now, and from the point of view of where it’s going, is that we’re doing more enterprise-class products, like unified communications products that are moving from the clients’ premises so they’re available to everybody.
Cloud starts to make sense from an engineering point of view where you are dealing with a layer you can physically move, and that’s quite powerful for carriers if you needed to upgrade hardware, you have to disable part of network and that means customer service is disrupted.
Was Blueface an early user of cloud internally?
Because we develop everything in house – and that includes our own management systems for the business, from billing and managing the customer to deploying the network – our comms room here is fairly empty. Everything’s always been in the data centre where we host, and where we run everything from. In that sense, we’ve probably always been reliant on cloud. We’re probably doing more now, though, in terms of email and sales products accessible from anywhere,
What’s the split between the part of your IT team that works on developing your products and services, versus the maintenance side of IT – keeping the infrastructure up and running?
We have systems people, as well. I suppose we’ve been very lucky in the people we have, if there’s something missing somewhere, we develop it. I’m a big believer in owning the code. If we acquire a piece of software – which we don’t do often – we also acquire the code. It keeps us flexible, it keeps us lean.
Why we do that is, it gives us flexibility in scaling and changing. Especially in this market, we have to adapt quickly. If we develop a product and it doesn’t go the way we want to, we can change it very quickly. It takes me longer and it’s a lot harder to change it if we outsource. At moment it works in our favour that we do things in-house.
There’s a lot of cross training. We have a lot of people with an understanding of how the technology works, and how to write reusable code, so that we’re not redeveloping. We are developing new products for the current environment and with crystal balls in the other hand, we try to make sure what elements we have – we try and develop where we don’t have to come back to this. Sometimes that works – 80pc of the time – but other times you need to tweak it a bit to keep it going.
We always look at our network in its current size, and we look at what it will be like in a year. (The year) 2013 was a good year for us, and everything tends to get doubled up when we see good figures: our infrastructure is better, more people are connected.
What are some of the big projects you’re working on this year?
Some big projects we’re working on for 2014 is machine to machine (MTM). If you ask me what we’re going to put on it, I could give you a couple of ideas, but we won’t know until we see what the need is from a customer perspective or service providers of a different sort.
The MTM concept and the whole ecosystem is becoming a big part of what we do. When it comes to technology, it tends to be a physics thing and we see how that trends out: it’s a move to bigger bandwidth, better connections, so that’s more of a known trend. The harder one to judge is selling, and judging what products do well.
Are you very hands-on with the technology, or is it more of a management role where you’re less involved with the nuts and bolts of IT?
I always review how my month has looked, and it kind of goes up and down. I like the business side of it more than I initially assumed I would. But in a sense, I’d say it averages out 50/50, depending on where we are and which market, or depending on how deep we are into a product.
We built our second POP (point of presence) in our data centre and that involved a bit of commercial discussions but also we had to make some fundamental infrastructure decisions. And then sometimes I could go as high as 20pc of my time being hands-on. But it’s because we have a technically savvy team, it helps. I’m happy with that ratio.
I’ve done a combination of things, but I always put it down to the people around you: I have an excellent guide in my CEO. I’d be part of the commercial decisions but I used to stay on the side. More and more, I learned from our CEO and now I think I’m in a position where I’m involved in commercial deals – on a customer deal or on a commercial deal.
I feel I have more of a grasp on what Blueface’s business needs are. I’m not saying it’s my forte but I do enjoy it, and it’s interesting to understand both. I understand the technical needs but you have to look at it from a commercial cost and benefit.
So which one tends to win out, the commercial or the technical side?
It depends on where the idea comes from. Having an engineering team and developers, you can do so many things but it’s about what makes commercial sense. I love my gadgets, there’s no two ways about it: I’m definitely a geek – a typical engineer kind of person, but I do understand some things don’t make commercial sense. Because we sell to business, it can’t just be cool, it has to make sense. And to be honest, some of the crazy ideas don’t always come from engineering!
I think it’s about what’s active in the market. The Italian market (where Blueface acquired cloud telephony provider Kebu in 2012) is very similar to the Irish one, but the need and what they perceive is a good product is very interesting, so I also find that dynamic very interesting. You have to have a different opinion in each market, even if it could be the same product.
