Design Essay #1 – Disconnected Data-Driven Apps

Note to regular readers: This is a software development-related post. Occasionally I do these to help process and clarify my thoughts on a project. If software design isn’t your cup of tea (or coffee), feel free to skip today’s post – I won’t be offended. Actually, I won’t even know!

I’m presently mulling over the design of a new app that will feature both an iOS app and a browser-based UI sharing a common web server backend. The browser UI/UX (User Interface/User Experience) is easy to think through, but the iOS app, not so much. It’s not a matter of how the controls on the interface will be laid out, or what the screen-to-screen workflows need to look like. It’s more a matter of the user experience when the iDevice is disconnected from the network.

I want the application to feel very responsive whether connected on WiFi, 3/4G, or completely disconnected. This implies a local copy of the data on the device, and that implies that data needs to be kept in sync with the server backend. This all leads very quickly to every programmer’s least favorite topic – data synchronization. It’s a simple concept to talk about, but it’s never easy to actually implement. It’s a nontrivial process that can be extremely complicated depending on the requirements of the UX.

Let’s start with a populated database. Our browser-based user gets a standard CRUD (Create/Read/Update/Delete) interface to interact with the data. Other than worrying about record-locking so that multiple browser-based users don’t run each other over trying to simultaneously update the same record, we’re pretty much good to go. Handling record locks is a well-known pattern with a straightforward implementation.

Our iOS user, however, will need a local copy of the database. Getting the first copy downloaded is easy. We ask the server to dump the data in JSON or XML format and then have our app throw it into a local Core Data database. If this was a view-only app, we’d be finished, other than to provide a mechanism to regularly refresh the data, such as at application startup, return from background, or when the user hits a refresh button. We would certainly implement a way to receive only updated records in the future, and that could be handled by adding a “last_updated” field to the table schemas, and asking only for those records that were updated since the last time our local database was refreshed.

At some point though, the iOS users will demand equality with their browser-based brethren. Rather than risk bringing an Occupy Wall Street-style event to our development lab, we are compelled to provide CRUD functionality on iOS. This means data is going to be changing in multiple places, and we’ll have to do careful, regular housekeeping to keep everything in sync.

The basic blocking and tackling here will involve sending CRUD transactions to the web server for processing and acknowledgement. If we send a new or updated record to the server, we’ll want a response that tells us how things went back at the server. When things don’t go well, we have to decide what to do. If the failure was caused by a connectivity problem, we need to mark the update as not sent and keep it in queue of unprocessed requests to be retried at a later time. If the failure was some sort of system or database problem back at the server, the response should help our iOS app make an informed decision on what to do.  And what sorts of problems might we face?  Database down or bad credentials?  Server out of disk space? Duplicate record errors? Non-null field violations?  I’m not sure I can guess them all, but I do know we need to have a default action to handle  unexpected edge cases.  And what do we tell our iOS user when things turn evil?  Hmm….the Apple Way would be to just hide it all from the user and try to figure out a way to handle it silently. Definitely non-trivial and perhaps not worth the development effort. I lean toward being straight up with the user and telling them that the operation failed and they will need to try it again later – in a very nice way, of course.

Let’s look at another situation: User A is using a browser. User B is using an iPad and has just refreshed his local copy of the data. Both decide to update the same customer record. What are the possibilities?

  1. They change different fields (e.g. user A changes “Street Address” and user B changes “Credit Card Expiration Date”)
  2. They change the same field (e.g. both A and B change “Last Name”)

In case #1, we probably want to preserve both changes, though we really can’t be 100% certain. In case #2, both A & B may have both changed the last name (i.e. both changed “Smith” to “Jones”), but what if they changed it to two different last names? Which change should we keep?  Should we say we’ll keep the latest change? We can, but that doesn’t guarantee we’re keeping the right information. We remember that we can’t lock the record as we did when our two browser users we’re vying of the same record because our iOS user could be using the app while disconnected. In fact, he can’t even check for record locks. And even if he were connected, the network delays of lock processing would probably result in a very poor user experience. So…what to do?

The robust solution would be to build a mechanism that allows the users to see where multiple updates on the same record have resulted in a conflict, and then allow the user to pick which one will be kept. That takes the difficult (impossible?) decision out of our code and puts it in the user’s lap. This could be implemented by adding two fields to the table schemas. A boolean “conflicted” field could be used to indicate that a record encountered a conflict condition when an attempt was made to process it into the database. An complementary “conflict_id” field could be used to point to the other record that is party to the conflict. When a conflict is detected, the record in question would be added to the table with these two fields set appropriately, and our CRUD interface logic would have to pick these out, highlight them for the user, and provide some actions to let the user clean things up.

In the spirit of getting something running quickly, my druthers would be to use a phased approach to get to The Promised Land above.

Phase I: Implement full CRUD capability for the browser UI, and view-only on iOS. The database back-end is a well-known pattern that can be laid down quickly and get the browser users online. Doing view-only on iOS first lets us work through the minutiae of the Core Data implementation without the complexities of dealing with disconnected CRUD activities and conflict resolution.

