The Industrialization of Mobile

I am on the board of Sitrion, who just released their latest version of Sitrion ONE, which allows enterprises to deliver mobile solutions in one single day.

Many companies travel a long and interesting journey. When we invested in NewsGator in 2004, RSS was just starting to emerge as a protocol and wire up much of the content on the web. At the time, it was impossible to anticipate how the web would evolve, as 2004 was a particularly low point in the evolution of venture capital and tech companies. Of course, it was also the year that Facebook was founded, which is an important thing to remember about the relationship between perception in the moment and long term reality.

A little over a decade later, mobile is dominating much of the growth of the web. Every company we are involved in is working on a mobile app. Every Fortune 1000 company I’m in touch with is focused on its mobile strategy and figuring out how to build and deploy mobile applications to its employees, many of them who are now engaging in BYOD where their personal mobile device and work mobile device is the same iPhone or Android phone.

A year and a half ago NewsGator acquired Sitrion to expand from their historical Microsoft SharePoint ecosystem product footprint to include SAP via Sitrion’s products. We decided to rebrand the company Sitrion as we liked the name better. As a hidden gem, we got the beginnings of an amazing mobile product that Sitrion had started working on.

NewsGator also had developed key mobile technology, especially for the enterprise, but with a tight dependency on SharePoint. Last year the combined product team stepped back, thought about what it had, and redefined the vision of the company around the notion of “the industrialization of mobile.”

Daniel Kraft, the CEO of Sitrion, has a very simple explanation of what the product and team addresses. Today, mobile apps are hand-crafted solutions for a specific use case. Accordingly enterprises make investments in very specific projects and just start to look for ways to mobilize their entire workforce.

Instead of building a new app for each use case, Sitrion provides the customer with one app for each platform (iOS, Android, Windows Phone) and pushes all the required services (micro-apps) to this app based on people’s roles, context or even behavior. As a result, you can create many custom apps, for specific use cases, without having to have a developer create multiple apps.

We think this will result in up to 90% reduction in development costs as you actually don’t need any OS developers. Time to market is correspondingly faster and TCO drops dramatically. Instead of an employee having 25 different company apps on their BYOD phone, they have one “container” app with 25 micro-apps.

