Socorro Independent School District in El Paso, Texas had a big challenge. They were looking to create an academy focused on specialized student learning, as well as creating a 1:1 learning network for their incoming freshman students. Despite being near the border of Mexico and serving a number of low-income families and at-risk students, they had the focus to provide their students with all the tools possible to set them up for success.
In order for Socorro ISD to deploy devices and computers for their students to have access to updated curriculum, and to turn their focus onto 21st Century Learning (C21), they would have to find budget or alternative funding for a necessary infrastructure upgrade. This would allow Socorro ISD to achieve their goal of having the digital curriculum they desired.
Socorro ISD used E-rate funding and local sources of revenue to help meets its technological needs. They worked to put together a compelling plan to leverage Category Two funding for the needed technologies at each campus.
Cisco stood out among the other solutions. Chief Technology Officer, Hector Reyna said, “Following our testing, we knew Cisco Meraki would be easy to teach to our instructors, and the claims behind the technology lived up to its performance — both on the power side and the support side.” Cisco’s network came with a reputation of reliability, and therefore Reyna and Ben Ross, Network Director, decided to pilot some wireless solutions and quickly found that Cisco was easy to maneuver and competitively priced.
Since its deployment of Cisco Meraki Access Points and Cisco Catalyst Switching, Socorro ISD has experienced large gains in performance — both technically and academically. One of the main reasons Socorro ISD has experienced such success is due to the vision of district Superintendent José Espinoza. Espinoza encouraged the district to work closely with Reyna and the IT department, and vigorously campaigned for more funds to be poured into technology. As a result, Socorro ISD students are confident that they get an equal, even superior, global education. Socorro ISD will continue to leverage E-rate to support their digital learning initiatives.
For more success stories, ideas, and information, please click here to access last week’s blog in our E-rate series, and stay tuned for our final E-rate blog next week. Now is the time to think.. How are you leveraging E-rate to fund your digital learning initiatives?
Administrators can use now use Ansible as their common tool for configuration management, deployment, and orchestration of Cisco UCS standalone rack servers and Cisco Nexus. Ansible can help you set up infrastructure quickly and easily. Continue reading “Extending Ansible Automation to Cisco UCS and Nexus”
Today, technology solutions are addressing the world’s most challenging problems. The medibus, Germany’s first vaccine vehicle, is one of those solutions.
It’s making life-changing impact on healthcare in rural communities that need it most.
Since launching last year, a medibus is in use 6 days a week to deliver health services to rural regions and underserved populations in Germany. Recently, an elderly woman living in a small remote village and challenged with her ability to travel for healthcare needs received treatment for chronic diseases from arthritis to diabetes. Lacking a permanent local option, and if not for the medibus, this woman would’ve likely had to leave her family and relocate to an assistance home in the city.
Another larger version of the bus (pictured above) was presented both as VR model and in-person at Cisco Live Berlin this year. It is currently used by the Berlin medical center Charité for a huge vaccination campaign. Within a just a few months, many thousands of patients have been examined and vaccinated in the mobile medical office.
Across the globe, we are seeing large population and demographic shifts that increasingly affect how medical professionals deliver imperative services. To address the challenge of bringing care to remote regions, Cisco, Deutsche Bahn, and Charité and SAVD teamed up to convert former Deutsche Bahn vehicles into fully-equipped mobile care facilities. With the vehicles, general health care, specialist medical care, occupational examinations, and health information events are possible.
Plus, with Cisco technology, live video translation can be established, which allows patient communication in all relevant languages, without having to have a multitude of interpreters on site.
With the medibus, care is no longer time or place dependent. Specialists and experts are made available to patients through video conferencing, and with the mobility of a care vehicle, health services are now accessible to everyone, regardless of their physical location.
And the opportunities for transformation with this concept don’t stop at health care. The bus could be used for a variety of innovative purposes in government, education and citizen services.
To learn more about the medibus, check out the video below, or follow along with @CiscoHealth for more updates.
Cisco Spark Board just won Red Dot’s Best of the Best Award for “extraordinary, innovative design.” This is one of the world’s top design honors, and I could not be more proud of our team. Cisco won four more Red Dot Awards today, for Cisco Spark Room Kit and other tech components from the Cisco Spark family
Companies like CoBuilder, and Signa are telling us that the Cisco Spark Board has transformed the way their teams work together, and I know of two companies that have bought more than 80 Cisco Spark Boards a piece for a single office space. Verizon has called Cisco Spark Board the “next evolution in cloud-based collaboration” and plans to roll them out to customers and employees worldwide.
Frankly, this is the real reward — people love this product.
We built Cisco Spark Board to radically improve what is an often miserable business process: holding a meeting. The Cisco Spark Board is a simple, all-in-one display that works as an electronic whiteboard, a wireless presentation screen, and a video-conferencing system. Like many great industrial design achievements, it’s simple on the surface, with a lot of innovation under the skin. That’s what it takes to turn the too-often painful meeting experience into a magical one. Cisco Spark Board was chosen among the 5,500 Red Dot entries and is validation of how hard we worked toward that goal.
Taking the Panic out of Meetings
When we first sat down to plan how we wanted the product to feel, it was the stressed-out team member who has to run their team meeting that we were thinking about — not the IT manager who installed the product. We wanted anyone to be able to walk into a room with a Cisco Spark Board, and having never used it before, immediately know which icons to touch on the screen, quickly conference in other attendees, and share their computer screen – in 90 seconds, tops. Without help or support from IT.
Nobody is happy when a meeting can’t start because someone has to spend 20 minutes getting the screen-sharing or conferencing set up. We set out to fix that. And we did.
People entering the workforce today also should expect that their work communication tools are easy to use and empowering – as much as the social tools they use with their friends and family.
And we wanted the Cisco Spark Board to keep getting better, for everyone. We made it self-updating, like Teslas and iPhones, so we could keep it current as we learned more about what people were doing with it. Today’s workers expect this, and rightfully so. The era of static products is ending.
For us, all these changes from our standard product development model meant building a meeting-room technology platform from scratch – hardware, applications, cameras, the stylus, the operating system, everything. Even the sales model and pricing structure.
We took a big risk with this approach. One of the biggest was the integration challenge (some would say outright competition) with our existing product lines that have happy users and robust sales pipelines already. At Cisco, we’re accustomed to supporting multiple generations of products, and we’ve lived through several technological tectonic shifts. Even so, the Cisco Spark Board would be radically new and different for us.
That meant we needed a new kind of team. I have learned the hard way that how you build a design team is the most important part of making a breakthrough product.
Shipping the Org Chart
Cisco is a huge company with tens of thousands skilled and devoted people. But we didn’t want to put our standard corporate team on this project, even though we had all these great resources at hand. Single-purpose teams are faster and more nimble.
Products tend to reflect their creators. If you have a complex, bureaucratic development structure, it is easy to build a product that mirrors that. And we wanted the product to work for small teams. That meant we needed a small group to create it.
So we did ship the org chart. But it was a great org chart, because we built it from scratch.
A select team of people, from across Cisco’s disciplines, came up with its own ways to build a meeting room product focused on the end user first. That might not sound revolutionary today, when consumer products are infiltrating the enterprise, but Cisco’s traditional customers have always been IT professionals, not end users.
The team built the Cisco Spark Board with the idea that we would “sell” it to the end user office worker, even though it was Cisco’s paying customers, IT teams, who would actually buy it. (That said, IT requirements, like industry-leading security, performance, and manageability were table stakes for the product. This is Cisco, after all.)
The design and development team, physically separated from the bulk of the company, built a new industrial design, a new software architecture, and new low-level code and apps to bring it all together. And did it in a fraction of the time a ground-up project would take using our standard process. If you want a small team to succeed, you absolutely must reduce dependencies on larger teams with different goals. It’s not that established teams can’t be good, it’s just that they often serve different masters.
The entire Cisco Spark project, including the Cisco Spark messaging app, the Cisco Spark Board, and more products to come, is our offering to the millions of workers that don’t have the advantage of a company-supported modern communication system, and those that have to use conference rooms that have technology from the 1980s, if they have any at all.
The Red Dot Award we won for this product isn’t just a validation of the Cisco Spark Board’s beautifully-designed hardware and its magical ease of use – it is also recognizing that for us, great design came from a great team and great teamwork. Getting that right is the best way to get products that work, look amazing, and are fun to use. And we’re just getting started.
I highly encourage you to view this interview with Cisco Spark Board’s lead designer, Torkel Mellingen. It’s an awesome insider’s view of the design process and this team that I’m so proud to lead.
Today feels like what it must be to be a race driver winning the Le Mans or an actor winning the Oscars. As a product designer, it’s an amazing feeling to be awarded “Best of the Best” Red Dot Design Award. No doubt it is a privilege to win this award, but like the race driver at Le Mans, it can’t be done without the team.
The team that developed Cisco Spark Board dared to challenge the norm and to strive to make it almost embarrassingly simple. Most importantly, the team stayed true to the product vision.
We started thinking about how people have changed the way they work, while most meeting rooms haven’t. We looked at the tools people enjoy in their personal lives, such as mobiles and tablets, and we questioned why the enterprise hadn’t yet caught up. Most meeting rooms feel like boxes of disconnected tools that delay meetings and often make it unnecessarily difficult to get things done. And we thought it was just as important to incorporate that people are increasingly working in teams, yet our personal devices are designed for individual use.
So we created a team tablet for the wall. The Cisco Spark Board has the three most important capabilities teams need when they meet:
Our user experience and industrial designers worked side-by-side with a shared vision for humanizing technology. From the beginning, the design team was determined to take things out of the room. We partnered with the engineering teams to integrate all hardware into the board (including speakers and microphones), to remove the cables, and to hide the camera. We also gave the Cisco Spark Board a “home button” and three large app-like circles on the main screen, so everyone instantly knows how to use it.
Red Dot just recognized the Cisco Spark Board product design with its “Best of the Best” Red Dot award. We made a leap from complex to simple. To me, the award from Red Dot acknowledges that we landed in just the right place. It feels amazing.
Cisco Collaboration also won four other Red Dot Awards this year for the recently announced Cisco Spark Room Kit and other parts of the Cisco Spark family.
A few weeks ago, Talos published research on a Korean MalDoc. As we previously discussed this actor is quick to cover their tracks and very quickly cleaned up their compromised hosts. We believe the compromised infrastructure was live for a mere matter of hours during any campaign. We identified a new campaign, again leveraging a malicious Hangul Word Processor (HWP) document. After analyzing the final payload, we determined the winner was… a Remote Administration Tool, which we have named ROKRAT.
Packet capture has long been used by network operators, but a variety of challenges have limited its effectiveness in security and threat detection. In large networks, packet capture can collect terabytes of packet data, and sifting through that data for evidence of an intrusion can take a long time.
Traditionally, investigators used broad packet capture to support their investigations. They would capture everything at various points in the network. When investigating potential incidents analysts would search these captured packets looking for key IP addresses. When they had a reduced subset of the packet data they would use scripts that used the data to recreate a timeline that shows what a device and an IP address communicated with over time. From this timeline analysis the analyst could locate specific suspect exchanges and extract just those packets. This extract often returned a large number of packets, forcing investigators to spend hours searching the packets and their payloads for data relevant to the security incident. This slowed down investigations, incident response, and ultimately, the time to resolve an incident.
To address this problem, we explored using different technologies to accelerate incident response. We started by looking at incident response workflows using NetFlow and packet capture in concert. We quickly realized that IT professionals could begin their investigations using NetFlow, which is a more lightweight form of network telemetry, to identify the exact flows associated with suspicious activity. Then, using the exact time, sender, receiver, and port involved in the flow, they can create a highly targeted packet capture query that returns fewer, but higher value packets.
Together, NetFlow and packet analysis allows investigators to be quicker, more agile, and more responsive to threat activity.
Quicker Investigations
There are key differences between NetFlow and packet analysis. NetFlow contains network traffic metadata, which includes aspects such as time, date, IP addresses, port number, etc. Packet capture retains the packet payload, including user and application information.
For example, an employee attempts to look up their time card through a web application hosted on a company server. That application might make a query to a database of employee information on another server. If the employee wants to look at their pay stub, that may involve a query to the payroll provider’s data center across a virtual private network (VPN).
Reconstructing these events through packet analysis requires a lengthy query that may return thousands of packet files that the investigator must then sift through.
With NetFlow, this is a speedy query that provides you with the “who” and “when” of all of the network transactions involving the target machine. But sometimes more granular insight – the “what” – is needed.
This is where packet capture shines. While NetFlow can help specify the time frame or who was involved, packet capture provides the details of a conversation. And with the added information provided from NetFlow analysis, we can craft a more precise packet capture query to reduce investigation times.
Instead of a broad query – such as retrieving every packet a specific machine sent or received on a given day – we can narrow down the time frame and port number. This returns fewer packets that are more relevant to the investigation, which can reduce an hours-long investigation to a few minutes.
Intelligent packet capture with the Cisco Security Packet Analyzer
Unrefined, large-scale packet capture is the quintessential Big Data problem. It has all of the data, but it takes time and resources to find the right information. By narrowing the scope of packet capture by performing timeline analysis with NetFlow and Stealthwatch, many of the challenges of packet capture can be reduced or removed entirely.
The integration of Cisco Stealthwatch and the Cisco Security Packet Analyzer brings together the best aspects of both NetFlow and packet analysis. Using NetFlow and packet analysis together allows organizations to:
Accelerate incident investigations by quickly locating and analyzing the data around a specific security event
Obtain deeper visibility into packet data to obtain greater context around an incident
Investigate incidents based on device, user, and application instead of reconstruction based on all the packets that traverse the network
Retain pertinent data to examine the exact sequence of events in an investigation
Like other packet solutions, the Security Packet Analyzer collects a rolling buffer of full packet capture, but where it stands out is how it works with NetFlow solutions. When an investigator uncovers a suspicious flow with Cisco Stealthwatch, an enterprise-proven visibility and threat detection solution, using NetFlow, they can click a button to run a targeted query in the Security Packet Analyzer. This query contains all of the parameters of the NetFlow record, ensuring the quickest and most specific query is used. In addition, this query is run simultaneously on all Security Packet Analyzer deployments, and once the packets in question are found, the remaining queries are terminated.
By combining NetFlow’s broad scope and quick investigation capabilities with the in-depth information provided by packet capture, the Security Packet Analyzer shortens investigation times from hours or days to just minutes. Furthermore, the accurate and timely alerts provided by Stealthwatch’s NetFlow analysis allows for the targeted storage of relevant packet capture data, preventing the loss of important information.
Contributions to this post are also made by Jon-Paul Pritchard, Head of Executive Staffing in the Asia Pacific Japan and China (APJC) region.
This week, I and my Cisco colleague Jon-Paul Pritchard will be driving a TUK TUK – which is a small three-wheeled rickshaw-type buggy/taxi – with only 7 horsepower (equivalent to an average lawnmower) 3000km across India. We are on our own, with no support crew. We have only our wits to get us through (oh dear!)
We will be navigating through treacherous roads and vast uninhabited mountain ranges and countryside. The journey takes about 2-weeks (thank you to Cisco for the 5 days off to give back that we will each be using), however we will keep you updated as we go with emailed updates to this blog post. (Editor’s note: Check back each day!)
Why are we doing this? Well, one, it’s fun. And two, to raise money for some charities.
You see, last year one of my team Leaders sadly lost her husband to cancer. The charity she and her family supported was Doctors without Borders, or internationally known as Medecins Sans Frontieres. This organization does incredible work in providing urgently needed medical treatment to the those that need it most. Even the smallest donations will save the lives of adults, children & babies, as the most basic infections and illnesses in the developed world can be fatal to the world’s under-developed populations.
We hope you enjoy (and are entertained by) our adventures and updates from our race across India.
UPDATES:
__________________________
Update from the road, sent in on April 7, 2017. A recap of the first few days.
This is us (Kevin and JP) getting ready to start our tuk tuk adventure!
We arrived in Jaisalmer, a truly beautiful place. On a arrival at we met another “tuking” team in the baggage areaand we shared our taxi with them. Our first 5 hours seemed crazy, dodging cows blocking the road and dealing with the unpredictable traffic. After watching a sunset, we headed off to to find our Tuk-Tuk and become acquainted.
Sharing a cab with a fellow team!
We spent the next morning learning how to maintain, fix, and fuel the thing before getting our hands on the keys and heading out on the dusty test track for some maneuvers. Deciding that the cushions weren’t quite cushiony enough we upgraded to a luscious fabric number that wouldn’t look out of place in the 1970’s; a few more stickers and some new handlebar grips and it looks a million bucks! We were assisted in our endeavors by a friendly Tuk Tuk driver and his mate who between them seemed to know everyone and was able to get us anything. He also helped us get costumes for the “commencement of the race” Adventurist party.
Kick off party costumes!
When we checked out our house to head off on our adventures, I left our hosts/owners with a couple of Liverpool signs for their reception but the owner was obsessed about me giving him one of my Cisco t shirts. These were designed for us and are the best in this kind of heat, and I couldn’t part with it, but he settled for a hoodie. Maybe I’ll send him one when we get back.
The parade ground at the palace where the race would start was rocking and everyone keen to get on their way, drums banging, honking and generally a carnival atmosphere. We rocked up and shot off, going the wrong way! What we hadn’t planned for day 1 was our way out of the city.
We corrected our path and we were on our way towards Barmar. We drove the tuk tuk for the next several hours in the baking hot sun through nothing but desert with the occasional town, this was defiantly the most remote part of our journey it would seem.
On day two of driving we were a little more ambitious than day 1 as we knew we needed to be within spitting distance of Surat to give us hope of getting to Mumbai for our fourth leg. Along the way we passed deserts and trees, then more deserts and trees, than some more deserts and a few more trees (you get the picture) 350km of not much to see except sand and trees.
The further south we got the more life appeared and by the time we had blasted through Palanpur there were farms and farmland springing up left and right. Our diversity count grew as we saw camels and monkeys to add to the ever present cows and goats.
The little girl (our tuk tuk) is holding up well despite some random gear changing and a temperamental clutch. Seems second gear is a lottery while neutral is a mystery! Talking of the little girl we were thinking that she hasn’t been named yet so we wanted to see what you thought we can call her? Leave suggestions in the comments below!
Name our tuk tuk!
We also ended up driving in to a wall in the tuk tuk to avoid hitting a cow. Which if killed carries life imprisonment in Gujarat (I’m not kidding.) Not to mention that we were lucky we also didn’t hit the eight-foot tall giant stag that hurtled in front of us followed by the giant dogs that were chasing it.
We may have finally figured out the order of things on Indian roads: cows, buses, trucks, cars, motorbikes, goats, rickshaws (tuk’s), people and trucks going the wrong way. We also almost rolled our sweet baby tuk tuk… who knew joining a freeway, at speed, down a loose / fine sand dune was going to cause an issue with the steering ?!?!
For a while, we caught up and convoyed with the “Everything is Possible” after a hard trek over a mountain range, great They are a couple of guys from LA that work in the film industry and good lads too.
Convoy with another team.
We are turning in to the final half of the trip now. Our tuk is doing amazing and is holding together so well compared to others.
Don’t forget to leave comments with tuk tuk names below! More updates soon!
Lots of love.
JP n Kev
Update after the trip, sent in on April 26, 2017.
Perhaps we spoke too soon about our girl, as heading through the mountain range took its toll. It was obvious she wasn’t right, down on power and struggling on the hills. We decided on a quick pit stop at a mechanic to give her the once over, and two hours later she had a new piston, new gear plates, new clutch cable and some running repairs on the exhaust. This work kept us sweet for around 150km before the bolt holding on the exhaust sheared off and she started sounding like a Formula One motor car. We limped along through the mountain passes scaring wildlife and deafening the locals.
We headed in to Goa, which has the most incredible drive views coming in from the North and we probably got to see sights your average Goa tourist would never get to see, which included three encounters with the police, they seem really professional in Goa and check all our documents. Everything’s in order, thank goodness.
We made a decision to take off from driving. The tuk was sounding terrible and we needed a rest. We’re not trying to actually win this race (not even sure if you ca !) but we wanted to get the hard yards done (mountains and deserts.) We needed a place to stay, and our only requirement at this point was that we wanted a pool. JP found a nice Hilton in Baja beach and we knew the guys from LA and Oz were heading to that area so we landed on that. As we both have Hilton accounts it made sense to book individually through our Apps. JP booked his, a little pricey but it looks nice so sod it.. next up I go to book, 3x the price … what ?!?! Seemingly JP had booked the last standard room and the only other room available was the best suite in the hotel! We couldn’t cancel JP’s room, so I got a night of luxury.
A party was planned in Goa for all the teams, and we arrived earlier than most with a few other teams, so we got a few days of R&R. The tuk needed it, too.
We then set off 70km down the coast to our next stop in the beautiful Palolem beach area. More police, more document checking. We get the opinion that there might be special incentives for finding someone without the right paperwork.
We were at this point looking at 170-200km days to make our target of Kochi by the night of April 13th. It seemed like a good idea to put a big dent in the distance left and set a target for Udupi which was about 250kms away in the next state after Goa which is Karnataka. Our only other experience of Karnataka is from visits to Cisco Bangalore so our viewpoint was a little distorted and expecting hustle and bustle of the major city. What we actually got on the coast road though was some of the most beautiful scenery we have ever seen, swapping jungle for beautiful bays and beaches. Although a long day it was a very enjoyable ride. And our tuk tuk is holding up nicely, no signs of fatigue.
Speaking of signs, we found a few on the road that we found quite funny. Wouldn’t you agree?
By now we were looking forward to the final few legs into the finish line, excited for a lay in, and ecstatic to know we will have made it!!
As we woke on the final morning of our adventure the sun was rising over the Arabian sea and we had around 40km to go to the finish line. We stayed the night in a beautiful beach-side villa with sea access and some of the nicest fresh seafood we had seen through the journey, although mixed with authentic Kerala heat it was a little spicy for some! As we drove out from the compound we were still sporting the hammer and sickle flag that we had purloined from a lamp-post on the way through a village, it is fair to say we weren’t entirely sure what it meant but we got some very welcoming cheers and claps from passers by. Only once we got to the finish did we learn more about the ruling political party and some of their less orthodox methods; still it all adds to the legend that was our rickshaw run.
They say the most likely time you will be involved in an accident is within 10km of your house, in our case it was within 10km of the finishing line. We took a typically risky overtaking maneuver and nearly ended up as the meat in a bus/car sandwich. The final day also included a brief ferry journey from the island of Vypin to Fort Kochi, and as we arrived at the ferry terminal it was clear we would be in for a bit of a wait as a throng of moped drivers and passengers swarmed the quayside waiting for the next boat to dock. As it happens we waited only an hour and decided that we would head to the finish line and see if there was anyone already there, if not we would stop and get some photos.
Driving into the parade ground it was all relatively quiet and there were a few shocked faces, it was 12pm on the 13th April and no other teams were even close to the finish line, surprisingly and totally by accident we had finished first!!
We had the best of plans to summarize our journey into a brilliantly written, Pulitzer-worthy last paragraph, but alas, we’ve given up on blogging for a bit. Suffice it to say, we had a great time, raised money for a great charity, used our Cisco paid time to volunteer and grew closer along the way. PS: We never were able to stop calling the tuk tuk “our girl” – so that’s her name!
“We adore chaos because we love to produce order.”
-M.C. Escher
“Alexa, turn on Apple TV”
“Alexa, turn on dining room lights”
“Alexa, play classical playlist from Spotify”
“Alexa, set the living room to 70 degrees”
Our household is definitely “Alexa”-enabled, but behind the scenes, of course, there’s Apple, Logitech Harmony, Philips Hue, WeMo, Spotify, and Nest. And I’m guessing I’m not alone in just such a setup. In fact, I’m probably on the conservative side when it comes to the number and variety of smart devices I’ve enabled. But here’s the thing…without something to coordinate it all together, what would my experience be like? Would I be so enamored by the connected home?
Don’t get me wrong. I love my Apple devices for what they provide. Similarly, I love my Philips Hue lights and WeMo switches. And so on. Each device provides me a specific function or experience I need/desire/fancy. But at the same time, each has its own configuration process. Its own app. Its own website for account management. So, if I had to go to four different apps, at least, in order to start watching a movie with optimal lighting and at a comfortable temperature, I might question if all that “chaos” was worth it.
In steps a device like Alexa…a solution to centrally interact and control all my devices. But it’s actually more than that. With something like IFTTT, I can now spread a level of intelligence across my connected home to automate processes, trigger on specific information, and so on. Some may find that intelligence in other options, like Samsung’s SmartThings. Regardless of the platform choice, this intelligence is where I see a parallel with today’s multicloud world. The need to bring order to the chaos we’ve inflicted upon ourselves.
Organizations today operate using many applications across many clouds and side by side with their on-premise IT environment. Each application, each cloud, or each application-cloud pair provides a specific critical function, or experience, for the organization. But at the same time, each has its own configuration process. Its own management interface. Its own performance SLAs and security requirements. Its own foundational technology. So once again, while I need all those individual services, at the end of the day, I still just want to watch a movie with optimal lighting and at a comfortable temperature.
So, like me and my connected home, organizations need intelligence that spans their multiple clouds and IT environment to make daily operations and new development easier and faster. Because at the end of their day, that intelligence enables organizations to meet stakeholder requirements with fast development and deployment, enhanced customer experience, efficient and secure operations, and quality performance. That kind of cloud intelligence can provide application management that crosses boundaries. Security for your users, data and apps that crosses boundaries. Visibility and insights that cross boundaries. Networking policies and enforcement that crosses boundaries.
Because without it, organizations would essentially be, turning on their WeMo switches with the WeMo App and their Phillips Hue lights with the Hue app. Turning up their temperature with the Nest app. And turning on their entertainment center with the Logitech Harmony app or remote…or worse, turning on their TV, amp, Apple TV, and setting the proper inputs with so many remotes that they already lost count. Like me, organizations need cloud intelligence, to provide the “order” that makes the overall experience well worth the “chaos.”
The team that developed 
