• A new digital assistant from Facebook seeks differentiation from Apple Siri, Google Now and others through combined human- and AI-informed actions.
• Likewise, IT buyers considering the application of AI within big data projects should invest in people who know both data and the business itself.
Tucked away within the original run of 60s television series Star Trek (the one with Kirk, Spock and crew), there’s a gem of an episode entitled “City on the Edge of Forever,” which was written by noted science fiction author Harlan Ellison. In that episode, the Enterprise stumbles upon a mysterious, powerful, perhaps even omnipotent machine of sorts called The Guardian of Forever. When Kirk innocently asks his colleagues what it is, the mysterious, mechanistic entity that has the power (as we later discover) to reveal earth’s living past replies:
“A question! Since before your sun burned hot in space and before your race was born, I have awaited a question.”
With Alphabet now holding the reins of Google, a more traditional, more focused vision should make products like Google Apps for Business more appropriate for the enterprise by introducing a more stable evolution of capabilities.
But, with a tighter focus within Google itself, will the industry lose out on what were frequently disruptive, sometimes crazy but quite often game-changing innovations from Google proper?
I’ve had some time to think about the recent corporate reorganization at the company formerly known as Google but now referred to as Alphabet, and while I was initially skeptical, I now truly believe that this move will make products like Google Apps for Business much more appealing to enterprise buyers. With high-value interests like Search, Android, YouTube, Apps, Maps, and Ads all housed within a single corporate entitle (Google), enterprises of all sizes (not just those within the long tail) will be able to look forward to many improvements such as a more consistent and transparent rate of innovation as well as improved cross product synergies… perhaps a [cough!] unified API. Continue reading “Google’s Alphabet Shakeup Is a Huge Improvement; I Don’t Like That”→
As teams become more geographically dispersed (and inclusive of customers, partners and external agencies), organizational requirements for ad-hoc meetings are increasing; consequently, this democratization of video is resulting in the redesign of the physical workspace.
To maximize productivity, small informal meeting places (known as “huddle rooms”) need to incorporate the right physical attributes (adaptable furniture, white boards, Internet access, power, etc.), hardware (screens, speaker phones, video cameras) and software.
It’s hard to deny that the modern workplace is changing. The place we work is more varied than it has ever been. We work in airport lounges, serviced offices, homes, customer sites and, of course, our offices. Offices, with their fixed spaces (such as large conferencing rooms and cube farms), oftentimes detract from a team’s ability to work productively. As the two biggest cost centers in most businesses are people and property, more forward-thinking organizations are starting to combine these two elements in a more strategic way to optimize both. Continue reading “No Access to the Executive Telepresence Suite? Try a Huddle Room Instead”→
Open source containers may actually live up to the hype of becoming a viable alternative technology for hosting distributed applications.
Docker’s container technology will only succeed if it continues to build out a similarly strengthened and reliable management framework equal or greater to that of existing application environments.
Many IT decisions for enterprises are heavily based on reliability. They have to be, because the typical enterprise customer doesn’t have the time, budget, staff, or patience to deal with the fiddly-bits of making a fledgling system run, especially if there’s a Tier 1 vendor solution already available that meets most of the criteria. This has always been the open source dilemma for enterprise IT managers; is it worth the risk of reaching for the shiny brass ring of low-cost open source software when it’s just as easy to stay safe on the vendor pony? Well, sometimes it is, and the brass ring of container technology is getting closer and closer at a surprising rate. Continue reading “Docker Takes the Next Big Step in Hardening Its Container Ecosystem”→
• The temptation to modify open source software outside of a project is often well intentioned but brings a number of significant drawbacks.
• If you’re in enterprise IT, don’t buy products based on open source projects like OpenDaylight without a guarantee that the vendor won’t fork the code in the future.
In a strong rope, lots of underlying threads share a heavy load in the very same way that strong ideas form a great movement. Over the last few weeks, I’ve picked up on a couple of threads that I believe need to be at the core of the Open Source SDN implementations to insure the strength it really needs. At the OpenDaylight Summit, I had a chance to speak with a number of vendors about the future of OpenDaylight (ODL) and my desire to see every vendor making a controller based on ODL commit to not make any changes to the distribution that doesn’t come from the project. In other words, don’t fork the code because doing so presents a number of deleterious issues such as:
• Changes from outside the project make it more difficult for vendors because those changes may conflict or introduce new bugs with the updated ODL code
• Increasing the time it takes import changes from ODL into the forked code due to increased testing and validation
• Impacting integration from other products due to unexpected changes to the controller behavior
• No improvements to the overall health or functionality of the OpenDaylight code if changes aren’t up-streamed.
Colin Dixon, Chair of OpenDaylight’s Technical Steering Committee and a Principal Engineer at Brocade; and Devlin Avery, also from Brocade, spoke at length in Best Practices and Pitfalls for Building Products Out of OpenDaylight about the discipline needed to not clone and fork the code base. Brocade is demonstrating leadership in SDN by making a public commitment to not fork the Open Daylight code at all. It’s tempting for vendors to make changes that they think can be reverted later, but in reality, doing so instills bad habits and complicates their software development lifecycle. Perhaps more importantly it will create problems as the project matures and software vendors try to maintain consistent code bases that diverge more and more. There is also no guarantee that products that integrate with ODL will work properly against a forked version.
So you’re thinking, “Well, that’s great Mike, but what can I do to change this?” The answer is to speak with your wallet. At F5’s Agility 2015 conference, General Colin Powell (Ret.) gave the keynote. He’s an entertaining speaker and draws on his experience in the military and government work. Midway through his keynote, he expressed his frustration with the gridlock in Congress and made a pointed statement that while Congress is dysfunctional, it is we, the voting public, who put our representatives there, and we can vote them out as well. Changing Congress is hard, but this principle is actually easier to implement for enterprise IT.
When it comes to support for standards and open source software, you “vote” with your wallet. I don’t think there are many networking professionals evaluating ODL today that really want to be locked into a particular vendor’s product line, but once you buy into a fork of an open source software project that’s exactly what you’ve done and you will may well have signed on to have fewer timely updates and far less seamless integration in the future. Trust me, you don’t want that. The solution is to tell your networking vendors that are shipping software based on open source software that you don’t want forked code; and if they can’t deliver project-consistent code, you’ll be shopping elsewhere.
• Future mobile acquisitions will be driven by pure plays involved with OSS ecosystems (e.g., HP/Stackato).
• Modern app developer shortage leads to less sophisticated toolsets aimed at helping traditional developers be productive in B2E app development.
Vendors of mobile app platforms and platform services are realizing an apparent shortage of mobile and cloud savvy developers. As a result, the industry can expect to see a number of initiatives and solutions rolling out over the next 12 months, based around mobile services, low-code, rapid app development tools, and open source code and toolsets.
A recap of recent events illustrating this growing trend (which were also covered by Current Analysis):