DEVNET-1125 Partner Case Study - “Project Hybrid Engineer”

Editor's Notes

1. More businesses and organizations are seeking technology solutions to solve their important challenges.  And as more people, processes, data and things become connected, the pace of change is accelerating. These network-centric trends are creating challenges and opportunities for customers and for Cisco. Consider: 50B connected devices by 2020 (Telefonica I&D 2011 and Cisco Visual Networking Index 2012) 80% of Ent apps deployed in the cloud in 2012 (IDC Predictions press release: http://www.idc.com/getdoc.jsp?containerId=prUS23177411) 300K apps available in 2010; market grew to 2 million available mobile apps in 2012 (IDC and Deloitte Predictions: IDC: http://www.idc.com/about/viewpressrelease.jsp?containerId=prUS22617910&sectionId=null&elementId=null&pageType=SYNOPSIS and Deloitte TMT Predictions: http://www.deloitte.com/view/en_GX/global/industries/technology-media-telecommunications/tmt-predictions-2012/telecommunications/e6d1068df67a4310VgnVCM1000001a56f00aRCRD.htm#.UXQwLIIiHKg ) More data created in 2012 than the past 5000 years; 4 exabytes of unique information generated in 2012; more than the previous 5000 years combined (Source: Telefonica I&D 2011) Connected devices will outnumber people by 2014; There will be over 10 billion mobile-connected devices in 2017, including machine-to-machine (M2M) modules-exceeding the world's population at that time (7.6 billion). (Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2012–2017)
2. Traditional networks don’t understand relationships between end points (servers) and the services that govern those relationships (firewalls, load balancers, etc), - it only understands relationships between traditional network constructs – vlans, subnets, ports, etc. Often it’s not even clear which shared networking components a given app depends on, creating problems for troubleshooting and assessing the impact of planned maintenance (change control expected impact assessment).
3. If we look FAST IT transformation from EA angle then it becomes apparent a broader set of skill sets will be required that spans from Processes , Governance, Application Architecture and Technology solutions as well as Systems Integration and Operations and Management .
4. Business level consulting, CXO level business and technology mappings .. Also another breed of skills is operational and workflow processes skills which is a different set of skills requiring knowledge of operations frameworks such as ITIL, eTOM etc .
5. These are the roles that we think that our organization needs to evolve to , this is our future state … Buysiness ARchitecture Systems Integration Specialist – business : - Responsible for analysis, design and implementation of solutions which enable existing and new applications and custom built systems - Sample technologies and methods worked on include service-oriented-architecture (SOA), Business Process Management tools (BPM), Enterprise Service Buses (ESB), etc. Business Process/Workflow Specialist: - Responsible for analysis, design and implementation and refinement of operational processes and workflows which support existing and new applications and custom built systems. - Sample processes and workflows include Change Management, Problem Management ( ITIL) and Strategy, Infra & Product domain models from eTOM. etc Information Architec Platform Specialist – e,g. unified framework , services catalog / ucsd .. .openstack .. Apic integration w/ EN module ( Cloud + Element Application Specialist - Application architecture Technology Architecture : Prod Specialist , e,g, UCS expert e.g. CSE ( general portfolio , ) Domain Specialist SE e.g. Firewall / Security : VSG , ASA , VFW … don’t need to be expert in the product rather than the domain and functional blocks ( e,g, an existing TSA ) ..
6. Bettter way to evolve . Organic + In organic growth. Upleveling internal skills and bringing in talent from outside . Application specialist : General application architect role where person understands the applications and how these applications can use the infrasructur System Integration specialist :
7. Based on the business requirements . Not all CSE’s need to be assigned to this .. People leading this ( APO-STC ) should have MBO’s . We also need to look at people who have some thses pre-requisites already like the development background and they just need a bit of a direction rather than full blown hand holding .. These people that we id via the baseline exercise may understand what the software selling models are , how to structure licensing , ELA’s etc.
8. Asks/Recommendations are in Orange Nirav’s recommended person : Dipen Shah
9. The priority list will change depending on technology space however I have tried to categorize skills here.   Python (Across the board) Puppet/Chef  (DC) REST API/XML/JSON (DC) Shell Scripting/BASH (DC) Cobbler/CFEngine (DC) Linux (Ubuntu/RedHat) (DC/Cloud) JAVA (DC/NMS/Collab/Security) Openstack (DC/Cloud) OpenDaylight (DC/Cloud) XMPP/Jabber C   Python is a table stake. Every engineer needs to have a basic working knowledge of it .. and this is why we have chosen as “de-facto”.   Python, Chef, Puppet, CFEngine, and Cobbler (in this order) are also big in the DC space, but not seen in a lot of other technology areas right now. For instance, sys-admins like Puppet (declarative language) and programmers prefer Ruby (Chef is written using Ruby and Erlang), however in most of the cases programmers do not deal with network device automation, so IMHO, Puppet makes more sense. However, one interesting point to keep in mind that N9K (standalone chassis) support Chef instead of Puppet. You might think why is that, it was due to their beachhead customers and their preference and maybe because of better Chef documentation. This is the reason I have given Chef higher priority than Puppet.   REST API/XML/JSON form a good basis for a number of technologies and pervasive where it’s used. For instance, the ASR1K support RESTful interface.  We have XML support in our Nexus series as well as some XML/NETCONF support in IOS.  JSON is the data encapsulation language du jour on the internet. This is the reason I have this category higher in the priority list.   Linux is everywhere, too.  Some Linux/UNIX/Shell knowledge as we will see software and Linux appliance based software become more prevalent in each technology. For instance, OnePK can be distributed on an Ubuntu-based VM.   Java is somewhat important from the point of view that we have a number of applications that use it.  Understanding how to read Java code, stack traces and understand the semantics of the Java language help to make engineers in the NMS, voice apps, and security spaces better troubleshooters (and I'm sure in other technologies, too), however I do not see it as a high priority in APO or Partner SE community.    Openstack is obviously big in the DC and Cloud spaces.  It pretty much lives there with the exception that we have VIRL/CML on the horizon, and it will use Openstack under the covers.  That said, the level of Openstack customization will probably be low to non-existent, so engineers working on Cloud technologies may handle it like any of our other products that use Open Source software.   Opendaylight (ODL) is also big in DC space and Cisco is committed to it with our “platinum level” contributions at ODL. You may also know that we have standardized on three Cisco SDN controllers (APIC-DC, APIC-EM and ODL). Working knowledge of ODL and OF would be critical.   XMPP/Jabber towards the end in the priority list. For instance, XMPP will be getting bigger from the point of view that it is being seen as a good M2M protocol and something of interest for the IoT space.  But that is likely going to be a bit down the road. Our engineering working in IoT space may keep a tap on this.   C programming is included given that the onePK APIs will support it.  In Services it would be somewhat high given that our NOSes are built using C and Services engineers working on CATS, RP, and LAN SW technologies tends to read that code to effectively troubleshoot problems on those platforms. For APO and Partners SEs, I would not worry about it.   So bottom line, I would probably have the priority you see here for the DCN/Cloud space, but for other technology areas,  I would keep it general and adjust things up and down to make sure there is proper coverage.