Phase II: Implement full CRUD on iOS for just one of the tables and develop the backend API needed to asynchronously process updates from the app.

Phase III: Build the conflict resolution mechanism for the same table.

Phase IV: Implement full CRUD for the rest of the tables by simply extended the work done in II and III. At this point most of the guess work should be over, and things should proceed quickly.

I can’t imagine having any readers that made it this far, but if you did, and you’re a coder, AND you’ve been down this path before, I’d love to hear from you.  How have, or how would you tackle this conundrum?

 

Mainframe 3.0

Great ideas in technology don’t change, though they do change forms.

Courtesy of Sega

I started my corporate IT career near the end of the Golden Age for mainframes – just prior to PC’s taking off in corporateworld. SNA networks were de rigueur in enterprise shops and 10Base2 Ethernet and Token Ring were considering leading edge tech. (If you had a deep understanding of everything in that last sentence before following any of the links, contact me – I’d like to buy you lunch). This was “Mainframe 1.0”, a centralized computing model where all of the iron was essentially in one room. We could post big burly men wearing face camo and M-16’s around the doors and feel relatively confident that everything was safe and secure. We sent 9-track tapes off-site for backup and paid confiscatory rates to disaster recovery providers to put us up in their “recovery suites” should our data center fall victim to a fill-in-the-blank disaster. We worried mostly about fire, water, and extended power outages. A Chinese hacker was someone working in a rice patty, not an imminent threat to our security. Ah…the good old days. Mainframe 1.0 was compute, storage, and networking all together, all in one place.

As PC’s brought about the so-called “Client/Server” era, tech pundits began to proclaim the death of  Mainframe 1.0 and tried to convince us that  a decentralized computing model was really what we’d all been waiting for. A PC on every desk and a server in every closet.  Move the compute and the data closer to the user, we were told – it’s all good. The fact that it really wasn’t all good is a subject for another day, but the client/server era did bring about Mainframe 2.0.  In Mainframe 2.0, our well-proven and beloved big iron continued to do what it always had, (despite the denial of some), but it was reframed as just a Really Big Server in the shiny new client/server model. Mainframe 2.0 was all about moving high-horse power compute and storage into a hierarchy where it still handled the toughest, most critical workloads, but also played nice with others in terms of sharing data with smaller servers and client devices. A quick look at IBM’s annual reports through this era consistently showed healthy big iron sales. Clearly, rumors of the mainframe’s impending death were being greatly exaggerated.

Even though Mainframe 1.0 and 2.0 had been using virtualization technology since the 1970s, the introduction of virtualization on the Intel architecture somehow seemed to take the experts by surprise. As eyes began to reopen to the lessons and economies learned on Mainframe 1.0, and products like VMWare began to mature, we began to see a shift back towards a more centralized model. More workload on fewer but larger, centralized machines. Storage moving from server closets into high capacity, centralized storage arrays available over the network. Data and storage networks converging into one. Re-centralization was bringing better utilization, lower costs, and less management headaches. Who could have imagined?

As this new-found trend toward consolidation and centralization continues, we find ourselves at the beginning of Mainframe 3.0 and a new buzzword to go with it: Fabric Based Infrastructure, or FBI.  By definition:

A fabric-based computer is a modular form of computing where a system can be aggregated from separate building-block modules connected over a fabric or switched backplane

Practically speaking, FBI is compute, storage, and networking all together, all in one place, like Mainframe 1.0 of the 1980’s, but all in one rack and much more versatile and dynamic.

FBI is not built on the mainframe hardware of yesteryear, but the concept is strikingly similar. Products like VCE’s VBlock, or IBM’s brand new PureSystems take the best of Mainframe 1.0 paradigm and rebuild it with the latest technology. You might even liken it to the difference between the Iron Man Mark I and Mark II suits.

When you buy FBI, you are buying a pre-integrated bundle of compute, storage, networking, and virtualization, ready to use right out of the box (“ready” being a relative term depending on vendor). Sort of like Prego…”it’s [all] in there.” The mundane, time-consuming tasks of provisioning servers, storage, and networking manually are all abstracted away by higher level management tools. In an FBI world, the weeks of time previously required to set up a new server environment is reduced to minutes. Administrators create new server environments by simply requesting them through a browser-based service portal. The fabric manager takes cares of the rest. Almost sounds too good to be true.

VBlock fabric is built with Cisco UCS compute and networking, EMC storage, VMWare, and a software management stack, preassembled, tested, and ready for immediate provisioning. PureSystems fabric is built on IBM’s new Flex System compute platform, BNT networking, and V7000 storage. While VBlock specifically supports VMWare only, PureSystems takes a broader approach of supporting most any hypervisor, (VMWare, Hyper-V, KVM, PowerVM, etc), and can virtualize Intel or IBM’s Power architectures within the same chassis.  As you exceed the capacity of a single rack, the “fabric”  can be scaled out by adding additional racks of capacity.

