Julio Alonso-Lopez
Vice President, Product Development, IP Routers

Professional background: Julio Alonso-Lopez oversees the metro, aggregation, and edge routers portfolio development for Ericsson. He has served as head of broadband access and of 3G customer support at Ericsson, and he has been Vice President of engineering for platforms.

Education: Bachelor’s of science from the Technical University of Madrid (UPM) and a master’s of science from the University of Texas at Austin; currently pursuing an MBA at the Wharton School at the University of Pennsylvania.

Personal passions:  Spending time with family — in particular, following my son’s football games and my daughter’s swim races; jogging; sharing a good meal with friends.

By Julio Alonso-Lopez, Vice President of Product Development, Ericsson

In December 2014, Ericsson delivered the latest iteration of our flagship IP edge router, providing more features and functionality in a single software release than we would have thought possible as little as three years ago.

As a provider of technology for the networked society, we serve operators of the world’s fixed and mobile network infrastructure, who demand steady advancement in performance from our products in an ever-shortening period from conception to implementation.  Their ability to support the connectivity requirements of a networked society depends, in large part, on us.

So what is the networked society of which I speak? Here at Ericsson, we define it as a society in which everything that would benefit from being connected is connected. Today, we think of this primarily in terms of the five billion people who are currently connected — people like you and me sending each other e-mails, text messaging colleagues, and calling friends and family. Tomorrow, however, we’ll also be thinking about connectivity in terms of devices, with upwards of 50 billion connected devices in operation by 2020. There’ll be sensors here, there, and everywhere, pinging each other and shooting a stream of data across the network for analysis.

As the networked society evolves, network operators are looking for continuous improvements in scalability, intelligence, performance, and simplicity. Agility is crucial, and we want to ensure we deliver the capabilities the operators need.

As evidenced by the most recent release of the IP edge router, the product development unit I oversee at Ericsson is rising to the challenge. When a particular customer wants a certain feature or functionality, we need to be able to be able to deliver it within weeks — not the months or longer that such development would have taken in the days of old.

Inside the IP router Product Development Unit, or PDU, making sure we can meet our customers’ requirements for speed has meant rethinking our approach to software development. In the past two and a half years, we’ve ushered in transformative change. We now operate in a manner that lets us deliver next-generation software with newfound urgency while maintaining our high standards of quality. We make sure that our development cycles are shorter and predictable, and that the software we develop is easily ported from one platform to another. The journey is far from over, since continuous improvement is a fundamental part of the vision. We want to ensure that every release is better than the one before.

How do we do it?

Let Teams Make Their Own Decisions 

Being able to increase content and streamline time to market has meant creating a new mindset for the organization. Quality needed to stay a top priority, but everybody needed to embrace a new way of working, new processes, and new tools.

This has been possible, I believe, through empowerment. Rather than micromanaging development from on high, we now assemble all of the competencies needed to complete a particular feature, feature set, or use case into an autonomous cross-functional team. Such a team might comprise software designers, software architects, and quality assurance and testing professionals, for example, and work closely with the product marketing function. The teams work with our lead customers to assess and prioritize requirements, and they have the authority to make decisions and drive feature development.

At any one time, depending on the product, dozens, if not hundreds, of these small, cross-functional teams will be working toward the same end goal. In developing that flagship IP router I mentioned, we had about 50 teams working on disparate aspects but in coordination with one another.

Every team has an end-to-end view, but each is assigned a feature or set of features to complete on its own. We try to give the teams as much independence as possible, but we do recognize that a significant amount of coordination is required. Toward that end, a program management team takes the lead on the release, and we optimize the end-to-end flow of the development effort. We believe that’s what gives Ericsson a competitive advantage in time to market and, longer term, in efficiency.

Make Teams Accountable for Their Work

In the early phases, our focus is on software architecture. We want architectures that will scale across multiple generations, so they have to be both forward-looking and backwards-compatible.  As we work on software architecture, we consider not only standard use cases but also scalability, maintainability, serviceability, and total cost of ownership.  We make sure our development teams have the right technical people on board and that those people have enough time to do their due diligence on architecture.

Technical governance is an imperative in achieving architectural integrity. As I mentioned, the teams must have clear ownership of the decision mechanism, but they also need to know the appropriate procedures for making changes and communicating about them. Accountability is critical, too, and we have established a good set of key performance indicators toward that end. For example, we set long-term objectives and then break those down into tactical KPIs, which cover operational aspects such as software fault density, hardware returns, and feature velocity. We’ve found that continuous measurement likewise allows for continuous improvements in efficiency and quality.

Put Teams in Touch With Customers

Taking measure of KPIs is important, but it’s not the most significant motivator. I believe the best way to motivate a development team is to circle back after customer deployment. Team members need to see how the product they’ve developed is being used in the real world. They need to be aware of the product’s market traction and see that it’s generating revenue and is superior to the competition’s offering. A true understanding of how the product answers specific market needs can be a great motivator.

We tried a bunch of different approaches, but we’ve found that the most effective way to ensure success is to send our engineers into the field. Visiting with customers on their premises gives them a deeper understanding than they can gain by phone, for example. In person, they can spend a lot of time seeing how our products fit into customers’ network designs, discussing problems and constraints, and sharing their visions for market evolution.

Product Development for Tomorrow’s Networked Society

As we develop our collaborative product development environment, we work toward meeting the four key requirements I mentioned above: scalability, intelligence, performance, and simplicity.

Networks will have to be highly scalable in order to absorb the increased volume and diversity of traffic coming their way. Network operators must be able to handle a steadily growing stream of Internet TV and video content while supporting an unending array of interactive, real-time applications and communications. As always, scalability means better throughput. But increasingly, scalability needs to be about signaling, too.

Sessions involving on-the-go users with smartphones and mobile devices tend to be quite chatty, generating lots of messages to be processed. This changes the nature of the signaling load on a network. In fact, we see the signaling overhead as a much bigger challenge in many cases than the data load, and we are always looking to introduce enhancements in hardware and software to address it.

The network of the future must also be intelligent, capable of analyzing behavioral information and traffic patterns, for instance, and adapting in real time on the basis of the analytics. From a product development perspective, this means we’ve been looking at our ability to capture, analyze, and present data to higher layers of the network or to the network operator.

In addition, superior performance becomes very, very critical in a world where everything is connected and everything will be housed in the cloud. And, lastly, simplicity is the order of the day. Our customers are looking for simpler networks, networks that are easier to operate, and networks that can reduce the overall cost of ownership — and here, too, we’re always pushing the envelope in our development efforts in order to meet those needs.

As I think about the networked society and how its demands filter down into my product development domain, I can clearly see that vendors that don’t adapt their product development approaches accordingly will not survive. As fast as society is changing today, it will be changing so much faster in the future.

Originally published in CTO Straight Talk, No. 2

The Takeaways

As network operators look for continuous improvements in dimensions such as scalability, intelligence, and speedy implementation, vendors must pursue continuous improvements of their own. Each software release, for instance, must be better than the one before.

Instead of micromanaging product development from the top, Ericsson creates multiple small, cross-functional teams, assigns each one a specific task—a feature or feature set—gives them autonomy to complete their task, and requires them to coordinate for the delivery of the end product.

To stay motivated and engaged, these teams need to visit with customers in person to see how the product is being used, how it’s answering a specific need, and how it’s performing in the market.