Effective October 1, 2012, QUALCOMM Incorporated completed a corporate reorganization in which the assets of certain of its businesses and groups, as well as the stock of certain of its direct and indirect subsidiaries, were contributed to Qualcomm Technologies, Inc. (QTI), a wholly-owned subsidiary of QUALCOMM Incorporated. Learn more about these changes

Vertical vs. Horizontal Integration – Who Wins?

Building a smartphone today is not easy. Ask anyone who’s done this for a while and they’ll agree. Earlier in my career I did software for missiles, and trust me, it was MUCH easier. So, smartphones are not rocket science – they’re worse in my opinion. Why is that? Well, there are a number of reasons. Folks like to compare smartphones to PCs/laptops, but you don’t stick your PC in your pocket, your PC is not always with you and you probably don’t use your PC as your main voice communications device, let alone as a conveniently available camera so that your friends believe you when you tell them you ran into Sasquatch on your last camping trip. It’s the smartphone’s inherent mobility that makes the engineering such a challenge.

In addressing this engineering challenge, there are a couple of different schools of thought out there today. Some folks argue for the vertically integrated approach, where there’s tight control of the entire software stack from the application interfaces all the way down to the hardware. Others argue for a horizontal approach, which provides for clean lines of demarcation between applications, middleware and the HW-specific software, which I like to refer to as “The Adaptation.” Both approaches have been around forever, and both have been responsible for producing millions upon millions of mobile devices.
It used to be that vertical integration implied a closed system, where the OEM put the whole package together – apps, middleware and adaptation – and this was sold “as-is” by the operator. Historically, this was done in the feature phone space and below, using either proprietary operating systems or real-time operating systems with a custom user interface designed on top.

Indeed, this approach still probably accounts for a significant percentage of handsets sold globally each day. Now, however, this approach is finding favor in the smartphone segment as well, but with a twist: the middleware and adaptation software layers are relatively fixed, but the application layer is open for development. Sound like anyone you know?

On the other hand, the historical model for smartphones was to use a high level operating system with a rich set of public APIs at every layer of the architecture, to allow for maximum software (and hardware) differentiation. Don’t like the video player middleware? Just yank it out and sandwich your solution between the application interface and the adaptation interface and problem solved. Just like “There’s an app for that,” there’s a “middleware” for that. But wait, that doesn’t have the same ring to it, does it? Well, in reality, the market for middleware (and below) developers to innovate on the platform was relatively small and as a result, not too many companies ventured into this space unless it was to market a broader offering.

So, although a good idea, few companies actually participated in this type of innovation because even fewer of them profited by doing so. And lately, in my view, much of the middleware is seen as commodity or has been standardized, making it a less attractive layer to third parties and easier to vertically integrate. A horizontal model with a clean separation between the adaptation and middleware is also attractive to OEMs because it gives them flexibility in their HW selection, as it’s far easier to swap out application processors and other HW components in the horizontal model.

So, with the vertical model, I believe you get a tightly controlled user experience at the expense of HW and middleware flexibility. The horizontal model gives you that flexibility in my opinion, but is less tightly integrated in the vertical plane because of its obligation to support public APIs, binary compatibility, etc. Into the midst of this fray enter the emergence of legitimate open source smartphone platforms: LiMo, Maemo, Android and now Symbian.

Now instead of just seeing the APIs, potential middleware developers can actually see the source behind the APIs and drive innovation across the platform. The jury is still out on the degree to which developers will capitalize on this opportunity, but it is now there in a way that simply did not exist a few years back. Open source has added a third dimension to this traditionally two-dimensional argument.

With clear benefits to both approaches, the obvious question to me is, “Can I have my cake and eat it too?” Maybe. Selecting key aspects of a horizontally-integrated device and vertically optimizing them to achieve certain objectives is definitely possible, while still allowing for innovation at all levels of the platform – particularly in an open source platform. While the vertical approach may offer the advantages of tight integration, in my opinion it is not a vehicle for innovation below the application layer and, as such, cannot become horizontal – whereas the open platform is more flexible in that regard.

So, in the spirit of the Winter Olympics, I’ll call it a photo finish, with the open platform winning by a nose because of its scalability and flexibility. I know there’s much more that can be written about this topic and I will leave that to all of you, since I’m already well over my allotted blog space with this post.

Let the discussion begin!

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries ("Qualcomm"). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.