VCE is a subsidiary company formed by VMWare, Cisco, and EMC, so it’s no surprise why only VMWare is supported on VBlock. On the other hand, this closed approach allows VCE to deliver a much more complete, ready to use solution. IBM is just arriving to the FBI party with PureSystems, and while it’s hard to nail down all of the details right now, it appears that more assembly is going to be required on a customer’s part to get to the same level of automation that VBlock offers out of the box.The Flex System hardware is also new to market for IBM, so early PureSystems customers will have to blaze that trail as well.

Besides VCE and IBM, NetApp also has an FBI offering in the form of a reference architecture, know as FlexPod, that shows how a fabric can built using Cisco hardware, VMWare, and NetApp storage products.Unlike VBlock and PureSystems however, FlexPod is not an actual product you can buy, it is merely a reference architecture.

If you’re considering building a cloud from scratch that needs to be implemented quickly, provision easily, and scale rapidly, I would encourage you to investigate fabric based infrastructure. An old idea might be just right for your new solution.

Making a Sound Technology Decision

Some times clarity appears when you least expect it. Just this past week it revealed itself again as I was being asked how I thought particular business application systems should be hosted. In each case the choices were:

  1. DIY – The traditional Do-It-Yourself option of using your own hardware and support staff. Everything is in-house and 100% under your control at all times. You are impervious to fires in tunnels and squirrels electrocuting themselves. You bear 100% of the cost of the hardware and the technical staff needed to support the whole affair.
  2. SaaSSoftware as a Service, where the application vendor either puts up a dedicated instance of the app just for you, or you live inside their multi-tenant environment. You do nothing but pay the bill and use the software, but you do place yourself at the mercy of your network connection and the competence and reliability of your SaaS vendor. You control none of the many moving parts, but you do put your faith in all them to be working when you need them. You also hope when you call for support that 1) a live, competent person fluent in your native language will answer, 2) the answer to every problem will not be “reboot your PC or cable modem”, and 3) the problem will be resolved in a timeframe your business can live with. As a small fish in a big pond, you recognize that you have no leverage (except perhaps a Twitter tirade) when the service goes down and your business goes thermonuclear.
  3. IaaSInfrastructure as a Service. An in-between solution where you buy server and storage resources from a cloud hosting provider, but you install and support your application. Like SaaS, you don’t have to worry about the hardware infrastructure. But you again bet the farm on your network connection and your hosting provider’s ability to keep the lights on. Unlike SaaS, you retain complete control over your application, which limits your risk and dependency on the hosting provider.

With all of these things to consider, making a cloud hosting decision might seem like trying to find the alligators in a swamp full of muddy water. Fortuantely, as in many areas of life, perspective and context are the keys to making a good decision. The answers to all of the varioius scenarios thrown in my in-box turned out to be not so much based on cost or technology, but more about the particular business implications of each situation. And it all really boiled down to one simple question:

If this application is unavailable, will my business be unable to transact business, and if not, how long can I put up with that?

Suddenly, the muddy water becomes strikingly clear. If your ability to run your business is dependent on your network connection and a distant data center, are you comfortable with that? To whom would you need to explain the downtime, and what would your customers say? What would be the impact on your bottom line?

For applications that aren’t critical to daily operations, SaaS and IaaS are perfect almost right out of the box. For critical apps, SaaS and IaaS can work if you design redundancy into your network connectivity, and the apps themselves are designed to let you run offline for a period of time. If you don’t have, or don’t want to have any infrastructure or technical staff, then a SaaS strategy “hardened” along these lines may be your best option.

Whether it be commercial or a non-commercial enterpise, the simple question above remains relevant. In churchworld, for example, would you want the Sunday morning presentation software (i.e. the “mission critical app”) to be running only in the cloud? Probably not. But the membership tracking application? Maybe so.

Ultimately, understanding business impacts is prerequisite to making sound technology decisions.

What apps in your business would you consider safe, or not safe to run in the cloud?

Should Upgrades Be Free?

Free-upgrades-forever has been a feature of the iOS and Mac App Stores since Day One. Users get a great deal: buy an app one time and get all future updates for free. As a user myself, I like that. Developers, on the other hand, end up with the short end of the stick, as they are seemingly faced with supporting that app throughout it’s lifetime for free. As a developer, I hate that. Will Shipley’s recent piece has forced the developer community to recognize there’s an elephant in room, and he’s not there for the peanuts. Indeed, I am having to face the elephant also, and I covet your thoughts as I decide how to proceed.

Before the app stores, software not only cost more to buy, but developers could easily charge for updates. It all happened either in brick-and-mortar stores or from the developer’s web site. Money could be collected to recoup development costs and make some profit every time a developer delivered more value to his customers.

With the advent of the app stores, Apple knocked the bottom out of software pricing. What used to sell for $29 was suddenly selling for $0.99, and what used to sell for $49 or more was lucky to sell for $15, and probably ended up at $5. Perhaps it was an unintentional side effect, but Apple effectively conditioned the market to expect quite a lot for $0.99, and for $5, to expect the moon. On top of that, they also unilaterally decided that all updates should be free. Perhaps this was a deliberate strategy to commoditize its complements, because Apple is after all a hardware company, but the long-term results on developers are proving to be more than a bit concerning as the marketplace matures.

