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. SaaS – Software 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. IaaS – Infrastructure 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?

In June of 2006 I went down like a ton of bricks on a basketball court with an Achilles tear of epic proportions. “Spaghetti” was the term used by my doctor.  It is a 6-month ordeal experience one does not forget, and I now often observe analogies to it in other things, most recently “The New iPad.”

The new iPad, or iPad 3, features Apple’s Retina display – crisp, vibrant, and beautiful, brought about by a doubling of the screen’s resolution by jamming in four times as many pixels. Ostensibly this should be nothing but a plus for the iPad 3, but in certain use cases, the Retina display is really an Achilles heel in Trojan Horse clothing.

While Apple upped the ante on the display resolution and threw in a quad-core GPU to handle it, the new iPad’s A5X CPU is basically the same dual core processor running at the same speed as last year’s iPad 2. And herein lies the Achilles heel. Depending on the app you’re using and how it was written, performance may actually be poorer on the new iPad.

Apps that require heavy CPU (vs. GPU) power to render images, such as PDF-based applications and others that use methods like [CALayer renderInContext:], are now faced with making their calculations over 4 times as many pixels without any additional processing power. To the user, this reveals itself as sluggish performance, including noticeable lag when turning pages in apps like NextPage that display image-ladden PDFs. So we end up with a better display, but with potentially poorer performance.  The very popular Instapaper by Marco Arment was one such notable victim.

In several ways, this conundrum is much like an torn Achilles tendon for both iPad 3 owners and app developers alike:

1. It is inconvenient. An achilles ordeal includes explaining to your wife what happened, dragging your injured self to a doctor, followed by surgery, 90 days in multiple casts, learning how to get on/off the toilet using only one leg, months on crutches and wearing a high-fashion boot, weeks of physical therapy, and then eventually learning to walk again.  I was inconvenienced, to say the least.

iPad 3 purchasers are expecting a good experience, but depending on the app, which may have worked just fine on iPad 2, they are possibly now getting subpar performance. On the developer side, iPad developers have been ambushed with a problem they were not expecting, and quite frankly don’t have the time or inclination to handle.  Clearly, inconvenience all around.

2. It is painful. The actual rupturing of an achilles tendon turns out to be the least painful part of the process. Recovering from the surgery has it’s own amped up round of pain, and that comes with good medication, but nothing beats the first post-op procedure. Initially after surgery, my foot was cast in a downward pointing position, much like a ballerina. After the tendon healed (90 days in my case), they cut off that cast, taking some of my skin with it, and then straightened the foot to a normal position. This requires the stretching of a mended, but never-before-streteched tendon that doesn’t want to be stretched, sending one into a realm of pain that may not quite approximate childbirth, but has to be darn close.

App developers who have to deal with iPad 3 rendering sluggishness may not have any low-pain solutions available either. In my own case, I was able to quickly pivot by rendering PDF pages to UIImages instead of directly to the screen. Others have not been so lucky, and have had to resort to schemes whereby they render new content in memory on a separate thread while the user is viewing the current on-screen content. Remembering that upgrades in the iOS and Mac App Store are free, developers aren’t going to get paid to fix this. A nice bit of insult added to the pain of injury.

3. It takes time. If you behave and do exactly as your doctor and physical therapist say, you can make a full recovery from an achilles injury, and I did. In 6 months I was walking normally, and in 12 months I could play sports again, though I thought it wise to retire from basketball. I had no interest in further refining my one-legged bathroom or driving skills. So too, depending on the app, it may be a long time before iPad 3 owners see the performance of their favorite-now-sluggish app get better. Eventually we will see an iPad with quad-core CPUs, and eventually app developers are likely to fix their performance issues on the new iPad. But in either case, it is going to take some time.

The new iPad’s screen is certainly sweet, but if you’re an iPad 2 owner, you may just want to hang on to it for another year. With the recent drop in price, it’s clearly the best overall “price performer” in the lineup until we learn about the specs of “the next iPad” (or “the newer iPad”, or “the 2013 iPad”, or whatever).

Have you noticed any app sluggishness on iPad 3?

Where on earth did that number come from? I was recently enlightened by @AndyAndrews in Mastering the Seven Decisions:

Going back through history we learn that:

• Four feet, eight and one-half inch spacing is what they used in England, and it was English expatriates who build the first US railroads.
• Prior to building railroads, the English built tram-ways on this same spacing, because they reused the same jigs, tools, and measurements that had been used to build wagons.
• The wagons used this spacing because it needed to match the ruts in some of the old long-distance English roads. Different spacing would have meant a lot of broken wagon wheels.
• The wheel-rutted roads through England were remnants of Imperial Roman Empire’s road system dating back to 43 – 410 AD. Turns out the famous Roman war chariots also had a wheel spacing of four feet, eight, and one-half inches. Rome was all about standards, so all the chariots were the same, and the roads got grooved over time.

So today, we have US railroads built to the standards of the old Roman war chariot. And why? Because there is natural tendency to become accustomed to the ways things are and do things the way they’ve always been done. Perhaps it was the old English wagon builders who coined the phrase “if it ain’t broke,don’t fix it.”

Fast-foward to the US Space Shuttle program. We’ve all seen the pictures of the shuttle waiting for lift-off and can probably remember seeing the solid rocket boosters (the two smaller cylinders on either side of the main tank, known as “SRBs”.) separate during flight and float back to earth. The SRBs were manufacturered on the other side of the country from Cape Canaveral and had to be shipped by rail over track that passes through tunnels; tunnels whose width is governed by the width of the…yes, you guessed it…the spacing of the rails. So even though the shuttle engineers may have preferred to make the SRB’s larger, it seems that the Romans actually had the final say on the design specifications.

