Cisco’s Very Big Conservation of Complexity Problem
Of all the tools in its ginormous account-control arsenal, Cisco holds solution “complexity” near and dear to its heart. Since its earliest days, Cisco has weaponized product complexity and applied it to pretty much everything from product design, to sales, and even to service and support. Examples abound, but let’s just take a peek into the product side first, and then look in on the origin story for the CCIE (Cisco Certified Internetwork Expert) program, which has been so massively successful it’s now become a nice little earner for Cisco – generating about $150M to date – in and of itself. Before we start, it should be noted that complexity is – warning, BGO (Blinding Glimpse of the Obvious) ahead -- the last thing Cisco customers are actually looking for, if for no other reason that there simply aren’t enough top-flight network engineers in this life-cycle for them to hire at any price. Cisco, however -- very much the prisoner of its own business model -- purposefully soldiers on.
Days of Cisco Past (1989) – a New Hope
Having clearly reached that “Get Off My Lawn!” stage of a 30+ year career in networking, over the next couple of months I’ve decided to share some unfiltered “insider” observations about how Cisco turned from its late 80’s IBM-killer roots, with its well-earned reputation as the liberator of enterprise businesses around the world, to, well, IBM redux. Even separated by 30 years the parallels are obvious, but here they are: “Massive company owns the global enterprise networking market; sells its customers identical undifferentiated, proprietary solutions (with baked-in obsolescence); charges ever-increasing and often tear-inducing fees for software and maintenance; leaves customers desperate for an alternative.” In 1989-1990, Cisco, when it had about 100 or so employees, was that fresh alternative. Any customer/prospect technical question that came in was jumped on immediately, often to the chagrin of management, by multiple people in engineering and support offering opinions (competing at times) on exactly what action the customer should take, but it was all about listening to the customers and doing right by them – and it worked like a charm. This pervasive customer advocacy philosophy was critical to how Cisco persuaded large enterprises that firmly believed back in 1989 “you can never be fired for buying IBM” to, well, not buy from IBM anymore.
Dating “Dos” and “Don’ts” from the IT Automation Survey
In my last post, I introduced Pica8’s new IT Automation survey. I discussed how the survey shows that digital transformation is driving IT’s focus on automation, especially how they manage automating remote sites. They are clear about their desired goals, and IT automation efforts are well underway. In this post, I’ll present the challenges IT faces in their automation efforts and provide some advice on how best to proceed with your IT automation efforts. As a reminder, while IT automation is a clear focus, engagement varies by IT domain. Let’s start by looking at the challenges IT is facing in each area. In terms of automating the data-center, the biggest challenge was a lack of staff automation experience. I say “was” because IT has largely completed automating the data-center (as well as their cloud, remote sites and mobility.)
Enterprise Automation 2020 Survey - Part 1
It’s clear that IT automation is happening at enterprises around the world. But there are lots of areas within IT. Which are organizations automating first, which are last, and what’s next on IT’s automation playbook? To find out, Pica8 commissioned ReRez Research of Dallas, Texas to survey 200 Senior IT managers in the U.S. and Canada to learn more about how IT is embracing automation in different areas. We surveyed all areas of IT, but skewed senior-level with a third coming from IT executive roles and 59 percent coming from IT management. We reached all sized organizations from SMB to large enterprise, and across a wide range of industries. The survey shows IT is laser-focused on IT automation.
Why We’ll Colonize Mars Before Cisco Understands Software
Over thirty years ago – ouch -- I joined Cisco as its very first marketing hire, tasked with giving them a more professional image than “Stanford grad students run amok” in preparation for their IPO. But during my six-year posting, I also got to witness Cisco’s first attempt to build an actual software solution, a now long-forgotten SNMP management platform called NetCentral Station. After throwing significant R&D and marketing capital at NetCentral Station over the next year or so, Cisco threw in the towel. As its product manager prophetically told me in the end days, “We should never have entered a business we know nothing about.” A decade later her words remained prescient. Then I was working for a small startup comprising networking software developers who had previously been acquired by Cisco for quite a high valuation because of their VoIP expertise. Cisco followed good business practices – in their view -- and locked down the founders for three years by detailing an extensive scope of work for software development that they had to complete before they would be allowed to leave the company.
Viable Open Networking Automation Solution Comes to the SLED Market
Automation is increasingly required to keep up with growing access network requirements, which are forcing organizations to add new switches and/or replace older switches with higher-capacity models at an accelerated rate. With precious few experienced network engineers and technicians in-house, it’s difficult to deploy large numbers of these switches manually – hence the need for automation. The “gotcha” here is that automation software from legacy networking vendors, such as Cisco, is so expensive as to be out of reach for many organizations. This is particularly the case for users in state/local government and education (SLED) markets, for example, who must operate within very tight budgets to make effective use of taxpayer and donor dollars. Shelling out tens or hundreds of thousands for a Cisco DNA Center automation package is tough to justify. It’s a situation that has users taking a very hard look at whether open, white/brite box networking hardware paired with automation software for open switches and enterprise workflows can meet their needs at a cost that’s more in line with budget realities. In a word, the answer is now, “Yes.”
A New Solution for SLED: Open, Automated White Box Networks
Operators of state and local government networks; K-12 networks; and higher education networks have long had to lean heavily on automation tools to deploy, configure, and manage their campus and access switching infrastructure due to the combination of multiple remote sites paired with lean IT support staffs. This, in turn, has made them extremely dependent on the, at times extraordinarily pricey, automation tools served up to them by their vendors. With Pica8’s first-of-its-kind automation framework explicitly designed for these networks they are captive no more.