What do you think? Are we in front of an industrialization of mobile, or are enterprises just slow and need to wait many more years for mobile being the main way things get done in large companies, just like how it’s playing out with consumer behavior?

  • I think Mobile is like the Web in the early 2000, every enterprise wants to have it but they don’t know why they need it. It all seems like a good idea. That being said, with strategic insight and real value proposition, it can really serve/solve use cases. Anything that enables this trend should be valuable. My bet is you are maybe a little ahead of the curve but that is a good thing right? What was that we overestimate the next 1 year and underestimate the next 10 years?

  • Rick

    Umm… That doesn’t make any sense. Just because you have a “container application” that runs apps inside it doesn’t mean it will reduce 90% of the dev time. The container application is only 10% of the work. The micro-apps, what I called rain drops in my cloud EMR system, will still need to developed. Those are 90% of the dev work.
    .
    Can you explain better Brad. As I’m sure you know. I like to bust your balls. But this one really does seem nonsensical. I will say that container apps are a good thing. They’ve been used for decades to provide functionality filtered by a user’s authorization to company systems.

    • Chris Chaten

      Also, does the container model require compromised UI (it’ll be tough to act native in a single use container, no?)? The old model didn’t demand high quality UI for enterprise. New model is increasingly user friendly w/in enterprise.

  • Slim

    Creative people need quiet time to think. Many do not have or want an electronic leach. The work area is one you enter when you are ready to work. It makes for much better quality.

    • Rick

      Thank you Slim and I agree.

    • Daniel Kraft

      What mechanism would you like to see to give you access to anything you need to get your job done, while away from your desk?

  • Brian Kellner

    Rick, you’re right that there’s much more to creating an enterprise mobile solution than just the app part. ONE is actually an entire platform that includes connectors to work with backend systems. So it not only insulates developers from needing to do any native mobile development, but it also actually generates code to talk to SAP, SharePoint and Salesforce. So you can build a ton of these use cases with just point and click. The container and deployment model is super-slick for getting the right functionality to the right people, but it’s only part of the story.
    Chris, you’re right that the user experience really matters. The ONE client actually is all native and the micro-apps are native on the phone as well (even though the developers never write native code). ONE focuses on use cases around approvals, information updates, and quick data lookup or data entry (e.g. submit a vacation request). So it has a nice, clean and friendly UI for those cases, and customers tell us they like having consistency in appearance and behavior around these use cases (as opposed to training their users on a dozen different approval apps). That said, ONE is not the platform to use if you’re creating a highly customized use case (e.g. a visual product configurator probably isn’t a great fit).

    • Rick

      “actually generates code”
      .
      I did that with my EMR system. I wrote a DSL (domain specific language) that generated code. That’s something I like to see in software development. Visual development and generating code is the proper way to quality software.

  • Harsha G

    One big difference versus consumers, in the enterprise most people have their PC most of the day and so that might be the preferred way to access company related stuff (at least I do). But, might really take off in companies were many employees don’t have desk jobs…

    • Daniel Kraft

      Harsha, is that the case? I would love to get more data. I hear this a lot and when digging deeper, even the people with their PC ask for the ability to do the little things on their phone when waiting for the elevator, the coffee break, the end or beginning of a meeting. Any insight you have would be much appreciated.

      • Harsha G

        Daniel, It feels to me like most people would prefer to use the bigger PC screen, since they are stuck to it anyways. My guess is during breaks, people do non-work stuff mostly. But, that’s just my opinion and I don’t have any data to back it up:) That said, I could definitely see people using mobile to complete simple tasks during endless meetings…

        Also, the more I think about it, it’s not a matter of % of employees needing it, but the absolute number. Every company has folks who are not at desk all day or travel a lot (sales, marketing etc) who would benefit from an app like this and that might be enough justification for bigger companies to invest.

        Good luck with your product!

        • Daniel Kraft

          Thanks Harsha!

  • JLM

    .
    Part of the discussion about mobile has to be the continually increasing capabilities of the devices themselves.

    Mobile two years ago is dwarfed by what mobile is today. I lug around a Samsung Mega and it already is a damn good little phablet.

    At the tablet level, mobile is almost as good as a desktop, certainly a lap top.

    With bigger and faster smartphones, the convergence between smartphones and tablets and laptops is moving faster than ever before.

    This notion of convergence is a hidden trend that is not discussed enough.

    Mobile will not only be where people are, it will also grow so rapidly in capabilities it will be where stuff gets done.

    JLM
    http://www.themusingsofthebigredcar.com

  • ian_peterscampbell

    The answer depends largely on what the technology really proposes to do. I think there are generally three categories of solutions that what you described could be: mobile web aggregation, client side HTML5, and auto–generated native code. For each:

    If you’re talking about an app that creates a container space with some glue logic and presentation helpers for a variety of internal web apps? That might be pretty helpful from the standpoint of pulling together the entire suite in an access-managed way, and could provide some nice helpers between “apps.” It would remove the need for most native code, but it would shift the work to mobile web development. Less expensive yes, but not 90% less by a long shot. Also the value proposition seems a little shaky unless it’s providing something really interesting on the InfoSec side.

    If you’re talking about an app that contains multiple “apps” with client-side HTML 5? That has a lot in common with the first solution. It will allow some improved UX (though I have not experienced that as a primary concern of the enterprise, historically). It will still require mobile web development, and since it becomes more client-side will require more fit and finish work after it’s all generated, for the suite to really be able to get good interoperability between the constituent parts.

    If you’re talking about auto-magically generated native code that mirrors/duplicates internal web and desktop tools in an attractive way? Well that would be pretty incredible. It would also be very challenging from a technology standpoint. I’ve never once seen a platform to auto-generate or translate code that wasn’t like an ill-fated flight over a desert: making amazing progress quickly right up until the point it dumps you in the middle of nowhere to die of thirst. The sheer difficulty of getting that right might be mitigated by only dealing with a limited number of enterprise platforms, which would limit the functionality somewhat but might not matter since a lot of enterprise companies use a pretty limited set.

    I’m very much in agreement that there’s a heck of a business to be built around obviating the need for any mobile development by big companies that want to offer all their tools to employees on mobile. But…I’m VERY leery of claims that mobile development has been “solved” (I’ve heard it a dozen times in the last decade) and this historical evidence has been that native mobile development still holds a lot of advantages. I’d love to see a disruptive innovation prove me wrong.

  • JonathanBowden

    Brad, you bring up some great questions here. From my experience of creating enterprise mobile apps both internally at Dell, as well as an outside consultant to many fortune 500 companies, I have a strong resistance to the “container app” idea.

    As anyone who has worked in corporate america will attest to, one of the biggest problems organizations face is the over complication of tools and systems. Having focused and lean apps to perform specific functions is a huge benefit.

    I strongly feel the solution that is needed most is a simple single sign on.

    I would not mind having a folder of my companies apps on my phone, with a single sign on, rather than one large, bloated app I have to wait on to open, for each action I want to take.

    But that is just my two cents. How do you feel about this alternative solution?

    • MarkusDopp

      You are making some very valid points Jonathan. We also see that solving the users login challenge is a core value proposition for us. That’s why Sitrion ONE can authenticate against already well established enterprise identity infrastructure such as ADFS and then impersonate into on-prem systems like SAP, SharePoint and others.

      I slightly disagree with your single app resistance comment 🙂 We do not want to mobilize complex backend applications by replicating their functionality. For instance we don’t want to put a full blown CRM transaction into the ONE client. What we are doing instead is supporting the user with mobile “moments”.

      Simple Example:

      1. Notifying a sales rep about an upcoming customer meeting (trigger comes from Microsoft Exchange) and automatically pushing a customer briefing card to the productivity stream of the ONE app (FY revenue, opptys, open orders etc. assembled from Salesforce, SharePoint and SAP data)

      2. Allowing the rep to check-in to the customer meeting and tracking that event in CRM

      3. Reminding the rep with a card and notification one day after the meeting that he/she can quickly track meeting notes.

      And there are a lot of other mobile moments that make employees more productive and more engaged:

      – Corp Comm posts for blue collar workers delivered securely to their personal device
      – Approval capabilities across all on-prem and cloud systems in one single app for managers
      – Quick data entry & lookup use cases (e.g. request time off and automatically activate OOF message, temporary open benefits enrollment access etc.)

      All sophisticated use cases can still be build on a custom basis, but a lot of corporate uses cases are just too cost prohibitive with custom app development.

      We believe that combining these lightweight mobile moments with enterprise Single-Sign-On and a consumer style UX is really making a difference.

      Would love to discuss with you what other challenges you are seeing in the enterprise mobile space given your experience and background. Please ping me via email or Twitter (@markusdopp)

      • JonathanBowden

        Thanks for the thoughful response Markus! I just watched the youtube video demoing the app, and it does look promising. Curious, how has your adoption rate faired, and what have been your biggest challenges?

    • Rick

      It sounds like ONE provides a layer that provides “by convention” commonality. Kinda’ similar to an ORM.

  • Brian Kellner

    I think the best way to think about ONE is your third category – except, for some destinations, we say, “We don’t fly there.”
    The reality is that with any complex problem, you accept tradeoffs when you try to reduce the complexity. A lot of mobile development approaches try to allow for any kind of mobile experience to be created. We’re choosing to constrain the range of possible experiences, but still covering a huge portion of the use cases we see from enterprises. In exchange for accepting that constraint, we get native clients, native behaviors, really fast development, and immediate deployment without users needing to take action.
    Our theory is that every company has a ton of these use cases and would like the speed and cost reduction in solving them. So I anticipate that most large enterprises will have ONE (or something like it) to solve these general cases, and they will have custom, native development to solve other use cases.

  • Inserting an abstraction layer to try to hide the underlying details of
    your platform is hardly an earth shattering technique. You’d be hard pressed to find an example anywhere in the software stack where they provided 90% of the development cost being reduced. If you get 25%, you should consider it a major victory. More likely your dev costs will be comparable to other designs over time.

    Also, as was pointed out by another commenter, the constraints on the design (UI being just one part) imposed by the API associated with the platform layer will have to be repeatedly dealt with as the system evolves. These troubles in my experience are exponential with the number of underlying platforms, not just linear.

    • Rick

      I’ve used a drag-n-drop component based dev environment for years and they can reduce dev time by a bunch. The key is *properly designed components*.
      .
      Keep in mind for every assumption made flexibility decreases.

  • Blake

    I’m guessing that the “up to 90% reduction in development costs” figure is a comparison of app development on this platform vs. building one iOS, one Android, & one WinPhone app.

    Notice he said “costs” not “time”. This means fewer devs with a smaller skillset, and fewer development environment licenses.

    My cynical side would say “yo dawg I heard you like app stores so I put an app store in your app store” etc. Or that some talented JavaScript programmers could just use a good IDE to make a web app that runs on all these platforms (as well as the desktop, etc); (see also Eclipse Orion, Eclipse ECF, & Firefox OS).

    However I think this product is very well targeted in focusing on enterprise developers that are convinced that “mobile apps” are the way they want to move forward, of which there seem to be a growing number. Developers that need to roll out one (usually fairly simple) app that works on every employee’s BYOD. You don’t need a large-scale public ecosystem, you just need to support the developers’ corporate ecosystem.

    I’d postulate that the make or break factor for this product (at least concerning product itsself) will be the quality & flexibility of the development environment, & the speed at which simple stable apps can be churned out & deployed to employees’ devices.

  • Victor Muthoka

    Mr. Feld, how can I get in touch with you?

  • This sounds very similar to Feed Henry: http://www.feedhenry.com/

    I see it uses Visual Studio and .Net? I’d guess it is still HTML5 based like Feed Henry. Unless maybe it uses mono like Xamarin? That would be incredible.

    Mobile development is hard…..period. I’ve developed with native, HTML5/Phonegap, and I’m currently using Xamarin which I LOVE. But all these their advantages, disadvantages and unique challenges.

    From the developer perspective, this sounds like a fantastic solution for Enterprise. Automating the ability to develop and deploy to ios, android, Windows is a beautiful thing. I wonder if it has it’s own cloud component for if it’s local to the enterprise (or both).

    Enterprise sales can be so rough. But they also use numerous platforms and if Sitrion can pull all those together in a single mobile app then it could be a no brainer.

    I can see it as a huge win for CTOs and IT depts that are overworked and looking for a way to make their company more productive while keeping the budget from exploding.

  • Rob

    Yes, I think you are a bit out front, but not the only player obviously. Salesforce has had this same concept in the hands of its customers for 2+years now. Of course you need to develop the solution on the Salesforce Platform, but it is a pretty strong platform. What you might want to think about is allowing people to develop once for every other platform as well. So if you develop for the regular web/laptop/desktop, that the same experience moves natively over without any additional work to the mobile device.

  • RBC

    Hey Brad, circling back after thinking about this for a day. This could be a good roll-up, your reputation certainly precedes you on that front. However I’m skeptical about apps as containers. I would recommend this 17 min video from Andrew Betts who designed the FT’s web app. It talks about building the front end using components.

    It is hard to pull complexity out of B2B organisations, and if I hear one more person say they are going to abstract it I’m might blow a gasket. Ramble over, but check out this video, I double dog dare you to say it isn’t cool 🙂

    http://youtu.be/oHB74_vQPrU?

  • martinsnyder

    I’m wondering about the world of December 2016, when everyone already has the big iPhone they want, and Windows 10 is rolling out across phones, notebooks, and tablets….will that begin to change the meaning of “mobile” as we know it?

  • Rick

    Brad,
    You should do a podcast like Fred.

  • Roopa Dharmapuri

    We built a similar “Apps Dashboard” – but all that we meant for it to do was allow a bunch of enterprise URLs, wrapped into mobile web clips deployed inside the dashboard as min apps. If the mobile app needs to be feature rich, it becomes inevitable that the underlying OS capabilities have to be heavily used – and that heavily differs across platforms. Add to it the complexity of enforcement of enterprise policies, security/key management and slick UI to top it all, the complexity becomes non-trivial. That said, one mega app/framework certainly has key benefits like SSO, centralized notifications, etc. Keen to watch how Sitrion evolves!

  • Sprugman