Nevertheless, it is Apple’s ecosystem, and rather than brood over it, developers simply need to find a way to deal with it. I’ve reached that point myself, and it’s time to make some decisions. I’m not bothered by providing fixes to bugs for free on older versions,  those should be free, but as I consider adding significant new functionality that brings more value, it seems only fair to be paid for that value.

So rather than sitting around hoping for Apple to change its mind about paid upgrades, here are two options I’ve been pondering. How do they strike you?

  1. Create a new, separate app. Instead of adding new features to the version already in the store, a new app would be placed in the store that is essentially an upgraded version of the old. This would be good for me because I’d be getting paid for the new value I’m delivering, but bad for my customers for a number of reasons:
    • Existing customers have to pay full price for the app again. They are being made to pay $10 for what new customers are getting for $5. This doesn’t seem quite fair. Also, suppose someone just bought version 1 last week, and now version 2 shows up in the store? It’s not fair to ask them to buy it again a week later. They could ask Apple for a refund, but I know I’d be miffed about that as a customer.
    • The new app can’t use the old app’s data. From Apple’s standpoint the two versions would be completely different animals and barred from sharing data. This means customers would essentially have to start from scratch – any data they’ve created in the old version could not come along for the ride. Depending on the app that might be OK, but in my case, it would cause tremendous weeping and gnashing of teeth, not to mention a gaggle of 1-star ratings and odious reviews.
    • If a customer doesn’t buy the new version, they don’t get the latest enhancements to the app. I’d call it “soft-core blackmail.” As a developer, I would have zero incentive to improve older versions once I put a new version in the store. My attention would always be focused on the current version, because that’s the one paying the bills, especially as the burden of supporting the old version grows more costly over time.
    • To avoid confusion, I would have to take the old version down from the store so that new customers would not accidentally buy the wrong version. That would leave existing customers out in the cold, since removing the app from the store would mean I’d have no way to get new bug fixes out to them.
  1. In-app purchase of new features. Perhaps you’ve seen drawing apps that allow you to buy additional brushes and tools via in-app purchase. One could effectively do the same with any new features in an app. Existing users could buy the new features that interested them, and new users would be in the same boat. Seems fair. But this only works from a developer’s standpoint for certain kinds of features. Not every enhancement can be done as an add-on option. This angle also requires significant response from customers to make it financially worthwhile. Last time I checked, the conversion rate on in-app purchases was under 2%. And, I worry that it could feel like a “nickel and dime” approach to existing customers, sort of an old-style mafia shake down in digital clothing.

I’m not really happy with either of these options, but to quote Shipley:

Without paid upgrades developers are strongly dis-incented from writing new major versions of existing products. Which stinks for us, and for customers.

So with that in mind, every serious developers has some decisions to make. My druthers, and that of many other developers, would be to simply charge an upgrade fee, and that would be a “win-win” for everyone. Sadly, those are not the cards Apple has dealt out.  We clearly need some creative thinking to solve this Kobayashi Maru scenario.

If you were my customer, how would you advise me?

If You Build It, Will They Find You?

After going through the hard work of developing a mobile app for your business, you would surely like a significant number of people to find it. Much like a bomb’s purpose is to explode, an app’s purpose is to be used. It turns out that while building the app is certainly more like science and less like astrology, I’m finding the opposite to be true of getting apps noticed.

Case in point: I’ve had a music dictionary app named “MusicTools” in the App Store for over two years. Despite the great reviews and ratings it receives (4+ stars), daily sales volume are measurable using the fingers on just one hand. As I’ve wracked my brain trying to find a way to increase sales, I’ve made an alarming discovery. If you pull out your iPhone, go into the App Store and search on “music dictionary”, here is what you are likely to find:

The top two are either average or not well rated, but have the words “music” and “dictionary” in their title. Notice the little cheat exinhe used to game the system by adding a “.” to the end of the word “Dictionary”. Genius. Clearly the App Store gives significant weight to app titles that contain the search keywords, and that makes sense.

But as we then scroll through the rest of the apps listed, we find reverse chord dictionaries, guitar chord dictionaries, rhyming apps, history books, religion books, poetry collections, and finally down around position 31, MusicTools. The first keyword I used when listing the app in the store was “music dictionary“. The description I provided for the store describes in great detail how this app is a music dictionary. Now how in blazes does that not rank better than rhyming apps, history books, and poetry collections?

My revelation was that not having the word “dictionary” in the title obviously cost me mega-ranking points, and exinhe’s little trick with the “.” proves that name rules supreme over ratings and reviews.  As I said above, that does makes sense to a degree, but consider this: the app with the mashup name of  “Musictionary” usually lists in the top 5, does not have the words “music” and “dictionary” explicitly in the name, ranks only 3 stars, and gets average or poor reviews. How is that MusicTools, also with a mashup name, but with 4+ stars and good reviews, doesn’t list ahead of, or at least along side of it?  Cue the Mayan music and bring in the astrologers.

