This five-part series of penetrating discussions on the latest in enterprise mobility explores advancements in applications design and deployment technologies across the full spectrum of edge devices and operating environments.
Here are some excerpts:
Gardner: Before we explore the Kony World news, what’s going on in the enterprise mobility marketplace? What are enterprises looking for in their mobility strategy?
Kawasaki: Obviously, mobility has proven that it’s not just a passing fad. It’s really evolved over the last four or five-plus years. Initially, most companies were just trying to get one or two apps out in the public app store.
Many started with some type of branded consumer apps, what are called business-to-consumer (B2C) applications, and they were willing to make the investments to make it have a fantastic user experience. They would try to make this a way for customers to experience and engage the brand. A lot of times you saw this being built and launched by the marketing organization inside an enterprise.
Now, what we’re seeing is a shift. As people are looking for the next set of ways to exploit mobility, they’re looking internal, inside their enterprise. They’re looking at what I refer to as or business-to-employee (B2E) applications.
But instead of one or two apps, there are literally dozens or hundreds of mobilized processes and applications that most larger enterprises are looking to build as they start looking at all the internal processes. It could be mobilizing sales or employees, looking at support out in the field with field technicians, or providing self-service access to vacation requests.
There are a number of challenges this creates. One is lack of skills. If you’re building one or two, you can probably muster the technical expertise or you can outsource and hire an agency or someone to build it. If you’re looking to supply dozens — some larger enterprises are looking at hundreds of internal-facing mobile apps — that really highlights the imbalance between the demand from the business stakeholders and the supply of IT skills, resources, and technical talent.
Build applications quickly
Kony, since day one, has focused on how to drive faster and faster acceleration of the full development process. That’s part of our core value proposition of rapidly delivering great mobile apps by providing tools and platforms to help build applications more quickly.
When we talk about building anything custom, there is a certain amount of time, typically three to six months that you spend, not just for the development, but to map out the requirements to do all the testing and final deployment. And with any custom software development, you can only compress it so far, and there’s a certain amount of skills and expertise that you need.
To answer your question, we think that there needs to be other types of models for ultimately creating these internal mobile applications. The trend that you’re starting to see, and that we believe is really going to take off, is a move away from custom, bespoke development of each and every app, to much more of an assembly and configuration model.
If you look at building a home, for example, there was a time where you had to custom build all of the parts to your home. You would go out, cut down the trees, and do everything from scratch, but that was a hugely inefficient process.
Now, essentially, homes are componentized. You can find standard sizes lumber parts. Large parts of your home may be prefabricated and it’s just a matter of assembling and configuring them to meet your needs.
We’ve seen the same assembly across a number of industries, like the auto industry. Many industries have realized the benefits of moving to assembly and configuration, as opposed to custom built.
We’re seeing this in software as well. There was a day where everyone used to build their own enterprise resource planning (ERP) system or their own sales automation system. Now, people have moved to the configuration of packaged software. Mobile applications are now at the tipping point where they need to have a different way that will address the explosion in demand that I was describing.
There are a couple of things that we think are required to create this new model. One is that you need to have an ecosystem that provides pre-built components. Obviously, you can’t assemble things if there is nothing to assemble from. So there needs to be an ecosystem of components.
Then, there needs to be some type of tooling that allows you to assemble the components without having to be a developer, but more of a visual drag and drop type of composition experience.
And then once you have done that, it can’t just be a pretty picture. It needs to actually somehow run and make its way down to your phone or to your device. So there has to be some type of execution or dynamic run capability behind the description of what you have created.
Those are the three requirements. Of course, we have just announced this week some software that addresses each of those categories.
Gardner: Well, let’s delve into them a little bit. There were three major announcements around your Marketplace, your Modeler, and also an example of how these come together in your first prepackaged application called the Kony Sales App.
Kawasaki: I’ll talk about each of these. I’ll start with the Marketplace. As I said, to make this practical and useful for our customers, we need to be able to create a way to find and discover pre-built components. Some of these components Kony may build ourselves, but we’re also working with a number of very talented leading edge partners of ours — independent software vendors (ISVs) and systems integrators (SI’s), who are also contributing prebuilt components.
This week, Feb. 4, we launched Marketplace. If you go out to community.kony.com/marketplace, you can browse. We’re adding partners on an ongoing basis, but you’ll see some of the early solutions that are available in the Marketplace. That’s the first part of the announcement.
The second piece is around how to assemble these into an actual application, a new product called Kony Modeler. Unlike some of our prior products, our developer tools, these do not require development backgrounds.
The typical profile of a user of Kony Modeler would be either a business analyst or someone closer to the business who knows how to drag and drop, to define what the end-user experience should be for your mobile app, knows how to describe the process or the workflow that has to occur, knows how to take those forms that they’ve painted, and be able to map it to some backend business data, coming from a system like SAP or Salesforce.
As long as you can do that, you don’t have to be a developer and drop into code. You can describe this visually. You can drag and drop. Then, when you’re done, the important thing is that it’s not just a picture that you print out and you throw over the wall to your developer. This description of your application then gets pushed out instantaneously to our cloud run time.
We’ve extended our backend-as-a-service, what we call Kony MobileFabric, so that it takes this model, this description of the mobile app, and will download it to your device and run it. Then, the next time as an end-user, if you are using one of these apps, you just automatically get whatever changes or updates have been made. You don’t have to go out to an app store and find a new app. It just automatically is part of your app.
As an analogy, in the same way if I use any software-as-a-service (SaaS) software, I won’t have to install a new app on my laptop. I just go out to my web browser, and next time I log in, it’s always up-to-date.
Gardner: It sounds as if this has some of the greater elements of platform-as-a-service (PaaS), but the tooling is designed for that business-analyst level. It also gives you some of those benefits of rapid iterations. You can change and adjust. You can customize to different types of user within the group that you’re targeting. And all of this, I assume, is at also low cost, given that it’s a SaaS based approach. Tell us a little bit about why this is like PaaS, but PaaS-plus.
Kawasaki: PaaS typically has been targeted primarily toward developers. And it’s maybe a higher level productivity for developers, but you still have to write code against software development kits (SDKs) or other application programming interfaces (APIs). Kony Modeler provides a non-developer experience.
The other big thing, and you pointed it out, is that it really does lower all of the infrastructure, hardware, and software costs that are required, because it’s purely cloud-based. It makes it not only lower cost from a total cost of ownership (TCO) standpoint, but it also accelerates the whole development cycle.
I think about this as a shift away from a classic waterfall-type model, to much more of an agile model. In the old model, you spend three to six months trying to go through and nail the requirements and hand it off to your dev team. Then, they go off, and you find out, only when it’s in final QA, that it doesn’t look right on the device, or it comes back and the business has changed their mind. That never happens, right?
Modeler allows you to very quickly iterate a working application to release in a matter of days and be able to do testing with your end-users. Based on their feedback, I can make updates on an agile basis and continuously iterate on functionality or enhancements to the application.
Gardner: Burley, it also sounds like you’re able to bring A/B testing type activities to a different class of user, where you don’t always know what your requirements are precisely, but you can throw things on the wall, try them out, see what works, and iterate on that. I don’t recall too much of that capability being available to a business analyst type of user.
Kawasaki: You’re correct. Usually, there is this very extended process, where a business analyst has to document everything in some thick specification, and even if you have it wrong or you are uncertain, whatever you communicate out to the dev team is what they go off and build.
So it’s not that this does away with requirements, but it does allow more flexibility to change or to test. And I’d agree. I think the responsiveness will allow much more experimentation and innovation. It’s better to fail fast. If you have tried something out and it’s not delivering the results, you haven’t invested a huge amount of time and cost to learn that.
Gardner: And another appealing aspect of this for IT and operations is that this isn’t shadow IT. This is under the auspices of IT. They can bring in governance. They can audit as necessary and make sure the right backend sources are being accessed in the right way, with the right privilege and access controls. They can monitor security. We talked about how it’s better than PaaS, but it’s also better than shadow IT for a lot of reasons.
Lack of skills
Kawasaki: It is. We were talking earlier about the skills shortage, and if you look at the stats or the data, most industry analysts predict that up to 60 percent or 70 percent or more of mobile development is outsourced today, to either an interactive agency, a systems integrator, or someone else, because of lack of skills.
So it has been outsourced to some third party, and who knows what technologies they are using to build the app. It’s outside the typical controls or governance of IT. So it’s not only shadow; it’s dark matter. You don’t even know it exists; it’s completely hidden.
Yet, at some point, inevitably, those apps that you may have outsourced for your first version, it’s not just a first version release. You want to update it sometimes monthly. So it has to come back into IT at some point, for no other reason than it’s connecting and talking to enterprise data in the back end. It’s connecting to other IT controlled systems, and so there is a huge amount of risk and costs associated if these things are completely hidden off the grid.
Gardner: Let’s take this from the abstract to the concrete. We actually have an application now in play called the Kony Sales App. Who is that targeted to, how does it work, and what do you expect to be some of the proof point metrics of this in usage compared to how organizations conduct themselves with customer relationship management (CRM), especially if there is multiple CRMs in play in an organization?
Kawasaki: That’s a great point. First of all, this is the first of a series of what we call ready-to-run applications. And the reason we call it ready-to-run is that it’s a packaged app. This isn’t a custom or bespoke app, but it’s pre-connected and pre-integrated to the common back end, in case of CRM what most companies are using, something like Salesforce or SAP on the back end.
So it comes ready to run, but like packaged software or SaaS software, it allows you the ability to configure and customize it, because everyone’s sales processes or their user base is going to be different. That’s where the Modeler tool allows you to configure it.
So when you purchase Kony Sales, you get not only the application, but the use of Kony Modeler to be able to customize and configure it. And then, as you make changes, you push it live, and again, it deploys using the SaaS model you were describing.
To talk a little bit more about Kony Sales, we think it’s a new style of mobile apps, what I will refer to as a micro app. Historically, people thought of CRM software, and I am overgeneralizing, but as big, somewhat monolithic, applications.
One of the historical challenges with CRM usage is that you had to bring your laptop with you, and sales reps are notorious at not completing data in a timely fashion. It takes a lot of mandates, top-down from the sales leadership, to get data into the system so you can get accurate reporting. It’s one of the age-old problems.
We believe that if instead of trying to get the whole CRM application crammed down onto a four-inch screen, with all the complexity that it requires, you target very specific action-oriented micro apps that a sales rep can do very quickly on the go, that doesn’t take a lot of training, and doesn’t take a lot of thought. They can very quickly look up and see their accounts, or they can very quickly log a call they have made.
So we’ve taken a task-oriented approach and created a modular micro app approach that really is meant to be very easy and engaging for the end-user, which in this case is a sales rep.
Gardner: And again, for the understanding of how this all works across multiple endpoints, regardless of what your sales force is using for their mobile device, this is going to come down. They are going to get that user experience and that interface that the craftsmen behind the app demanded and designed.
Kawasaki: That’s right. Kony Sales is multi-channel. It works across phones, tablets, iOS, Android, and importantly, it does not replace your existing CRM data. It extends the CRM systems you already have, but makes them much, much easier to very quickly get access to.
Also using Mobile First types of approaches, and by that I mean if you are a sales rep, very likely you are on the road or in an airplane. How many people have tried to use whatever CRM client, even some of the web mobile experiences, to get data into Salesforce or SAP? It’s all web-based, HTML5-based, and it doesn’t work if you’re not online.
One of the things we designed in from day one was that you have to be able to operate in an “occasionally connected” mode. So if you are offline, either because you’re out in the field talking to your customer, or you’re in an airplane you can still have the same easy access. Then, when you’re connected again, it will synchronize and handle updating SAP or Salesforce in the background.
Gardner: Now that we have the model of the Modeler, the Marketplace and these ready-to-run apps, what comes next — more apps, bigger marketplace, or is there another technology shoe to drop?
Kawasaki: It’s more apps certainly, and not just from Kony, but from our partners. When we did some of our initial planning and research, the most commonly mobilized processes were ones that were customer facing or customer impacting, just because of the benefits and the ROI.
So we started with sales. We’re going to release our next one, which will be around field service. It really helps engage at the point that you’re supporting and serving your customer.
There are a set of these that we are working on, but I think also importantly, we’re working on really making our partner ecosystem trained, ready to use Modeler, and to build very unique and differentiated applications to publish to the marketplace.
We have a couple of examples of these ready-to-run apps that are compelling from our partners that you will hear more about, and that list will continue to grow over the coming weeks and months.
You may also be interested in:
- Kony gives enterprises the means to make mobile development a force multiplier for business productivity
- Panel tackles how to make mobile devices as secure as they are indispensable
- Five ways to make identity management work best across hybrid computing environments
- As the digital economy ramps up, expect a new identity management vision to leapfrog passwords
- Mobile enablement presents challenges, opportunities as enterprises retool apps for the future now
- Standards and APIs: How to best manage identity and security in the mobile era
- Microsoft SharePoint at a crossroads — opportunities and challenges abound for users to advance productivity
- Siemens Brazil blazes a best practices path to deliver work flow applications on mobile devices
- Why HTML5 enables more businesses to deliver more apps to more mobile devices with greater ease