When someone using your mobile cloud app begins a transaction and communications is unexpectedly lost, what happens on both the device and server sides when that break is detected? And what actions follow when communications is restored, likely in a completely new session? These are important questions whether your app is operating in the financial, retail, or services industries.
This boils down to well-crafted specifications from a competent business systems analyst coded by an experienced developer in a clear, understandable way that holds up to extensive QA scenario testing and subsequent audit scrutiny. No one said it would be easy — that’s why up to 80% of the code in a typical application may be solely for exception handling.
It’s akin to a multiple-choice question with no right or wrong answer: cancel, complete, or suspend.
When a cloud session is interrupted, do you cancel an in-progress transaction? If yes, and that’s happening on the server side, you’ve got to do store-and-forward, eventually getting that cancellation to the mobile app to maintain end-to-end synchronization. Maybe your server side also needs to generate an e-mail or text message so the user knows what happened and what action ensued. Of course, no communications means the message might also be subject to delay. And, your app is logging all of this, right?
Perhaps, instead, the transaction gets processed and posted. If that’s the case, it might be happening without immediate confirmation to the user. Maybe that’s ok for a 99-cent music download, but, if the transaction is an application for a mortgage, for scheduling medical tests, purchasing airline tickets, or, to think more industrially, something that impacts a factory-floor production line, there’s much more at stake.
The third alternative is to suspend the transaction and wait for the user to re-appear under a new session ID, whereupon the transaction can presumably resume. This state that lies somewhere between cancel and complete may be the most complicated of all. Was the product deducted from the available inventory database? Was the payment portion transmitted to the third-party credit card processor? Was a pick ticket generated? There’s the issue of databases that may not know the correct record-locking states. And what if the user doesn’t re-appear within a specified time frame? It can get very messy very quickly.
Journaling and logging are essential components of any transaction-based system, but their true value may be more in post-mortem by a team of auditors than in dissecting the complexities and permutations of an interrupted event in real time. That was fine decades ago for nightly batch processing, but in today’s cloud age of expected instant results, users can’t — or won’t — wait.
Finally, there’s perception. Does the user blame the communications carrier or your app for the snafu? It takes only a moment for an angry customer to blast your app and company on social media, even though neither may be at fault.
What’s your philosophy when it comes to transactionus interruptus? What happens on your mobile app and on the server side? And how do you get the two sides back in sync? Tell us, we’d like to hear from you.
You’ve poured your heart and soul into a cloud-based mobile application development project. Thanks to APIs, Internet of Things, and the newest breed of development tools it works flawlessly and looks great. But, how do you react when the curtain is pulled back and the corporation behind your lovingly crafted app fails miserably in areas beyond your control, such as providing customer support?
When I recently needed to have a printer serviced, the first place I turned to for information was the company’s good-looking, well-regarded, easy-to-navigate mobile app. I’ve used it many times for accessing files residing on my home network’s NAS and printing them on printers connected either by Wi-Fi or an Ethernet cable. Works like a charm. The app can also query this manufacturer’s printers, report remaining levels of consumables, and even initiate an order to buy. Pretty handy and darn clever.
Not only is the app a nicely designed and implemented bit of software, it’s essentially the public face of this vendor. Your app should be no different.
Unfortunately, the app was useless for finding a local repair depot. Even worse, the company’s website was no better. The dropdowns where I selected my printer type (color laser) and model were confusing and obscured the map. And it not could find anyplace that could repair my product, just four years old. Pretty darn pathetic. As a last resort, I called the displayed phone number. After 22 minutes, most of which I was kept on hold, a “nearby” repair depot was found. In Arizona. I live in Boston.
My point is that there’s more to a company than the image of its online presence. You can build gorgeous apps that work beautifully. Your IT department can be behind you all the way. You can have at your disposal the latest tools for development, quality assurance, and deployment. Development might even occur on a robust platform as a service with production on a top-tier cloud service provider. And none of that may be good enough.
What does this means for your quality of work life? Can you still be proud of your work or might this be the sort of thing that spurs you to find a new opportunity? Or maybe it doesn’t matter at all — you just grin and deposit the paycheck.
Tell us about the quality of your work life and the company behind the app. We’d like to hear from you.
As the cynics are fond of saying, the nice thing about standards is that there are so many of them. Nevertheless, if you build applications that in any way deal with healthcare, you should consider adding yet another one, HL7 FHIR, to your vocabulary. It’s part of the movement to drive paper out of the healthcare system.
FHIR, short for Fast Healthcare Interoperability Resources and pronounced “fire,” is a standards framework, still in draft form, that describes modular data formats and elements (called “resources”). It also encompasses an application programming interface (API) for exchanging electronic health records. It’s being positioned as suitable for mobile phone apps, cloud communications, and server communications within institutional healthcare providers. Supporters include industry heavyweights Cerner, the Mayo Clinic, Meditech, McKesson, and the Partners HealthCare System (which includes Massachusetts General Hospital).
Resources are the standard’s building blocks, numbering just shy of 50 and organized into 12 groups. The Medications group, for example, is composed of seven resources: Medication, MedicationPrescription, MedicationAdministration, MedicationDispense, MedicationStatement, Immunization, and ImmunizationRecommendation.
FHIR is managed under the auspices of Health Level Seven International (HL7), a Michigan-based “not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services,” according to its website. To put it more simply, HL7 creates standards for the interchange of healthcare data.
Though still considered a draft standard for trial use that is yet to be finalized, FIHR looks promising. If it eliminates paper and advances the speed and accuracy of clinical healthcare, I’m all for it.
Do you develop applications for the healthcare industry? If so, share your opinions about FHIR and your plans for incorporating it (or not) into your development process. We’d like to hear from you.
Microservices are your future. Actually, they are your present — or should be. If you’re not already well-versed in microservices and containers, you’re running at the back of the pack. It’s time to study fast and furious.
We’re all used to giant monolithic applications that handle every last aspect of a solution, no matter how small. To be simplistic, think Microsoft Word or Adobe Photoshop. Each does hundreds of different things. Photoshop, probably closer to a thousand. In the case of Word, it’s pretty clear that file management, page layout, spell check, mail merge, and printing have nothing whatsoever to do with each other. So, why are they all shoehorned into one giant program?
To answer my own rhetorical question, it’s because that’s how we’ve done it for decades. Sure, Word runs as a launcher .exe and a handful of dynamic link libraries (.dll files), but that’s for memory management as much as anything else. That model isn’t really any different that the days of yore when mainframe computers were lucky to have 64K of magnetic core memory. To allow large, monolithic accounting systems to function, different modules were often written as a series of overlays, swapped into memory as needed. It was a real art form. Microservices are vastly different.
In a microservices architecture, large, complex programs are built from small processes that are each independent, communicating with each other — when necessary — through application program interfaces (APIs). Think of it as a suite of small, non-coupled modules, each running in its own little world.
The advantages are profound. Microservices solves the update problem. With a traditional monolithic application, a new version usually means replacing everything. Not so in a microservices architecture, where individual pieces can be updated as necessary. That’s especially useful with cloud and mobile applications where, for example, weekly user interface or functionality updates are fast becoming the accepted way of doing business.
Second is the issue of demand scalability. Should one aspect of a monolithic system become a bottleneck, say, checking inventory levels in a retail application, there’s no simple way to add capacity. But, in a cloud application designed as a series of uncoupled, containerized microservices, it’s a relatively simple matter to spin up additional instances to meet demand and alleviate the bottleneck.
We’ll be doing some spinning up of our own, as SearchCloudApplications writes more about microservices architecture in the coming months.
What’s your experience with microservices? We’d like to hear from you.
As Internet of Things sensors appear in more places, it is cloud applications that must handle the data packets they generate. Depending on the use, the data could be anything from a trickle to a raging torrent. Are the applications you’re building capable of handling such volumes? And in real time? Is your cloud infrastructure or provider service agreement robust enough to handle enormous volumes and instantly scale when those volumes spike? Hope so.
Gartner research vice president Kyle Hilgendorf looks at IoT in a unique way. One IoT sensor creates a miniscule amount of data. Think of it as a single raindrop. But, put enough raindrops together and you get a downpour. That’s where we’re headed, he says.
Consider one scenario. If a sensor is monitoring the temperature inside some device — refrigerator, toaster oven, NAS unit, industrial furnace, airliner jet engine, or nuclear power plant — and reporting the temperature every 15 seconds, the volume of data your application needs to handle is tiny. But, if your application tracks temperature reports for every jet engine that a major airline carrier has in the air at any point in time, that single raindrop of data has now become part of a massive torrent. Your application needs to handle that, and storage must be capable of keeping up with both the collective amount of data and its incoming speed.
But wait, there’s more. Your application also has to decide which sensor data to keep and which can be ignored. Maybe you should write every temperature reading to a file or maybe just the ones that are outside of a pre-defined acceptable range — good old exception reporting. And what about that span? A 10-degree temperature variance in a toaster oven is not a big deal, but for a jet engine that variance could spell disaster. Then there are decisions about sounding the alarms in real time or simply presenting aggregated reports periodically. As always, there is no right or wrong answer.
How are the applications you’re building processing, leveraging, and storing incoming IoT data? Share your strategies with us; we’d like to hear from you.
Sitting in sessions at the Gartner Catalyst conference, one might expect to hear continual pushes to get everything into the cloud. That’s just not the case. In one key session, the message was that while it’s prudent to have a “cloud first” strategy, “cloud always” may not be wise.
That line of thinking was delivered by Kyle Hilgendorf, a Gartner vice president of research who is strictly business. No kidding around here. Some applications simply do better running in a traditional IT model. Which ones? There’s no clear answer because no two businesses are exactly alike. For one, ERP may do best sticking with a traditional model, for another it may be manufacturing process control. Or it could be a batch process, such as monthly statement rendering. It just depends.
Some legacy applications simply aren’t technically suited for porting to the cloud. That depends, too, but paying attention to risk factors is critical. Those factors might include regulatory compliance issues, customer privacy, and, in the case of medical applications, everything from patient service levels to potential loss of life.
In your analysis of application migration, have you identified applications or processes that are not suited for the cloud? If so, join the discussion and fill us in. We’d like to hear from you.
At the Gartner Catalyst conference in San Diego, Stephen Wheat, chief IT architect at Emory Healthcare, Georgia’s largest healthcare plan, got it right. To get cloud and mobile app development done within a reasonable time frame, the job is often outsourced to qualified partners.
One of the more articulate IT chiefs I’ve heard in a long time said it’s really pretty simple: His group identified three “preferred partners” for most application development. While a few projects will be implemented with internal resources, “most future projects will go to these external developers.” Of course, these developers aren’t just anyone. While they clearly have expertise in cloud and mobile, they also have proven themselves when it comes to compliance and governance. In a word, HIPAA.
What’s also shrewd is that Wheat uses different review and deployment models for apps that are public-facing or those for use only by employees on the inside. Why? Because a multitude of aspects differ for internal and external apps. These include trade dress and branding, legal, compliance and regulatory, communications, and more.
It gets even more interesting. Emory Healthcare currently counts 21,678 mobile devices on its network. Amazingly, 99.5% percent of them are bring-your-own devices (BYOD). Fewer than 200 mobile devices are actually are actually managed by Emory. The app portfolio is about 60 strong, with more on the way. These include simple apps for finding one’s way around the facilities, to 3D imaging apps that help surgeons with highly complicated liver surgery. Designers take into account not just security issues, but, “security that’s relevant to consumers,” Wheat says. What that means is that, for example, epilepsy patients may not have the motor skills to navigate through sign-on and authentication procedures that you and I take for granted.
You can learn more about Emory’s IT architecture. It’s a fascinating read.
What are your priorities when it comes to app development and getting the product out the door? Are you willing to hire outside help?
We don’t hear much anymore about building applications intended to run inside a mobile device’s browser. It’s just not fashionable or newsworthy. These days, the tools, techniques, user conferences, and marketplace are all about native mobile apps. Which camp are you in?
The browser is the easy solution. You don’t need separate code bases for Android, iOS, and Windows devices. If a website and server-side code works in one browser, it should work in any other. That model simplifies development, can vastly cut development costs, and speed time to market. When you’re done with development and testing, there’s likely no need for third-party certification and no app store to deal with. Host your site and you’re in business.
Seems perfect. But, what about the all-important user experience? You can’t push notifications and there’s no way to keep it running in the background. Because it has to run inside any browser, performance may be less than optimal. After all, we’ve all seen websites that run just fine on one desktop browser only to crash and burn on another. Cram too many design elements in the site to create a quasi-native-app look and feel, and painting the screen might become painfully slow. For your entertainment pleasure, you can even view a gallery of mobile Web design miscues. Yet, for all their shortcomings, businesses still need to offer a mobile Web experience.
Mobile apps are very different. You tailor them to the specific OS and screen size. That means they’re likely to look a lot more attractive. Performance is almost guaranteed to be zippy. Users are likely to have a more-enjoyable experience. And that means they’ll come back again and again. Available for downloading via app stores, discoverability is easier. And you can charge a fee. Even big companies like magazine, newspaper, and other content publishers do that.
With mobile apps, you can send push notifications. You can save content to the device for working off-line. It’s the reason I can store my airline boarding passes in the iPhone Passbook app with no need to worry about whether I have a Wi-Fi or cellular connection at boarding time.
But, as in all things mobile, there’s a tradeoff. That OS and screen-size tailoring extends development cycles. That means development costs are higher. You’ve got to go through the vetting and testing process at multiple app stores. And there are the fees you have to pay every time your app sells.
This isn’t an either/or scenario. I suspect in the vast majority of cases that businesses need to offer a mobile Web and native app. A private developer who is building a game isn’t bound by the same rules.
Which is it for you? Have you forsaken mobile Web in favor of apps only? Or are you sticking with both? Are you migrating from Web to app? We’d like to know.
Data isn’t safe anywhere. Pay a zillion dollars for security, and it’s not going to stop the bad guys from getting in. Just ask the federal government. Or Target. Or Home Depot. Or TJX. Or Sony. Or Anthem.
Maybe it’s better to save all that money, spend zero on security, and simply let the bad guys saunter in through the front door. After all, they are coming. Talk about great ROI. But, we know that would be a hard sell to the CEO, especially in this age of Gramm Leach Bliley information security requirements, HIPAA, and COPPA, the FTC’s Children’s Online Privacy Protection Act.
As a developer, you have several alternatives for dealing with data security. You can build multiple rings around data sets and hope for the best. Of course, that doesn’t protect you if the bad guy is an employee who is already on the inside. (No wonder we don’t hear much about intrusion protection anymore.)
There’s the concept of app wrapping, cloaking a mobile application in a shroud of parameters that might be configured to prohibit local data storage on the device, or self-delete the app after three failed password attempts, or bar saving files to any third party service, such as Dropbox or Google Drive. Fortunately, with app wrapping, you can build your app without much regard for these issues, and apply the cloak as a wrapper around your finished code.
The latest discussion centers around whether to encrypt everything that isn’t already publicly available. The idea makes sense — let the bad guys steal all the data they want, but if it’s utterly unusable, perhaps they’ll eventually give up. Unfortunately, in practice, it gets much more complicated.
You need to think about every employee’s or customer’s device needing to decrypt data in order to use it. That’s big-time processing overhead, depending on the amount of data, not good when your mission in life as an application developer is to keep cutting response times. And when the transaction is completed, you’ve got to re-encrypt for transmission back to the database, wherever it resides. More overhead. And you’ve to build all this into your program code. There’s also the huge issue of key management.
As a developer, how concerned are you with transactional or at-large data security? A lot, because it’s the right thing to do, or not at all, because security is someone else’s job? Are you called into meetings on data and systems security? And are security protocols different, depending where files live?
Share your opinions about application-level data security. We’d like to know about your experiences, and you’ll know that you’re not the only one out there pondering the same questions.
We’ve all seen it. That chief marketing officer wants a new report or a redesigned user experience on the company’s mobile app. The guy is already fed up with an IT department and CIO he sees as everything from active obstructionists to clueless, unresponsive ne’er do wells.
IT isn’t interested, doesn’t have the people or budget, has other more-pressing projects on the docket, or may simply doesn’t get what the marketing team is trying to accomplish. What happens next is that the department decides to go around IT and sign up for some software-as-a-service subscription or, increasingly, use a no-code drag-and-drop tool to build mobile apps that connect to company data through an assortment of APIs. After all, the point of many APIs is to simplify access and integration. The result: Shadow IT.
I’ve heard it argued that Shadow IT can’t harm corporate intellectual assets (data) if the apps built are read-only, perhaps for generating sales or inventory reports. I’m not buying that argument, though it depends how you define harm. While prohibiting write access does protect digital assets against dastardly destruction, deliberate deletion, or worse, evil editing, a read-only app still puts the data out in the wild, where you have no control over who can see it. That doesn’t damage the data, but it certainly could harm the business.
As for these no-code tools, the selection abounds. Industry analysts are even looking at them as a good way to accomplish tasks that move the business forward without straining developer resources that are already stretched thin.
Shadow IT is inevitable. To make it work better for everyone, I’d like to see the marketing department be less surreptitious about it. Go to IT and say, “We’re going to do this and we wanted you to know before we start.” Not only is that good corporate citizenship, but it increases the likelihood that IT will take at least a cursory look at the tools and project intent to ensure that security is up to snuff and regulatory mandates (HIPAA, for example) aren’t smashed to smithereens.
As a developer or CIO, what’s your opinion of the trend toward departmental no-code app development? Everyone I speak with has strong feelings. We’d like to hear yours.