I continue to search for the answer to this vexing enigma, but I think the lesson to be shared is that the name you pick for your app is more critical to its discovery than you might realize. Search keywords alone obviously do not cut the mustard. With over 500,000 apps in the store, let alone how many might be in your app’s particular category already, you really should put some “discoverability” thinking into your calculus when choosing a name.

There’s an old proverb from the 16th century that goes something like “give a dog a bad name and you might as well hang him.” Apparently that proverb applies in the App Store as well.

Am I off base here?  Would you not expect the top search hits in the App Store to actually be what you searched for?

Should You Worry About Having an Android App?

I’ve been trying hard to sell you on the need to have a mobile software strategy for your business. If I’ve managed to convince you thus far, you may be wondering where to begin. You do of course need a good idea to start with, but very soon you’ll need to decide not only who your ideal customer is, but what kind of device she carries. Targeting Apple’s iOS devices is a must-do, slam-dunk, no-brainer, but less obvious is what to do about the Android platform.

Before jumping into the Android pool, it would be good to take an eyes-wide-open approach to the current factors causing developer malaise in the Android world. The largest of these include:

  1. Lower sales. Looking at raw market share, Android would seem to be a necessary play if you want to make money.  Unfortunately raw market share doesn’t tell the whole story, but sales data definitely help color it in. The chart below is for Audiobooks, a very popular app that’s been downloaded over 2 million times.

 

 If this chart is even closely representative of the entire mobile app ecosystem, Android is clearly not the place to make your initial investment.

  1. Hardware fragmentation. By this count, there are at least 1,443 known varieties of Android devices in the wild. Trying to support them all with a native app would be a sure-fire going-out-of-business strategy. The cost would simply be unsustainable. On the other hand, not supporting them all is guaranteed to attract a gaggle of poor reviews and 1-star ratings.
  2. Slow OS adoption rate. As seen below, compared with iOS, user adoption of new versions of the Android operating system are extremely slow, meaning developers must support more versions of Android for longer periods of time, and possibly delay the release of new features that rely on more current versions of the OS. Translation: more cost.

  1. Customer Mindset. The Android customer mindset is not the same as that of  iOS customers. David Smith, developer of Audiobooks, captures it well:

I think most droid users have never heard of the android market, whereas most iOS users get their phone and then immediately go looking for apps. That is just anecdotal, but it seems like a lot of people just view it as the ‘free’ phone option at the cell phone store…sure there are people who are deliberately choosing it but I’d guess that is a minority.

This helps illuminate why one can observe a tendency to favor, if not outright expect, free apps in the Android marketplace. Check out this thread as an example (WARNING: strong adult language). Quality apps sometimes struggle to get a fair shake in a marketplace where the mindset leans toward apps having to be both all-things-to-all-people and free to boot.

These four issues, especially #2 and #3 are getting bigger, not smaller.  Why deal with all this friction when you’re just starting out?

Bottom line: It’s not necessary to support Android as you begin your app development journey. It may seem like you’re missing a huge opportunity, but clearly that’s not the case, at least not now. Start with iOS, become wildly successful, and then tactically approach Android. Based on your market research, support a carefully selected, small handful of Android devices and operating system levels that your ideal customers are likely to be carrying. This list will change over time, but managing it to a small set will be key to being profitable on Android for the foreseeable future.

What are your feelings on whether apps should be free?

Keys To Building a Mobile Software Strategy

strategy |ˈstratəjē|

a plan of action or policy designed to achieve a major or overall aim.

There is popular saying in IT circles, especially among disaster recovery planners, that “Hope is Not a Strategy.” The same is true of developing a mobile software strategy for your business. More is required than simply throwing an app into the App Store and hoping for the best. A well thought out plan is essential to getting a good return on your investment and avoid having your app die a lonely death in the App Store.

Here are some things to consider when developing your mobile software strategy:

Outcomes. Start with the end in mind, as well-known author Steven Covey would say.  What business outcomes are you hoping to achieve? Better awareness of your business? Monetizing your intellectual property (IP)? Transacting business with your customers no matter whey they are? Are you trying to maintain competitiveness, or bring break-away innovation and thought leadership to your industry?

Target Market. Who is your audience? What do they really need or want? Perhaps you already have a good feel for that, but thorough research will help validate it and help reduce the possibility that you’ve been wearing blinders. What kind of experience do you want them to have when they’re using your app? Simple and easy, or is complex OK?  Is your audience sophisticated engineering types, average consumers, or somewhere in between? Does your idea pertain only to a particular industry, or is there cross-industry appeal? The Steve Jobs mindset of “customers don’t know what they want until we show them” worked well for Apple most of the time, but the safest approach would be to do the research.

