Let’s have a little fun today and look at how the cloud is being used in ways that some might consider, well, out of the ordinary. Sure, anyone can conjure up a cloud-based system for purchasing books online, but what about using the ol’ smartphone to manage cows down on the farm?
SCR Dairy began in 1980 making equipment for the dairy-farming industry, stuff like detachers and pulsators, whatever they are. Today, the company offers cloud-based mobile applications for herd management, improving successful pregnancy rates, health tracking, and more. The latest advancement from the Israeli company is a series of mobile apps to — and stop me if you’ve “herd” this before — “improve productivity, reduce costs, and gain more control.” Whatever the industry, this golden troika of goals never seems to change. The company’s tagline is “make every cow count.” Like you, I didn’t know they could.
ETWater, which previously talked to me about the IoT talent shortage, designs cloud-based IoT smart lawn irrigation systems. The Novato, Calif. company builds Wi-Fi controllers that manage the zones of lawn sprinkler systems. It uses an integration analytics engine to calculate when and how much to water, based on dozens of metrics pulled in via APIs from a variety of sources. These include weather, humidity, time of year and day, sun and wind conditions, sensor readings of soil moisture levels, and a whole lot more. If you manage golf courses or office parks, it’s a clever and welcome use of cloud computing and data integration. At home, I can just look out the window.
If you’ve ever stood in the produce section and asked yourself, “Gee, are we out of kohlrabi,” Samsung has you covered. The Korean industrial giant’s new line of Family Hub refrigerators are equipped with, count ’em, three cameras that take a photo each time you close the fridge or freezer door. Use your smartphone to pull up an image while you’re at the supermarket or on the way home from work. Isn’t this what the cloud is all about? It certainly gives lends a whole new meaning to your subject saying “cheese” as the pic is snapped. Perhaps Samsung could link the cameras to SCR Dairy so we can have fresh milk from the farm on auto-replenishment. And, at last, you’ll know for sure if the light really does go out when you shut the door.
Finally, there’s the concept of paying by the foot. Literally. If those $400 running shoes you covet are out of your budget, you might be able to sign up for a pay-as-you-go plan based on how many steps you take or miles you run. The same might be true for those outrageously expensive high-performance tires you’d like to put on the family chariot. We’re not quite there for these two yet, but microbilling based on usage is very real. Without the cloud and Wi-Fi to do periodic data uploads, none of this works.
Well, enough of the fun stuff. The point is that what we can do with technology is limited only by our collective imaginations. Otherwise, we might still be carrying boxes of tape cassettes or three-ring binders filled with CDs on our journeys.
What are the truly unusual cloud apps that you’ve worked on and what was it about the development process that you found irresistible? Share your stories with us; we’d like to hear from you.
SAP and Apple. Apple and SAP. A good partnership offers benefits to each party. And that’s exactly what’s happening here. Let’s not forget the key third party not mentioned — cloud applications developers. For developers everywhere, there’s a lot to like.
SAP gets a lot from this union, starting with an express lane to develop its own enterprise apps for the iOS platform, encompassing iPhone and iPad (and perhaps Macs if OS X should eventually be supplanted by iOS). SAP also gets under-the-hood access to Apple’s XCode and Swift languages, a nice pairing with SAP’s own HANA in-memory applications platform and the Fiori UX (user experience) design environment. The real prize, however, is that SAP gets access to the 10 million enthusiastic developers writing for and who have expertise in iOS. That’s a lot of developers with a lot of non-traditional ideas about what apps can do.
Sam Yen, SAP’s chief design officer, is excited about the possibilities. “We’re trying to take the enterprise experience to the next level and capitalize on people using apps on their iPhones at home and the user experience they enjoy from that,” he said. “With our Fiori efforts, we want to optimize for mobile scenarios.”
For its part, Apple gets access to SAP’s global enterprise customer base, currently around 310,000 and an army of applications developers 2.5 million strong. Many of those developers are expected to create a new generation of purpose-built, enterprise-class applications that leverage SAP’s database and server-side power. It’s a huge vote of confidence in iPad and iPhone, both of which have seen sales wane in recent times. If the consumer market for tablets is near the saturation point, that’s likely not so in the enterprise. If a large, multinational corporation is going to equip thousands of in-the-field employees with tablets running custom apps, this partnership (and the similar one Apple struck with IBM in Dec. 2015) may sway the choice among tablets running iOS, Android, or Windows.
But wait, there’s more — a new SDK and a training academy.
The two companies are creating a new SAP HANA Cloud Platform SDK exclusively for iOS. It should provide developers with the tools to build custom iOS apps for iPhone and iPad based on the SAP HANA Cloud Platform, SAP’s open platform as a service. Add to that a new SAP Fiori for iOS design language to create apps that, in Yen’s words “look beautiful.”
Finally, expect to see a new SAP Academy for iOS by year’s end to help train developers.
Analysts are bullish. The union is seen as benefiting both companies. Jeffrey Hammond, a Forrester Research vice president and principal analyst who serves development professionals, told me, “This is good news for SAP customers who have struggled through many incarnations of SAP’s mobile strategy.”
What do you think? If your business is an SAP customer, we’d sure like to get your opinion. There’s a comment box just below that’s waiting for your feedback.
Ride-hailing service Uber is in an über-snit about how a handful of Harvard Business School students are using its developer API in a price-comparison mobile app. Uber, whose own app rained unsympathetic digital disruption and life-altering upheaval upon the taxi and limousine industry, apparently can’t take a dose of its own medicine.
According to the Boston Globe, an app called urbanhail ingests Uber pricing data via Uber’s API. As urbanhail puts it, “urbanhail gives you all of your ridesharing and taxi options in one click to help you save time and money.” The app currently serves only Boston.
From where I sit, this doesn’t seem any different than Kayak, Expedia, Travelocity, or even Google’s own useful ITA Matrix Airfare Search looking for favorable pricing among airline carriers. There’s also no shortage of apps that compare prices at my local supermarkets or tell me which gas station is the best bargain.
Is Uber right in prohibiting its API (and data accessed therefrom) from being used in a competitive manner? Should developers be allowed to access all of the data but only some of the time?
Clearly, there are legal and social issues involved. Uber certainly owns its own data and has every right to restrict its usage. Yet, this is a public API. Uber is not a federally regulated industry like air travel. And while Expedia, Travelocity, and dozens of other similar services are used for actually booking transportation and purchasing tickets, that’s not the case with urbanhail. The urbanhail app is merely informational.
So, what can’t you do with the Uber API? Let’s hail a ride to the Uber developer portal and find out! You cannot “compete with Uber.” You can’t “aggregate Uber with competitors.” Nor can you “store or aggregate Uber’s data, except as expressly permitted by Uber.” There’s also “You may not use the Uber API, Uber API Materials, or Uber Data in any manner that is competitive to Uber or the Uber Services, including, without limitation, in connection with any application, website or other product or service that also includes, features, endorses, or otherwise supports in any way a third party that provides services competitive to Uber’s products and services, as determined in our sole discretion.”
What’s your experience in using an API whose usage terms seem one-sided? Did you ever choose not to use a particular API because you couldn’t live within its terms? Perhaps your company publishes an API for use by others. Are its usage terms helping to broaden its use, or to restrict it? Share your thoughts; we’d like to hear from you.
Like it or not, no-code and low-code (I dub thee NCLC) application-development tools that allow line-of-business departments to navigate around IT’s army of highly trained, expert analysts and coders are not going away. It’s time to face reality.
According to a brand new study published today (May 2, 2016) by research house Vanson Bourne, The NCLC movement continues to gain traction. Among its key findings, the study notes that “63% of line-of-business respondents report that their department has either deployed, or considered initiating, application projects without the knowledge of the IT department.”
Now there’s a dose of new reality.
Just last week, Microsoft ended the private beta period for its PowerApps platform, opening up the NCLC tool as an unrestricted beta to anyone who wants to try it. Prominently displayed on the PowerApps website is a potent tagline: “Connect the things you already have, build apps without writing code, publish and use on Web and mobile.” Among the services to which you can connect are Salesforce, Dynamics CRM, Dropbox, Slack, Twitter, and Azure. And for the true evil scientists who really want to stick it to IT, custom APIs also make the cut.
“Power to the people,” is not just a cultural touchstone of the 1960s, it is the reality of our software as a service, mobile computing, distributed way of digital life.
PowerApps joins a long list of NCLC tools already widely available, but slapping the Microsoft name on something so potentially potent provides an enormous vote of validation for the technology. The CEO can finally go to the CIO and ask, “What about this?”
And there’s the rub. NCLC tools can benefit IT, or they can hurt. OK, Mr. or Ms. CIO, how do you plan to deal with it?
Ignore it. Woe unto you should you choose this strategy. NCLC is here to stay. You just can’t be seen as sticking your head in the sand. You can’t decree that all development must occur under the auspices of IT. You’ll be viewed as obstructionist, recalcitrant, and behind the times. You’ll be seen as an old-school CIO thinking in old-school terms. (Hint: You may already be viewed that way).
Ignore, but remain aware. That’s a half-step better. Departmental app builders are going to build apps. If you choose to consider those apps as a department’s illegitimate spawn, at least you should know what they’re doing and accessing. Stay wary, stay leery.
Acknowledge, but provide no aid. Admit it, denial is futile. Move beyond willful blindness. Sure, you’ll be secretly happy when an NCLC practitioner hangs himself or herself. Try not to rub your hands together too gleefully as you ride in on your white horse to rescue the project.
Embrace and be loved. Choosing to set people and departments up for success will win you friends and respect. When you admit that IT hasn’t the time nor budget (nor inclination?) to do a particular project, and follow that with support for a particular NCLC tool and maybe a written set of best-practices recommendations, you’ll rightfully be seen as a forward thinker that allows departments to react at the speed of business. Among the users of PowerApps that Microsoft is touting are Bose and Xerox. Clearly they’re on board with the concept of NCLC.
As an old-timer who grew up writing code in an MIS environment that wielded vise-grip total control over every aspect of apps and data, I admit embracing NCLC isn’t easy. But, it’s necessary. “Power to the people,” is not just a cultural touchstone of the 1960s, it is the reality of our software as a service, mobile computing, distributed way of digital life.
What’s your opinion of NCLC development tools empowering line-of-business departments? What do you see as the ramifications? Tell us, we’d like to hear from you.
Just a few days ago, In advance of a Gartner conference that’s slated for Sydney, Australia in May, Gartner research director Michael Warrilow, who is based in Australia, made a statement about the business of the cloud that is certain to trigger many discussions. Targeting his statements for that geography, Warrilow said that businesses are “too enthusiastic about cloud.” Though his geographical purview is limited, it’s reasonable to extrapolate his opinion to the wider global landscape.
“Some [businesses] are making dangerous assumptions that [the cloud] will always save them money, which it’s not necessarily going to do. What they will get is more agility and a different mix of capex and opex, which the business likes,” he said.
Mr. Warrilow is right, of course. Where I differ somewhat is that I don’t see some as “too enthusiastic,” but, rather, as enthusiastic for the wrong reason.
If a company is looking to cut costs, there are much easier ways to do it than launching the entirety of IT into the cloud. I’d start by dealing with output — how many printers are installed, which can be eliminated and replaced with a single departmental printer, duplex printing to halve paper consumption, outsourcing oversight and maintenance to a managed print services provider, just-in-time automatic toner cartridge replenishment to avoid hoarding, and so on. Follow that with imaging technology to eliminate most printing in the first place, and you’re saving serious money. It’s low-hanging fruit and it’s comparatively easy to do.
Cloud computing is a means to an end, not a business strategy unto itself.
I do not subscribe to the idea that cutting costs should be the primary reason for moving to the cloud. Cloud computing is a means to an end, not a business strategy unto itself. You embrace the cloud because you can deliver more services and better information to customers and employees more quickly. That leads to (in theory, anyway) more sales, greater revenue, and enhanced profitability.
If you’re reading this, you probably earn your living thanks to cloud computing. Without a doubt, cloud technology — and the cloud industry — have rocked IT to its very core and changed the way nearly every company on the planet conducts business. The allure of the cloud can’t be argued: More services, better security, increasingly powerful development tools, instant spin-up of resources, and plummeting prices combine to make the cloud, well, simply irresistible.
We’ve matured from years ago when applications that were the easiest to move into the cloud got the call, regardless of their impact upon or importance to the business. Today, the focus is rightfully on the applications that make the most business sense.
Do you agree? Is your organization’s reason for embracing the cloud to save money, or to improve the way in which it operates? Share your opinions; we’d like to hear from you.
What do developers worry about when creating an application? Performance. Data validation. Correct logic and processing. Memory use. Concise code. What they tend not to concern themselves with is cost. Perhaps that needs to change.
In doing research for a story on containers as a service (CaaS), both users I interviewed railed on the topic of license costs, at least as it pertains to Microsoft SQL Server. Both make a good case for paying close attention to how many instances of SQL Server are running, the number of servers on which they run, and, especially the proliferation of home-grown or purchased applications that expect their own personal instance of SQL Server.
The first hint of this came from Don Boxley, CEO of DH2i, a Fort Collins, Colorado company that makes SQL Server containerization software, primarily to endow databases with portability for easy movement from a development environment to production or from one cloud provider to another. Being able to stack containers on physical or virtual machines contributes to cost savings, he explained.
Well, that’s fine when a vendor pitching a product floats the idea, but how does this work out in the real world, in real businesses, with real applications? Turns out it’s a big deal.
Michael York, a systems engineer at Asante, a major regional healthcare system in Oregon, lives with the realities every day. “We have nearly 100 applications that have a SQL Server back end,” he told me. Most were purchased apps that stipulated a dedicated instance of SQL Server as a requirement. Add an app here and another there, and pretty soon you’re suffering from what York characterized as database sprawl. “It’s easy to stand up another instance,” he said. Getting the job done was the developer’s primary concern, not licensure costs. Running one instance per server sped development. Developers, he said, were often not even aware that instances could be stacked.
Through containerization, stacking instances, and de-provisioning of instances that were unnecessary, Asante saved more than $200,000 in 2015.
Tammy Lawson, a database administrator at Sonoco, the South Carolina global product-packaging giant (containers of a different sort), laid it out in very precise terms: “If each of my 61 container SQL instances were on its own server, the SQL Standard license for each server would be around $16K (using 2×8 AMD processors in my calculation since that is what my [DH2i] DxEnterprise physical servers are). That is a total of $976,000 just for Standard licenses. Buying SQL for my 4 Dx cluster nodes ($65K) + the DxEnterprise software came nowhere close to this number. Big savings in the licensing department.” Miss Lawson knows her stuff.
While it’s eminently clear that performance matters most, how much you spend year after year is important, too, especially if much of that spending could be avoided. If you properly stack instances on servers to mix and match database demand for the greatest efficiency, containers can save huge amounts of money. Developers need to know.
What strategies does your organization use to minimize licensure and maintenance fees? Share your ideas; we’d like to hear from you.
Chrysler killed off Plymouth. GM did it to Oldsmobile and Pontiac. Ford did it to Mercury. Microsoft even did it to Windows XP. Yet today, years after the demise of these products, they all continue to run. For the vehicles, parts remain available and dealers are happy to perform maintenance and take your money. Even for XP, Microsoft still issues the occasional security patch. Elsewhere, ink cartridges continue to be available for Epson inkjet printers discontinued long ago.
So, what’s the problem with the Internet of Things?
Consider Nest’s decision to kill off its $299 Revolv home-automation hub. Revolv (the company) was acquired by Nest in October 2014, which immediately stopped selling Revolv (the product). The service stayed up, however. Not for much longer. “As of May 15, 2016, your Revolv hub and app will no longer work,” states a message on the Revolv website from its founders. “The Revolv app won’t open and the hub won’t work.” Tough luck, buddy. And not exactly a PR-friendly warm and fuzzy writing style, either. (Nest itself had been snapped up by Google in January 2014.)
It’s reasonable to think that it was Revolv’s intellectual assets, especially its talented IoT developers, that Nest coveted. If you’re an IoT developer, or plan to become one, you should view the move as a signal that this is a great career path.
Initially, Nest (or Google or Alphabet) had no plans to compensate Revolv owners, but that now appears to be changing. In a statement provided to CNBC, a Nest spokesman said it will consider providing customers with compensation on a case-by-case basis. What form that compensation takes was not detailed. Either way, these customers are still left with nothing but a fancy paperweight. It’s the Abandonment of Things. Curiously, Google is refunding the full purchase price of its acquired Nik photo-editing software suite now that the company is making it free — and not shutting it down.
Do you think that’s fair? Shutting down the cloud component of your IoT product, turning faithful customers into orphans is a shameful business strategy. Can you imagine a maker of implantable cardiac pacemakers attempting a similar tactic? (Then again, no one jumped up to compensate me when it became impossible to buy blank VHS tapes for my VCR.)
I have an Acer laptop that’s nearly 20 years old. It runs Windows 95, still functions perfectly, and through an RS-232 serial-port powerline interface still runs an ancient version of the superb HomeSeer application, communicating with switch modules to control lighting in my home via the long-defunct X10 protocol. The laptop sits in a closet, out of sight, out of mind, plugged into a small UPS unit for power protection, and perfectly secure because it has no network connection. It’s all hilariously obsolete, but no one ever tried to shut any of these products down.
As developers, we understand that even the simplest of IoT products represents a significant investment. They contain embedded software to make the thing work, server side applications to process messages or send out alerts, databases for maintaining user accounts, iOS and Android mobile apps for controlling devices from your reclining chair, and more. There are license fees for software libraries, too.
I can understand the underlying economic reason for leaving the past behind, but in this connected age, before you arbitrarily put a bullet through your products and applications, you’d best provide a soft landing for the people who paid for the privilege of using them.
What do you think? Have you written code for products your company killed off, leaving customers with no escape route? Share your thoughts; we’d like to hear from you.
Last night, the FBI announced that it was dropping its litigation against Apple, because it had found an alternative way into the iPhone that had belonged to one of the San Bernardino terrorists. It proves, yet again, that nothing is ever completely, totally secure. Suing Apple simply became moot.
To the best of my knowledge, Apple never said that it couldn’t gain access to the phone, only that it wouldn’t. I’m not here to persecute or defend Apple, nor to debate the social or legal issues raised by the case. What I will do is opine about what we believe to be secure.
I’ve always likened device or application security to the idea of the scientific hypothesis. While it’s possible to absolutely prove a hypothesis to be false — all it takes is a single test case — you can never prove a hypothesis to be true. Every time you run a test that doesn’t destroy your hypothesis, all you’ve done is bolster support for it. But, you haven’t proved it true. Stop after a million tests that all support your hypothesis, and it still could be test 1,000,001, the one your imagination never conjured up, that smashes it to bits. You get the idea.
Testing for security is the same. In the digital realm, no matter how many times your security tests stand up to scrutiny, it just might be the very next one that lets the bad guys in. Who, after all, is the party that came forward to teach the FBI how to gain access to the infamous iPhone? Fortunately, this party was not a malicious hacker, but proved there was a way in, regardless of how secure Apple wanted us to believe the device was. (The data recovered from the phone still needs to be decrypted, but that’s separate from getting to the data.) Apple now vows to tighten security further.
One of the traditional arguments against cloud computing continues to be that some CIOs feel uncomfortable about security. Where are these cloud servers? Who is managing them? And wouldn’t 10,000 corporations virtually situated in the same gigantic physical datacenter be much more of a sitting duck target than a handful of servers buried deep in the bowels of 10,000 different corporate headquarters facilities? They’re all legitimate questions.
Cloud providers have the latest security technology and spend a whole lot more on security than any IT department ever could. They can hire experts that businesses can’t afford. They can hire experts that businesses can’t even find. It likely makes clouds much better at security than any business could do on its own, but absolutely, positively secure? In a word, no. After all, if security heavyweight RSA could itself be the victim of a huge breach in 2011, what does that mean for the rest of us?
Enough about the Apple case. Are you hypothesizing about the security of your systems, services, applications, and data? Sleeping well at night? Share your opinion — or your hypothesis; we’d like to hear from you.
As legacy applications from the on-premises datacenter are retired and replaced by cloud-based software-as-a-service subscriptions, those services need to be integrated. That’s the job of developers, armed with APIs and working under the aegis of the CIO. It’s all very tidy. But, what about integrating SaaS implementations that secretly came in through the back door without IT ever being aware? And what about when you find yourself in the crazy scenario of connecting a dozen instances of the very same SaaS?
It happens more often than you’d think, according to Liz Herbert, a vice president and principal analyst at Forrester Research. We’re all aware that different SaaS implementations, such as CRM, order fulfillment, payroll, inventory management, and others need to be integrated. That’s neither news nor fodder for an opinion column. Much more interesting is that we never think about is the need to integrate multiple copies of the same SaaS.
“In a large enterprise, it is not uncommon to have 12 instances of Salesforce that are unaware of each other, usually because each one was brought in separately under the radar,” Herbert observed. It’s yet another aspect of that phenomenon we’ve come to know as Shadow IT or Citizen IT.
It happens because line-of-business departments want to do their own thing and not wait for IT to work its way down a list of pending projects. It can happen because IT doesn’t have the budget. Or because there’s a roadblock with a legacy CIO who thinks in legacy terms. It can happen because a department manager gets wind of what a different department is doing, likes the idea, but goes with his or her personal twist.
Typically, these SaaS instances become known to IT months after they were initiated, when the department manager asks IT to take over management and administration. Whether they conform to the corporate policies on security or governance was never considered — until now.
To be fair, this is not always due to illicit SaaS sign-ups. A more above-board scenario is when businesses go on acquisition sprees and have to meld all the pieces into a unified whole. Though each might use the same payroll processing SaaS, it’s a good bet that no two implementations are identical. That’s more likely to become an official IT project even though the same-but-different integration issues persist.
Have you found yourself in the midst of integrating multiple copies of the same SaaS? If so, we’d like to hear about your adventures in the discussion thread. And remember, it’s not just your organization. When it comes to cloud computing, “I thought it was just us” simply doesn’t apply.
You’re a developer and darned proud of the code you write. You follow the specs and build what the stakeholders and designers want. You’ve tested it and all the test scenarios work as expected. You deploy and the app goes into the wild. But, what happens when there’s a problem that no one anticipated? Not you, not the app owner, not QA, not ops, not anyone.
After having a problem with my mobile phone, I visited the local store of the phone manufacturer, a giant company named for a fruit. None of the store’s so-called geniuses could figure out why the docs and data on my phone kept ballooning up to fill — and even attempt to exceed — the 128 GB device’s available memory. It turns out that this giant hardware company (or is it a software company) had no diagnostic software that could peek into the device and see what was suddenly occupying so much RAM, more than 23 GB. Manually adding up the data use reported by all the installed apps plus recently deleted photos still in RAM totaled less than 1 GB.
Multiple reboots did not help. The only alternative, they said, was a reset and restore from my last backup. After doing that, I attempted to re-add a credit card to the phone’s wallet. That resulted in a “card is already in wallet” error though it clearly was not. Multiple calls with said fruit company’s tech support experts (on my land line) could not solve the problem. Again, there was no way to peer into the phone to get a snapshot.
Four calls later, one young man in the fruit company’s Jacksonville, Fla. call center suggested the purely undocumented move of logging out of my cloud account associated with my phone then logging back in. Voila! I could now add my credit card. Why do this? He couldn’t say.
Why did the phone operating software and its wallet app behave in this manner? No one knows. Why did logging out and back in solve the problem? No one knows. Was that the cloud equivalent of a three-fingered Ctrl-Alt-Del forced-reboot salute? No one knows. With tens of millions of phones in use that support wallets and credit cards, why hadn’t this been seen before? Or if it had been, why wasn’t it documented? No one knows. Web searches did yielded some highly convoluted suggestions, though.
The innocent bystander in this are the developers who build software based on a set of specs. I’m not saying that the developers were surrounded by fools to the left and jokers to the right, but it’s clear that neither the specs nor the test scripts anticipated this situation. Perhaps this couldn’t have been imagined. It’s not like the famous spec failure that says how to process a payment if it’s received less than 29 or more than 29 days after the due date, but which fails to specify what to do if the payment is received exactly 29 days after the due date. That’s just bad design.
Burke Holland, director of developer relations at Progress Software, has reminded me more than once that great software isn’t finished until it’s fully tested. But, just as you can never prove that an app is completely secure, only that it is not secure, you can’t test for scenarios beyond your wildest imagination.
What really would have helped is powerful diagnostic software to do a RAM autopsy. It didn’t exist. And that makes me wonder what we should be doing in terms of creating diagnostics for the apps we build. Do you do that? Share your thoughts, we’d like to hear from you.