After Ameritech, I went to Alcatel and became involved with technology strategy and M&A. I had the opportunity to visit a lot of IP-related startups and saw a lot of teams with very different approaches to system design and development. Most of them were building a product based on some breakthrough piece of hardware technology, either a novel product architecture (usually motivated by removing a performance limitation), a hero experiment in massive integration or a new division of labor between HW and Software, usually doing functions in HW that had previously been done in SW. A few of them were building software products or software stacks, tools and frameworks. More rarely, but memorably, were a couple of startups that had a balanced approach to systems design... that is, they made really good choices about what functions should go in hardware, what should be kept in software and what partners should they have to develop parts of the HW and SW externally.
A common problem of the HW guys was to plan the software as an afterthought and then to hire a team of software folks to do everything internally, usually because they didn’t have the budget or the time to work with external partners. The systems that resulted usually went to market with fragile and poorly tested software and if they didn’t fail right away, didn’t achieve stability until the second or third release of the software.
The most impressive of the balanced teams I met, had partnered for their key silicon components, had a simple / robust chassis and had 5 or 6 software partners for various stacks and frameworks. The internal resources were architects, testers and glue software developers. They followed the technology trends of their HW partner closely, working with each new chip well before it became generally available. The software partners were each chosen because they were up and coming technologists that would, in 3-5 years be the best in the business. The resulting product was leading edge, not bleeding edge and remarkably stable. When changes in standards happened, it was there partners’ problem to sort these things out and, because they were totally focused on their function, almost always got it right the first time and worked the standards bodies to stay on the winning side of the techno-politics.
When I moved to ADC, one of my early responsibilities was to consolidate network management from multiple platforms down to a single platform. This was a very challenging activity, particularly since we had to execute it during the telecom meltdown in 2001. We started with the best of breed EMS and then, over the course of a year, built a modular product architecture that maximized reuse as new releases and new products to manage came and went. This flexible client / server architecture was eventually overtaken by thin client products, however, the modular approach, user interface experience and test automation remained valuable for 10 years. This software team was built up in Bangalore, India and eventually became the center of software development excellence (embedded and otherwise) for all of ADC.
Next time... lessons learned from my software journey. What was your experience with the Good, the Bad and the Ugly of software systems?
No comments:
Post a Comment