Platform. Apple? Android? Windows Mobile? This is actually the easiest decision to make. If you start with just Apple’s iOS platform (iPhone & iPad), you are likely to find all the market you need. The Apple and Android ecosystems are radically different from a developer’s point of view, and it stems from the simple fact that Apple tightly controls their platform, while Google does not.  In reality this translates to an Android platform that is splintered and non-standardized, with dozens of different device types and form factors to support. This naturally translates to higher development and support costs with no reasonable way to quantify the potential return. With Apple, there are essentially only two form factors to support, and Apple takes great care to ensure good backwards compatibility when upgraded models are released. From a business standpoint, Google Play (previously known as the Android Marketplace) is still problematic and lacks a solid review process that provides adequate protection for developers. Add to that poor support from communications carriers and hardware manufacturers for the devices themselves, and it quickly becomes apparent that Android is not the place to start your strategy.

Development. What is your core business? If the answer isn’t software development, or you’re not interested in adding it as a core strength, how to outsource the development of your apps will be an extremely important consideration. You might also explore licensing and re-branding an existing third-party app that has enough of the key functionality you need.

Reflect a bit before pulling the outsourcing trigger. The quality and sophistication of current software development tools, particularly on the Apple platform, has drained the software development swamp and lowered the barrier to entry tremendously. Setting up an Apple development shop today is more of a people investment than anything else.  A key consideration now is how much control you want (or perhaps need) to have over your own destiny. If you are willing to make the people investment necessary to do your own in-house development, you will have maximum control over quality, cost, time-to-market, customer satisfaction (see below), and the ability to innovate quickly.

If you do choose the outsourcing route, your options are on-shore with a U.S-based developer, off-shore (think India, Russia, China), or perhaps a talented teenage niece or nephew. As in so many areas of life, the time-honored mantra of “you get what you pay for” applies here as well.

Working with off-shore developers is typically difficult because of cultural barriers, time-zone differences, potential legal issues, and blatant dishonesty. If $15-$20/hr for software development seems too good to be true, well…it is. Buyer beware.

At the risk of sounding snarky, and I’ll admit this is a pet peeve of mine, I believe it’s worth pointing out that despite what tech pundits may say, great software is not developed in a weekend over a pizza and a liter of Coke. Just as not everyone with a pencil and ruler can design and construct an elegant home, neither is elegantly-designed and well-built software something that just anyone can do. Interview and review the portfolios of many (10-20) outsourcers before making any decisions.

My preference, which I would also advise to you, is to first seriously consider building your apps in-house, and if that doesn’t make sense for your business, use a US-based development company. Daniel Pink informs us that left-brained activity like software development is shifting overseas. While that may be true to a degree, Mr. Pink is not responsible for your business’s reputation and credibility, nor will he be there to help you with the issues you’re likely to encounter offshore. There are great (and affordable) left- and right-brained developers right here in the good ‘ole USA.

Marketing. Designing and building a software idea into a real product is only 20% of the process. The rest is sales and marketing. How will customers find your app? How are you going to generate awareness? Are you targeting a mass market, or a niche? Rest assured, with 500,000 iPhone apps and 220,000 iPad apps already in the App store, your apps are not likely to get noticed on their own. You must do the pick and shovel work necessary (or pay someone) to get the word out to your target audience.

Price. If you’re creating a Brochure or Transactional app, the price should be $0.00 because your goal is to get it into as many hands as possible. Beyond that, the key question is “what do you want to get paid for?” If it’s your IP in a form that the app actually delivers, such as performing a particular complex calculation, simplifying a complex task, or supplying valuable data and analytics, then the price of the app should reflect that value. We unforutnately have to deal with the fact that the $0.99 game market has negatively skewed the value of software in the minds of many, especially in the mobile marketplace. Resist the temptation to undervalue what you’re offering. Research from Distimo and others shows that people do associate better value with higher prices, and it’s reflected in their behavior when selecting a non-game app. They also tend to value good reviews higher than price. App reviews are a topic for another day, but it’s worth pointing out now that one-star reviews are potentially deadly to the financial life of your app.

Support. Hopefully your apps will be well-crafted and rock-solid, but all software has bugs, and you will want to be prepared to take care of customers who eventually find the ones that matter. (Yes, there are bugs that don’t matter!) Another key advantage of doing your development in-house is that you can handle these support issues yourself and maintain full control over the situation and manage customers expectations. No need to cajole your outsourcer into dropping everything he’s doing and work on your problem Right This Minute.  He most likely won’t anyway.

Summing up…

Considerable time and effort goes into creating an effective mobile software strategy. The “gold-rush” days of the App Store, where just being in the store was enough, are over. The great news is, however, there has never been a better time for a business to use software to expand markets and create innovative new solutions that help customers in meaningful ways.

There’s so much more to say on this topic, but if you focus on the points above, you’ll be off to a great start. And if you’d like to go deeper, please feel free to contact me.

Assuming money was not an issue, would you prefer to build your apps in-house or outsource their development?

What is an “App”, Really?

