Where were you in 1998? Somewhere in one of our customers, a customer booted one of our 3640 routers, and it’s been running ever since without a reboot!
It’s been running since last century! Wow. It’s been running since around the time my daughter was born, and a good few years before my son was born! It’s been running longer that some of our competitors have been in existence, and longer than Juniper Networks has been a publicly traded company!
I learned this from an email was passed around my office, that highlighted this remarkable evidence of reliability. It made me wonder, in your data center, what is your longest running piece of Cisco data center equipment?
And it also reminded me of some of our best practices for network reliability, such as Cisco Smart Services, described in this short VoD:
So now for the evidence. As you can see from the “show version” Cisco IOS output below ……
March 2009 was an exciting time for both for Cisco and for me personally. Cisco launched the revolutionary Unified Computing System, with many observers across the industry doubting if we’d stay the course (and if we’re honest, some truly misplaced derision -- I wonder who is on Planet Zircon now!). And I joined the Cisco Data Center Services team from the Cisco R&D organization! So with the recent third generation launch of Cisco UCS, described very well by my colleague Todd Brannon, I thought it would be a good time to reflect on our data center services portfolio around that time, and where we are now. My previous blogs chronicle part of this journey, however I have to say, the direct comparison I draw here I personally think shows that we have indeed brought a new transformational experience to the data center for our customers. And I’d like to give you my personal recollections on how and what I found out about Cisco’s approach to shaking the incumbents’ lack of innovation in the blade server market.
In part 1 of this posting, I related a real-life experience of mine, where I learned that customer problems were often a better source for product and service definition than formally stated customerrequirements. I’d like to take this discussion further, via a concept in product and project management called the “tyre swing”. Read More »
If you are already offering cloud services from your data center, or are starting your planning to do so, there are some key initial questions I’d advise you consider. And they’re not about the technical aspects of data center architecture! You find yourself asking “what cloud services should we offer?” and “How do we evolve what we offer today”. You may, post launch, also find yourself asking “Why is the take up to our cloud services not as big as we initially forecast?”. Before you say “aha - these are questions for service providers offering cloud services” .. I would argue that these questions are fundamental to enterprise and public sector organizations too -- assuming that you intend to provide cloud services to your user community that help them do their jobs. Following one of my colleagues who blogged earlier that, with cloud services, “you need to think like a product manager”, I will assert here that there are some key lessons from product management that can help you in creating cloud services that are actually useful to your customer and/or your internal clients and stakeholders.
As you may have noticed from my previous blogs, I’ve worked in product management of both products and services for a while (since 1997 in fact, when I moved from software engineering into the “dark side” ) …. so what lessons have I learned that may help you address the challenges of creating and defining new cloud services?
A few months ago, after a my previous blogs discussing cloud computing adoption, I changed subject and authored a short series of articles around the challenges of adopting an architectural-led approach to your IT strategy in general, and data center design in particular. (If you missed them, you can read them here: part 1, part 2, and part 3). The theme of these articles centered on the Winchester House in San Jose, California.
This house was extended by builder after builder, without any architectural blueprint. Consequently, this house had many doors opening into blank walls, abandoned staircases, and other “features” — and it was in construction for year after year, with point additions compounding the problems. I then asserted that this analogy can apply to how IT architectures sometimes evolve -- bit by bit, without a formal blueprint or “grand master” plan, if you will.
Architecture-Led Facebook Poll Results 31 Jan 2012
I finished the series with a poll on our Cisco Data Center Facebook page - thanks to all of you who spotted the poll and took the time to respond. The results were indeed interesting, so I thought I’d share back the results with you and discuss the implications. As the diagram shows, you certainly told us loud and clear what your biggest issue was when it came to adopting an architectural-led approach to your IT strategy and data center design: “We don’t have clear enough business goals for IT” scooped 65% of your votes, way ahead of all other options (!!) -- so let’s discuss now in some more detail.