Why IT Standardization?

Cisco IT has over our history become more and more standardized, with standard architectures (which are continuously upgraded to meet future business needs), and standard products, designs, software versions, and configurations. But we’ve never really told the story about WHY we have standardized so thoroughly. Many customers ask “What is the value of a global IT standard vs. regional or local designs?”

The answer is this: from an Infrastructure point of view, the value of standard architecture, standard product sets, standard software versions, and standard configurations are all very clear. The value it brings? It comes in several areas:

• Reduced operational cost and pain;
• Faster time-to–capability;
• Greater Reliability;
• Greater Scalability

A standard architecture is built of reusable, reconfigurable components and offers faster time-to-capability, and also helps ensure better interoperability. Software architecture in particular is built up of reusable components like Single Sign On, web portal services, database look-up services and so on. Infrastructure architecture has its parallel reusable services like load balancing and firewall services, and netflow information. As for interoperability — it’s easier to provide end-to-end features like IPv6, QoS, traffic security analysis, and application quality monitoring, if everything carrying traffic has the same feature sets and offers the same set of traffic monitoring and controlling features. It’s also more scalable, in two ways. An architecture of fewer parts is less complex, and can grow the design by adding more capacity or more identical parts. And as a more simple architecture grows the support staff doesn’t have to grow as quickly as the infrastructure, keeping the architecture more manageable and more cost-effective.

Standard product sets reduce opex costs – you only need to stock one set of parts, and train your Ops people on one set of troubleshooting skills. And they are the foundation for our Fleet Management system, our continuous (yet fiscally controlled and predictable) infrastructure upgrade process. A standard product set means that when you upgrade all over the world, you only have to build one standard migration plan, and train the implementation team on one standard migration process. Standard software sets make it easy (or easier at least) to automate migrating to a new version upgrade. All this means both infrastructure hardware and software upgrades are faster, easier, less problematic, and involve less downtime.

Standard configurations enable global support models. If there’s a problem at 3 AM someplace (and infrastructure problems often seems to strike at 3 AM  🙂 ) your global support team can connect to the problematic device and dig into configuration issues confident that they know exactly what they should be seeing, and a badly configured QoS or ACL change or other configuration problems will stand out more visibly. Issues are easier to fix, downtime is reduced, and a global remote support team enables local network engineers to get a full night’s sleep.

Cisco IT has had lots of internal arguments about the value of local vs. global design over its history, before deciding to move to a global set of standards. And many arguments for more local or regional design are still valid. Local design teams point out that they have to respond to local physical environments (e.g. Power supplies, ISP or SP cable connections) – this is quite true, and equipment procurement must take that into account. They also point out that their local employee/customer base may have different needs than are met by the existing global standard. This may also be true, and in our history it often was. But that was, often, a factor of our “global” architecture being designed by people in one place (e.g. our HQ, San Jose), who were not responding to the needs of remote regional customers. This issue was met by changing our architectural process, and our architecture teams, to be global in nature, and more aware of and responsive to regional needs; over time, it became so. Today our architectural teams are far more global (enabled, in my opinion, by a strong collaboration platform); and our architectural process has become far more global as well (driven by the global business needs which form the foundation of Cisco IT’s Operating Model.)

There were also some other political or business drivers for more local IT. Local design teams didn’t want to give up their political autonomy. This issue was removed by Cisco IT management turning local design and support  teams into global teams, reporting to other leaders in other location.

Last, there is the argument that a more local IT design can provide faster, more responsive IT solutions, and I think this is still partly true; but it comes at a significant cost. Regional customer groups want  local IT engineers to design custom solutions for them because it was faster for them to get their needs met, as the global process took longer than a skunk-works local team building a custom solution. However, in the end the local designs were less easy to monitor, manage, support or upgrade, and often less reliable. Faster doesn’t always mean better.

Nonetheless, it is true that IT doesn’t always respond as fast as the business would like, even though it should. Cisco IT has responded to this business need for speed over time with several different global efforts; for example:

• As part of an “IT as a Service” organization, Cisco IT works much more closely with the business, both regional and global, to determine business architecture needs, and tries to understand and anticipate future business needs and build the foundational IT platforms to support these future needs, reducing the time-to-capability delays of future projects by putting the required foundational elements in place ahead of time;
• Cisco IT offers the ACE program for faster delivery of leading edge technology to the most vocal consumers inside Cisco: Sales;
• Cisco IT has over time developed a faster release cycle internally, guided by our ACE program and delivered by our Fleet Management program; and
• Cisco IT enables a lot of self-service cloud services for user-customized application and internal private cloud capabilities.

These improvements have removed many (but not all) user concerns for faster IT, and some internal Cisco customers continue to “vote with their credit card” by buying “gray IT” cloud services when they feel Cisco IT is not responsive enough.  Still, Cisco IT has made some major strides in reducing user needs for “gray IT”. Cisco IT’s new direction to “Fast IT” is in some ways a further response to this issue.

In the end the biggest proponents of Standardization in IT are the IT operations engineers, because it makes their lives easier. And the biggest winners of a Standardized IT architecture, with standard products, software versions and configurations, are the business who receive better, faster, and lower cost IT services.

Share