Lest we forget, the term “app” has its origin in the word “application”, and more precisely, software application.  With the introduction of the iPhone 1G and the famous “There’s an app for that” advertising campaign by Apple, the definition of “app” seems to have been quietly narrowed down to software that runs only on a smart phone or media tablet. If you’re planning a mobile software strategy for your business (and I think you should be), it’s important to be clear on just exactly what the term “app” actually implies.

In the late 1970’s  when I was programming on this platform, we called the software a “program” and it was an all inclusive solution. It ran on one machine and used the directly attached storage and printers to get the job done. No network, no server to talk to, no Internet. No confusion.

When I later worked in a mainframe shop in the early 1990’s, we still used the word “programs”, but also called them “applications”, and they sometimes communicated with other applications via network links to destinations like the Federal Reserve Bank.  As client/server PC technology then crept into the picture and “three-tier architecture” became the new buzzword, we spoke in terms of “client/server applications” and “mainframe applications” to keep things clear. Still very descriptive, and everyone understood the relative underlying complexities.

And finally, as the PC/laptop era went into full swing in the 2000’s, we just said “applications” no matter what the platform, and tech folks could still contextualize things properly in their own mind.

Fast forward to the iPhone 3 era, where we could now find consumers and current generation techies throwing the word “app” around as if it described software that could only run on their phones and claiming it’s something anyone can build on a Saturday afternoon. At this point, confusion, murkiness, and disillusionment enters the scene, because businesses desperate to have iPhone apps are finding themselves confronted with a harsh reality: building an app is not the same as building a web site. An app can be a complex animal, just like the mainframe programs of old.

Somewhere along the line, it seems the proper perspective on what an app really is was lost, or at very least, badly watered down. So whether you are crafting a comprehensive mobile software strategy, or just considering a single app for your business, here are some common app patterns to help clarify your thinking and gain some perspective:

  1. Brochure Apps. A brochure app is effectively a mobile version of your web site. It provides content about your business in a format that looks nice on the phone and is pleasure to interact with. This can be accomplished to a certain degree without the need for an app by simply making your current site mobile-friendly. This list of resources will get you started down that path. Your customer’s experience, however, will be better if you take the time to convert your content into a native phone app. Brochure apps are usually self-contained, typically the least expensive to build, and normally offered as a free download.
  2. Utility Apps. A utility app can be built to capture your intellectual property (IP) in a form that can be sold for profit. Perhaps you’re an engineering firm that’s developed a set of highly complex and specialized calculations used in a particular design or construction process. You could build a calculator app based on that logic and then market it to the appropriate sectors of the design and construction industries. Utility apps are more complicated to build than a Brochure app and will cost more to develop, but you gain the opportunity to differentiate yourself in the marketplace and earn additional returns on your IP. Remember also that you are not competing in the $0.99 game market. The price of your app can and should reflect the value it delivers. A utility app is typically self-contained and does not require network connectivity to be usable.
  3. Data Apps.  A data app retrieves, processes, and presents information from a remote source, such as database server at your company, or from publicly available sources such as Google. They can be view-only, or they can be designed to allow information to be updated. At this point we cross the line into a new level of complexity – the so-called “back end server” that the app communicates with in order to retrieve and update data. Usually, this means that a network connection will be needed for the app to be useable, and you’ll need to consider if that’s realistic for your users.  Will they need to use your app in places without wireless coverage? If you are building a Data app from scratch, this means you now have two parts to your design: the “front end”, being the app itself, and the “back end”, which is a web-based service you will either have to build from scratch or build as an interface to the public data source you need. Data apps are consequently more complicated and costly to build, and may require multiple skill sets and more than one type of software developer. Not all iPhone developers, for example, are capable (or willing) to do back end server programming.  Back end servers also require regular care and feeding, so you will want to factor that into your costs.
  4. Transactional Apps.  A transactional app allows your customers to transact business with you. This could be anything from scheduling appointments to actually purchasing products and processing payments. Transactional apps are the most complicated and costly to build (Disney-quality games excluded), have the front and back-end design of a Data app, and may need to be interfaced with one or more of your existing business systems.

Hopefully I’ve been successful in helping you see that building apps can be just as challenging as traditional software applications, because…they are traditional software applications in most respects.  Some apps can surely be built in a weekend by a nephew (if he’s a good software designer and a talented graphic designer), but the time-honored mantra of “you get what you pay for” still applies.

Having fully convinced you last time that your business needed a mobile software strategy (I did, right?) , my goal here was to help you begin to understand the scope of what’s involved.  If you have questions or want to go deeper, please feel free to contact me.

What kind of apps is your business using or planning on building?

 

Why Your Business Needs a Software Strategy

If you follow the tech blogosphere at all, you’ve undoubtedly read that we’ve moved into a so-called “post-PC” era, where mobile devices are seen as having usurped traditional desktop/laptop technology. Whether or not you agree that such a transition has actually occurred, the exponential growth in the use of mobile devices is certainly undeniable.

The upshot of this growth is the equally undeniable ramifications for business. There is great opportunity to be had, but a bit of new thinking and a willingness to embrace new challenges is required.

