It’s easy to understand why the CFO likes cloud computing. It’s almost certainly less expensive than running a traditional IT organization and infrastructure.
Perhaps the HR manager likes the cloud, too. It means cutting payroll headcount and issuing fewer ID badges. The facilities manager probably adores the cloud. Fewer employees and a dismantled server infrastructure means lower electricity, lighting, and HVAC consumption. But, what to do with the recovered office space?
And what about end users? Should they like the cloud? I can argue they should not have an opinion either way. That’s because an app and its data should simply work and that whatever lies under the hood should not be visible or identifiable. When I log into my bank or into a retailer, I haven’t the slightest clue what’s in the cloud, whether it’s running on AWS or Azure, what’s on-premises, or anything else.
Developers, of course, are nearly universally for the cloud, though I’ve been told the top reason is one that might be a surprise. In a conversation yesterday with Dave Bartoletti, principal analyst at Forrester, he says the top reason is that the cloud lets developers develop faster. All the pieces are in place and there’s no internal red tape to conquer when asking for resources. “It’s the fastest way to get their job done,” he told me. There’s also the idea that with cloud expertise in uber-high demand, developer and architect salaries are being driven up.
CIOs lie somewhere in the middle. While they’re certain to be won over by lower costs and faster development cycles, there’s the opposing loss of control when their beloved on-premises infrastructure of long standing gets dismantled.
What about you? What is the one thing about the universe of cloud computing that you like above all others? What’s the one thing you dislike most? Share your thoughts, we’d like to hear from you.
With Oracle using this week’s JavaOne conference to reaffirm its commitment to the Java platform, third-party tool maker Azul Systems debuted an early access program for Java 9 support in Zulu, its open-source build of the Open Java Development Kit (OpenJDK).
Pre-release builds of Zulu supporting Java 9 are available now for the Windows, Linux, and Mac OS platforms. Azul, based in Sunnyvale, Calif., plans to introduce additional pre-release builds throughout the next year, keeping in cadence with OpenJDK Java 9 project advances.
Though the target launch date set by Oracle for Java 9 is still nearly a year away (Sept. 22, 2016), many key aspects are already public. A new modular architecture will let developers select only those features needed for a specific deployment, helpful when scaling down to small devices. Java 9 is also slated to provide improved run-time efficiency for stored class and resource files, faster graphics, a new HTTP client API, and improved keystore security.
In an earlier IT Knowledge Exchange blog post, I wrote about how Adobe, in an astonishingly poor effort to simplify, completely changed the import procedure in its Lightroom application, widely used by photographers. Photography forums went nuclear with rage and anger. In response, Adobe, in its Lightroom Journal advice blog, went so far as to issue an apology on Oct. 9, along with a promise to do better. It has.
Just one week later, on Oct. 16, in the same Lightroom Journal, Adobe’s Tom Hogarty said the company will restore the previous import experience in the next dot-release update. The blog post even provides a link to instructions for rolling back to a prior release for people who cannot wait.
Here’s why this is important. Lightroom does two primary things, non-destructive photo editing that logs every step in a permanent history, allowing users to roll back to any point; and digital asset management to keep track of every image. To do either, you first import the images into the Lightroom catalog, which is actually an SQLite database. What gets imported is not the actual image, but all of its metadata, including physical disc location. There’s also numerous options that can be selected at import time, much of which was eliminated in the simplification. The catalog is where the step-by-step editing history for each image resides, which can easily balloon the database to gigantic proportions. My own Lightroom catalog file currently encompasses 59,205 images of various file types (RAW camera, PSD Photoshop, TIFF, JPG, PNG, etc.) and is 5.3 GB in size. Though I keep several backups on various network drives and two NAS systems, the live working catalog must be stored locally. The actual image files can live anywhere and Lightroom dutifully keeps track.
Acknowledging that the ill-fated “simplified” (and I might add, positively awful) import dialog was sprung on users as a surprise, Mr. Hogarty writes, “We will continue to investigate ways to improve the ease of use of our photography products and will do so via an open dialog, with both existing and new customers.”
It’s good to see one of the world’s premier software companies admit it made a mistake. It’s even better to know that Adobe plans to fix it.
Has your company ever rolled out a software update or product that contained features reviled and rejected by users? What was done about it? Perhaps a rollback or maybe a decision to simply ignore the blowback and plow ahead. Share your thoughts, we’d like to hear from you.
Visit any of the TechTarget family of websites or e-publications and Big Data is everywhere. It’s unavoidable. Inescapable. IT isn’t about applications, it’s about the data. Think of all the things we do with big data: collect, validate, authenticate, store, de-dupe, access, secure, encrypt, back up, analyze, query, display, aggregate, report, purge, and integrate into applications. Data is so vital, countries and industrial spies steal it, and corporations sell it.
Sell it? Sure. Data has value. Big value. As a developer, the on-premises, cloud, and mobile apps you build are essentially refineries that transform the crude-oil-like raw ones and zeros of big data into information. Information, in turn becomes knowledge. Without developers, big data is like a tanker full of crude oil — pretty much useless, but packed with enormous economic value. And as we all know, economic value is power.
Who says so? IBM does. That’s why Big Blue is getting deeper into big data by agreeing to buy the digital business and data assets of Weather Co., corporate parent of the Weather Channel cable network and apps. According to the Wall Street Journal, the deal, which encompasses Weather’s website and app, digital intellectual property, infrastructure, and data, could be valued north of $2 billion. Weather information can be packaged and resold to a wide swath of industries, including airlines, truckers, agribusiness, insurance, electric utilities, pharmaceutical manufacturers, and more. The television network is not part of the package and will remain owned by owned by Comcast’s NBCUniversal, Blackstone Group, and Bain Capital, according to the Journal.
How big is Weather’s big data? According to CNBC, the Weather app ranks fourth on the list of mobile apps used daily in the United States. Weather fields an astounding 26 billion inquiries to its cloud-based services every day. And you think you’ve got performance and response-time issues?
There’s a link at the bottom of weather.com for the company’s API and documentation, which it calls “a Weather API designed for developers.” (For whom else would an API be designed?) Pricing is free for a maximum of 500 calls per day, and $200 monthly for up to 100,000 daily calls. Need to do millions of calls? There’s special pricing for that.
Clearly, big data isn’t worthless, it’s very valuable. But, without applications developers it sure is useless. That’s why all of Weather’s intellectual assets, which no doubt includes developers and the rest of IT, is part of the deal.
Finally, there’s that lingering question: Can your business’s databases handle 26 billion queries every day?
We all know that “things” of all kinds, limited only by your imagination, are already demanding all connectivity all the time. But, you ain’t seen nothin’ yet, if the predictions of those in the predicting business are accurate. Are your applications and the platforms they run on robust enough to handle the coming tsunami?
Research firm Gartner two weeks ago published its list of predictions for 2016. “By 2018, six billion connected things will be requesting support.” This is about tech support and also the need to think of devices as your customers. That means a steady flood of automated requests for data and the opposite — devices reporting their status. This isn’t just the “you’re gonna need a bigger boat” stuff of the movie Jaws, it’s about needing a battleship and a very agile one at that.
Juniper Research is even more aggressive with its IoT device projection. In a July 2015 report, the firm says “the number of IoT connected devices will number 38.5 billion in 2020, up from 13.4 billion in 2015.” That’s a jump of more than 285 percent. The report goes on to say that connected devices already exceeds the earth’s population by more than double. Yet, “for most enterprises, simply connecting their systems and devices remains the first priority.” One problem cited is conflicting standards.
It appears not to matter if the IoT devices your apps communicate with are consumer oriented (home automation, connected vehicles, healthcare, banking, etc.) or industrial (manufacturing floor, agriculture, power grids, smart office buildings, etc.) It’s a mashup we might as call “IoT Big Data.”
Even if your applications can handle the huge volumes and velocities of device-driven data, you still need powerful back ends to transform those ones and zeros into something useful. The Juniper report states the case well: ” Mere connections create data; however, this does not become information until it is gathered, analyzed and understood.” In other words, it’s not just device communications pipelines that need to be beefed up, it’s also the analytics standing in the background. Data, once it’s understood, is not just information, it’s knowledge.
Are your applications, storage systems, and analytics ready to handle the coming meteoric rise in connected devices? What is your organization doing to ensure capacity stays ahead of demand? Share your thoughts with your peers. We’d like to hear from you.
Application development isn’t easy. That’s why the profession of software engineering is so valued and why talented cloud and mobile app developers — like you — are continually sought after. That said, how do you feel after pouring your soul into a project, only to see it flop and get yanked mere months after its rollout?
The latest case is the shutdown this week of Amazon Destinations, the retail behemoth’s six month-old venture into hotel booking. A terse statement on the site says simply, “Effective October 13, Amazon Destinations stopped selling reservations on travel.amazon.com and the Amazon Local app. If you have a reservation, your reservation is valid and will be honored by the hotel. No action is required on your part.” That’s the entire statement.
Think about this for a moment. Technically, Amazon Destinations got the best of everything. It’s a darn good bet this product was running on Amazon Web Services and was developed, tested, and deployed using the very best of AWS’s own tools, perhaps even ones not available to typical AWS subscribers. You know the product was given oodles of compute resources and data-storage space. QA was, no doubt, top notch. Still, work needed to be done. Databases had to be built. Integration with external resources, such as databases of hotels and room availability had to be accessed and integrated. Queries, credit card transaction processing, logging, exception handlers, and user interfaces all had to be designed and built.
So, what went wrong? Perhaps Amazon’s effort was simply far too late to have any impact. There’s already tons of competition from dozens of dot coms, including Expedia, Hotels, Airbnb, Booking, Trivago, Kayak, Priceline, Hotwire, BookingBuddy, HotelBooking, and many more. I had heard almost nothing of Amazon Destinations, and I’m in the business of writing about such matters. According to Bloomberg Business, Amazon Destinations was launched in April 2015 in an effort to broaden the reach of its Amazon Local platform, which finds discounted, close-to-home shopping deals. Did you know that? I didn’t.
There’s also the growing problem of rogue booking websites and mobile apps that are out-and-out scams, according to a story published this week by NBC News. Amazon Destinations, of course, was most definitely not a scam, but it’s likely that once people find a travel site or app they trust, they’re going to stick with it. In other words, if you’re happy using Expedia, why switch?
As I’ve noted before, migrate a bad application from the on-premises data center into the cloud and you still have a bad application. That’s purely a technical design and coding failure. But, here, the problem is very different: starting out with a bad business concept. Even the best of developers would have no way of knowing. You get the specs and you code your heart out.
Building a great app doesn’t ensure that anyone will download it, or that it can be found at all.The challenge that extends well beyond the development process is making your app visible so that people want to download it. According to Nick
Nick Landry, a senior technical evangelist at Microsoft for all things mobile, if an app is not in the top 50 to top 100 across a category in an app store, the likelihood that it will ever be downloaded are very small, he says. Just 17% of independent developers generate no revenue from their apps, while another 18% make less than $100 a month, he added. Not very promising.
Has this happened to you, seeing an app withdrawn or service shut down soon after its launch? How did this impact you, after putting in a huge amount much work and many late nights? Share your experiences; we’d like to hear from you.
Today, let’s do something different. Instead of offering up my own opinions, I’ll let others hang themselves with their own words. Suffice it to say, test your software fully before shipping it out. These aren’t kids cloistered away in their bedrooms building apps for fun; these are commercial developers. Have comments on this? Well, sure you do — you’re a software developer, too. What do you think? Join the discussion; we’d like to hear from you.
Adobe royally messes up this week’s updates to Lightroom (desktop) and Lightroom CC (cloud).
In an effort to simplify the process of importing images from camera into the Lightroom database, well, it’s broken. Broken so badly the various photography forums are ablaze with anger. Today (Fri., Oct. 9, 2015), in the Adobe Lightroom Journal, branded as “tips and advice straight from the Lightroom team,” Adobe’s Tom Hogarty, writing on behalf of the Lightroom Management Team, falls on his sword:
Lightroom 6.2 Release Update and Apology
I’d like to personally apologize for the quality of the Lightroom 6.2 release we shipped on Monday. The team cares passionately about our product and our customers and we failed on multiple fronts with this release. In our efforts to simplify the import experience we introduced instability that resulted in a significant crashing bug. The scope of that bug was unclear and we made the incorrect decision to ship with the bug while we continued to search for a reproducible case(Reproducible cases are essential for allowing an engineer to solve a problem). The bug has been fixed and today’s update addresses the stability of Lightroom 6.
The simplification of the import experience was also handled poorly. Our customers, educators and research team have been clear on this topic: The import experience in Lightroom is daunting. It’s a step that every customer must successfully take in order to use the product and overwhelming customers with every option in a single screen was not a tenable path forward. We made decisions on sensible defaults and placed many of the controls behind a settings panel. At the same time we removed some of our very low usage features to further reduce complexity and improve quality. These changes were not communicated properly or openly before launch. Lightroom was created in 2006 via a 14 month public beta in a dialog with the photography community. In making these changes without a broader dialog I’ve failed the original core values of the product and the team.
The team will continue to work hard to earn your trust back in subsequent releases and I look forward to reigniting the type of dialog we started in 2006.
Epicurous, the foodie website, messes up its mobile apps beyond repair. The apps have to be completely withdrawn. Really.
Read portions of what Eric Gillin, executive director of Epicurious, writes on the Epicurious website on Tues., Oct. 6, 2015 (excerpted):
Important Announcement for All Epicurious App Users
If you’re using our app on Apple or Windows, it’s critical you upgrade it immediately. If you’re using it on another platform, sadly, we no longer support those apps. Read on for more information.
Effective immediately, our apps for Apple and Windows will no longer work unless you update them. On that same date, our apps for Android, Nook, and Kindle will stop working properly.
IF YOU USE THE EPICURIOUS APP ON APPLE OR WINDOWS TABLETS OR PHONES
You must update the Epicurious app. Upgrading your app is critical. It will no longer work properly if you remain on an older version. If you’re unable to install the update for some reason, you can still view our recipes — and your recipe box — right here on our website.
IF YOU’VE BEEN USING THE EPICURIOUS APP ON ANDROID, KINDLE, OR NOOK DEVICES
These apps will no longer work properly. Because we can no longer support these apps, we will be removing them from stores. We’ll be working to create new versions that include all of the functionality you’ve come to expect from us.
We’re deeply sorry if this causes frustration. We’re doing this because we want to make sure that we offer the best possible experience and sadly, it’s no longer possible for us to support older devices and every single platform.
Do I need to say anything else? What do you have to say?
You’d think we’re in a cycle where the number of cloud applications in enterprises is on a steady increase. I would have thought that, too. After all, the rush to decimate legacy IT has turned into something of a drag race. But, according to one study, we’d be wrong.
In its summer 2015 quarterly cloud report, the cloud-enablement firm Netskope reports that the average number of cloud apps used per enterprise declined for the first time. The company ascribes the decline to consolidation efforts from IT beginning to take hold.
To be a bit more specific, the report from the Los Altos, Calif. company notes the average number of apps used within enterprises declined from 730 in its first-quarter 2015 report to 715 in the second quarter. This marks the first time a decline has been seen, according to the company.
Why is this happening? The report says “enterprises are beginning to consolidate apps, especially those in the marketing, collaboration and productivity categories.”
That last statement suggests that enterprises are moving to a model of fewer, bigger, more-comprehensive apps that each do more. Call me naïve, but I would have thought it equally reasonable to go the other way — more apps that are each highly focused and specialized.
What is happening with the number of apps in your enterprise cloud? Which way should the enterprise app pendulum swing? Fewer apps that do more or more apps that specialize? It’s an intriguing topic for a lively discussion. Share your thoughts, we’d like to hear from you.
Let’s do some supposin’.
Suppose you work for a giant, global manufacturer. The company might make air conditioners. Or diesel-powered cars. Suppose you’re given detailed specifications for an embedded software project that disguises the operating status of a product being designed. Suppose the purpose of that application is to underreport the electricity consumed by that air conditioner.
Or — and this just might be the wackiest idea ever — suppose the purpose of the software is to surreptitiously shift a car’s diesel engine into a low-pollution “clean” mode while the engine is running and sensors detect that the steering wheel isn’t being moved and the wheels aren’t rotating. That would present artificially low levels of exhaust pollutants and particulates to environmental test equipment. I know, who could ever dream up such an outlandish, ridiculous scheme? It would be scandalous on an international level.
Here’s the tough question: What would you do if tasked with coding such a program?
You might keep your mouth shut, write the code, grin, and deposit your hefty paycheck. You might become a whistleblower and contact the authorities or the media. You might rationalize the situation and conclude you were just following orders. Perhaps your conscience might drive you to quit and find employment elsewhere. You might even write a time bomb into the code that prevents a car from shifting into low-pollution test mode. What would you do?
As a software developer, are you bothered by the premise of building apps designed to deceive? Have you ever been asked to this? Share your opinions, we’d like to hear from you.
Whatever language(s) you happen to use for coding applications and services, there’s no doubt that you are among the world’s best it. You’ve got the skill, the talent, the insight, and the brains to write efficient, compact code that runs flawlessly.
But, from what program specifications or documentation are you building these apps? Call me a mainframe-era dinosaur, but not a line of code written until at least two processes happened.
First, a business systems analyst interviewed stakeholders and translated their tales of woe into a clear, logical, unambiguous, easily followed set of requirements. That’s essential, because users rarely know what they want. (You agree with that, right?) When a department pleaded with IT (still called MIS in those days) for a new report, the savvy business analyst knew to look beyond the report request for fundamental process shortcomings. Generating a report, after all, is merely treating a symptom, not the underlying disease. It wasn’t unusual — at least if you were fortunate enough to have a really good analyst — for that one report request to eventually become a system that simultaneously solved a dozen seemingly unrelated problems.
Second, the business requirements document, following reviews, revisions, and sign-offs by all stakeholders — which magically transforms them into owners — was handed off to a systems analyst. It was this person’s job to translate the business requirements into a set of functional specifications, logical statements and if-then structures that programmers (not yet called developers) turned into actual program code.
Done right, this process, though glacially slow and deliberate, was often a thing of beauty, with buy-ins and approvals every step of the way. There could be no room for stakeholder/owners to complain that the delivered system was not what they wanted.
Today, things are very different. We don’t have months. New apps, systems, and user interfaces must be designed, built, tested, and deployed in a matter of weeks. Infrastructure is as much a part of system design as the software itself. Where everything once ran on machines somewhere down the hall, today, your apps run, well, somewhere. You’re calling on data from multiple sources, integrating data and processes on the fly, and delivering the results to potentially millions of devices owned by completely nameless, anonymous users.
That brings me back to the original question. When a project for a new application or system is dropped in your lap, what do you use as the specifications basis for writing code and designing an architecture? Does your organization have analysts who create detailed business and logical requirements? Are you instead saddled with this responsibility, and if so, do you know the business well enough to do a comprehensive job? Does someone have a chat with you over coffee and attempt to explain what he or she wants?
Share your experiences, good or bad, about defining app and systems requirements. We’d like to hear from you.