The take-away is this: From what perspective are you making technology decisions (or any decision for that matter) for your business? Are you making them based on the way things have always been done, or are you taking new possibilities into account? Are you trying to innovate on old models because they’re familiar and safe, or are you willing to explore new models that can give you a decided edge, but might stretch you a bit?

I have a friend who has a fond saying when presented with a new and different idea, which, when sanitized for a PG-13 rating goes like: “What horse’s rear-end came up with this?” In a certain respect, he’s more right than he realizes, because the Roman war chariots were built to be wide enough to handle the back end of two horses harnessed side by side. So we can trace design elements of one of man’s greatest technical achievements back to a horse’s rear end. Marvelous. I’ll never be able to look at the Shuttle the same way again.

Have you become conditioned to doing things the same old way? Is it holding you or your business back?

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.

2. 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.
3. 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.

4. 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?

The ultimate goal of Inbox Zero is pretty simple – empty your inbox every day. Sounds impossible. I realize the notion of an empty inbox borders on heresy for the email packrats among us, but don’t bail out just yet. Email, left unmanaged, becomes a stumbling block to your productivity. It is an insidious way for others to inject their priorities in front of yours. As a test, ask yourself a couple of questions:

• How often did you check your email today (include smartphone access during visits to the restroom.
• Did you handle it (or try to) right away? What important things on your to-do list will not get done today because you did?

Somewhat ironically, email can easily become a productivity killer, but it doesn’t have to be. Unfortunately, our competence is often judged by how quickly we respond to email, so being responsive is important. The key to staying sane and productive is having a system that helps you decide what’s worthy of your attention Right Now and what isn’t. Try the following process for at least 30 days and see what happens.

1. Pick two times of the day when you will empty your inbox. Only two times? More heresy. Process does not mean answer every email. Process also does not mean check. Clearly, you need to be on the lookout for email from your boss and clients throughout the day, but don’t get caught in the trap of answering all of it each time you check it. What process does mean is going through step 2 below. My processing times are 30 minutes before I leave for work and 30 minutes before I leave the office. That way I arrive at work ready to get started on my task list, instead of my email, and leave the office with a clean slate for the evening. I do sporadic checks throughout the day to stay responsive to my boss and time-sensitive business matters with clients.
2. Keep moving and do not chase the rabbits.Many emails have a rabbit inside that wants to be chased Right Now. For each and every email, ask yourself, “Is the sender asking me to do something?” If the answer is yes, do one of the following:
   • Do It.If it looks like something you can do in 2 minutes or less, do it right now. You will appear responsive because…you are. And practice the Golden Rule of Email – if you can handle the response either in person, via phone call, or IM, do it that way. Don’t send another email and fill somebody else’s inbox, especially if the person is in the office right next to yours.
   • Delegate It. If you’re being asked to do something that can best be done by others, pass it on. Don’t feel as if you’re Passing the Buck, but rather that you’re making the best use of your time. Respond to the things where you alone can add value, and refer the rest to others.
   • Defer It. If you can’t do it in less two minutes, and can’t delegate it to someone else, add it to your to-do list with an appropriate priority. Resist the temptation to disrupt your schedule by working on it Right Now. Remember, no rabbit chasing!

    

   

   If the sender is not asking you to do something, then you can either:

• Delete It. The “Delete” function in most email programs is often lonely. Ask yourself whether you really will ever need this again, and if the answer is no, simply delete it without hesitation. This is probably the hardest thing I am asking you to do, but remember, chances are good that if you ever would need it again, the sender or another recipient will still have it. Otherwise:
• File It. Over the years I have tried using various folder schemes using dozens of folders to categorize email that I wanted to keep. I wish I had all of that time back. It never really paid any dividends because I always ended up using the email program’s search function to find what I needed. Today I use just one folder called “Processed”, where I file everything worth keeping. In fact, in Outlook I have a shortcut that moves an email to my Processed folder with one click. Outlook, Apple Mail, GMail, Thunderbird, and their brethren all have search functions that can easily find any email you might ever need to retrieve. One folder = no wasted effort.
3. Use email rules for your opt-in emails. Besides the “Processed” folder, I keep a second folder for email newsletters, and any other communications I have signed up to receive. I then set up email rules to automatically move these from my inbox to this single folder where I can peruse them during my reading time. Apple Mail and Outlook make setting up rules extremely easy.  It doesn’t require a degree in Advanced Geekery, and is well worth your time to put into use. Rules could also be used to move any email you’ve only been copied on to a “CC” folder.” By definition (in theory anyway), CC’ed emails shouldn’t require your immediate attention, but it might be useful to single them out for review before filing or deleting.

It really is possible to keep up with your email. The small amount of effort required to put a strategy in place like the one above will ultimately save you time and make you more effective.  Not to mention the good feeling you’ll get from regularly seeing an empty inbox!

What other strategies do you use to control your email?

Ten years ago, well-known software business owner Joel Splosky wrote a great piece about productivity in his work life called “Fire and Motion“.  Says Joel:

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you. (That’s what the soldiers mean when they shout “cover me.” It means, “fire at our enemy so he has to duck and can’t fire at me while I run across this street, here.” It works.)  The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you’re not moving, the enemy gets to decide what happens, which is not a good thing. If you’re not firing, the enemy will fire at you, pinning you down.

The message for us in the context of a mobile software strategy is two-fold:

Last week saw Apple effectively using the Fire and Motion technique, as “The New iPad” became the latest round of fire thrown down at the would-be competitors in the media-tablet space. Apple continues to gain ground, while keeping the rest of the industry on its heels playing defense. This is a model of success we can emmulate in our own businesses by building a plan to innovate with software.

How are you planning to use mobile software in your business?  If you’d like some feedback on your ideas, please leave a comment, or  I’d be glad to chat with you.

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?

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 resourceswill 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?

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?

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.