We know for certain that growing numbers of our existing and potential customers are now carrying app-capable devices on a 24-hour basis. They can, and increasingly expect to be able to interact with our businesses whenever they wish, regardless of where they happen to be. On top of that, they are expecting that functionality and experience to constantly improve.

Clearly, the mobile app is the secret sauce that makes it all possible. Without apps (and often the backend servers that support them), mobile devices have little value except perhaps as a phone. The new reality of being able to transact business in the palm of one’s hands, and in some cases having products delivered there as well, means that software, not the device, is the new coin of the realm.

The classic factors that drove your business in the past are now driving the need for your business to have a mobile software strategy going into the future:

  1. Customer demand. Increased mobility is driving an increased desire among customers to transact business on their mobile devices. The good ole’ face-to-face method of delivering your products and services may no longer be good enough to keep you competitive. Much like having a good website has become a necessity for being credible, so too will having one or more meaningful apps.
  2. Revenue growth. Your company’s IP is a potential goldmine. If you’re in the services business, you’ve accumulated a tremendous amount of intellectual property that can be monetized in new ways. What industry specific information or processes do you possess that can be delivered via mobile app? How might such an app be able to expand your markets and increase revenues? Think of it as using a power driver vs. a screw driver.
  3. The barrier to entry (i.e. cost) is relatively low. Developing apps for your business does not necessarily mean a substantial investment in your own in-house development team. If you do choose to keep things in-house however, the tooling required to build apps has never been better or more affordable, and the talent pool of competent app developers is growing daily. Out-shopping the development can be done affordably onshore or offshore. Depending on your target audience, marketing your apps could be more of a challenge than actually developing them. Your existing customer base is a great a place to start. If you can get them excited, they will get the word out for you.
  4. Competitors. Your competitors will have a mobile strategy. Count on it. Chances are good that some of them have not only crafted their mobile software strategy, but are already executing it.

The rise of mobile software provides an unprecedented opportunity to bring existing customers more value and expand into new markets at lower costs. A good app strategy can also tighten the relationship with existing customers and turn them into Raving Fans that bring new customers. So rather than think of it as just Yet Another Thing IT needs to do, consider viewing mobile software as a key enabler for improving business performance.

What ideas do you have for converting your IP into valuable apps?

Keeping IT Real

While my current job title is technically (no pun intended) Chief Technology Officer, a good portion of what I do falls within the job description of a typical Chief Information Officer. As such, I have peers in both the CTO and CIO worlds. The language spoken by my CTO friends is usually laced with techno-buzzwords and acronyms, whereas the lingo of my CIO friends tends to be less technical and more process, metrics, and governance oriented. These men and women are incredibly talented in their respective positions, yet it is surprising how often I find both camps missing the mark on what IT is really all about.

Simply stated, IT is about business outcomes. A CIO/CTO is not finished when the technology is installed – he or she is finished only after the expected business outcomes are delivered. When you begin to look at IT in this light, it becomes apparent there is no such thing as an “IT project”, but rather only business initiatives focused on a particular outcome to improve business performance. Framed this way, waxing eloquent about how great new technology XYZ is, or bragging about system up-time is obviously quite out of place when the CIO is meeting with the executive management team. No one cares about how fabulous the plumbing is – they only care about how business performance is being improved.

If you are willing to go with me this far, then I would lay out the following strategy to make IT successful. This strategy is not completely original to me, but it’s a proven one that I’ve tuned slightly over the years and is currently the model that the CIO side of my brain operates under.

  • Avoid Stinkin’ Thinkin’. There are certain “classic” ideas about IT that seem right, but really hamper its ability to be effective. Ideas like “we have to align IT with the business” or “the business is IT’s customer” come to mind first. These sorts of notions imply that IT is somehow not really a part of the business, but just a necessary evil whose cost needs to controlled and minimized. To move the business forward, IT must be viewed as an integral part of the business and the mission. Doing this successfully requires IT to be focused on business outcomes, rather than inwardly focused on itself.
  • Show that IT provides value in terms the business understands. While it’s true that what can’t be measured can’t be improved, measurements that aren’t meaningful to decision makers aren’t helpful either. So instead of reporting that the database servers were up 99% last month, report it in terms of the business processes that depend on them. It’s much more meaningful to say “the Order Entry system was available 99% last month” (or put another way, it was down only 7 minutes at 3 AM). IT management dashboards should be focused on business process performance, not IT infrastructure performance.
  • Show how IT can improve business performance. First, help senior management understand their needs and relate the appropriate technology to them in language they understand. This requires a lot of listening and good communications skills, but you must have clarity before going any further. Help them prioritize the results into various initiatives, and then execute those initiatives on time and on budget. Last but not least, circle back to ensure the expected benefits are realized.

Back in 2009 I wrote a short post about the purpose of infrastructure, and what I said then still holds true from the point of view of those involved in the daily care and feeding of IT. As IT leaders, however, we must take a higher view – real IT delivers business outcomes, not just up time.

//spk