 Hi, I'm Peter Burris and welcome to another Wikibon action item. Once again, we're broadcasting from the Cube Studios in beautiful Palo Alto. Here in the studio with me are George Gilbert and David Floyer and remote. We have Neil Raden and Jim Cabilis. Welcome everybody. Thank you. So this is kind of an interesting topic that we're going to talk about this week. And it really is, how are we going to find new ways to generate derivative use out of many of the applications, especially web-based applications that have been built over the last 20 years. A basic premise of digital business is that the difference between business and digital business is the data and how you craft data as an asset. Well as we all know in any universal turning machine, data is the basis for representing both the things that you're acting upon but also the algorithms, the software itself. Software is data. And the basic principles of how we capture software-oriented data assets or software assets and then turn them into derivative sources of value and then reapply them to new types of problems is going to become an increasingly important issue as we think about the role the digital business is going to play over the course of the next few years. Now there are a lot of different domains where there's might work but one in particular that's especially as important is in the web application world where we've had a lot of application developers and a lot of tools be a little bit more focused on how we use web-based services to manipulate things and get software to do the things we want to do and also it's a source of a lot of the data that's been streaming into big data applications and so it's a natural place to think about how we're going to be able to create derivative use or derivative value out of crucial software assets. How are we going to capture those assets, turn them into something that has a different role for the business, performs different types of work and then reapply them. So to start the conversation, Jim Kobielus, why don't you take us through what some of these tools start to look like? Hello Peter, yes. So really what we're looking at here in order to capture these assets, the web applications, we first have to generate those applications and the bulk of that work of course is and remains manual. And in fact, there is a proliferation of web application development frameworks on the market and the range of them continues to grow, everything from React to Angular to Ember to Node.js and so forth. So one of the core issues that we're seeing out there in the development world is are there too many of these? Is there any prospect for simplification and consolidation and convergence of web application development framework to make the front end choices for developers a bit easier and straightforward in terms of the front end development of JavaScript and HTML as well as the backend development of the logic to handle the interactions not only with the front end on the UI side but also with the infrastructure, web services and so forth. Once you've developed the applications, you are a professional programmer, then and only then can we consider the derivative uses you're describing such as incorporation or orchestration of web apps through robotic process automation and so forth. So the issue is how can we simplify or is there a trend towards simplification or will there soon be a trend towards simplification of the front end manual development? And right now I'm not seeing a whole lot of action in this direction of simplification on the front end development, it's just a fact. So we're not seeing a lot of simplification convergence on the actual frameworks for creating software or creating these types of applications but we're starting to see some interesting trends in for stuff that's already been created how can we generate derivative use out of it and also per some of our augmented programming research new ways of envisioning the role that artificial intelligence, machine learning, et cetera can play in identifying patterns of utilization so that we are better able to target those types of things that could be used for derivative or could be applied to derivative use. I got that right Jim? Yeah, exactly. AI within robotic process automation to anything that has already been built can be captured through natural language processing through computer image recognition, OCR and so forth and then trends in that way it's an asset that can be repurposed in countless ways and that's the beauty of RPA or where it's going. So the issue is then, not so much capture of existing assets but how can we speed up and really automate the original development of all that UI logic? I think RPA is part of the solution but not the entire solution meaning RPA provides visual front end tools for the rest of us to orchestrate more of the front end development of the application UI and interaction logic. And it's part of a broader loco phenomenon. Yeah, it's also popping up in a lot of the interviews that we're doing with CIOs about related types of things but I want to scope this appropriately. So we're not talking about how we're going to take those transaction processing applications David Floyer and envelope them and containerize them and segment them and apply new software. That's not what we're talking about nor are we talking about the machine to machine world. Robot process automation really is a tool for creating robots out of human time interfaces that can scale the amount of work and recombine it in different ways. But we're not really talking about the two extremes the hardcore IoT or the hardcore systems of record, right? Absolutely, one question I have for Jim and yourself is the philosophy for most people developing these days is mobile first. The days of having an HTML layout on the screen of gone if you aren't mobile first that's going to be in pretty well a disaster for any particular development. So Jim, how does the RPA and how does your discussion fit in with mobile and all of the complexity that mobile brings all of the alternative ways that you can do things with mobile? Yeah, well David, of course, low code tools and there are many, there are dozens out there there are many of those that are geared towards primarily supporting fast automated development of mobile applications to run on a variety of devices and mobile UIs and so forth. That's part of the solution as it were. But also in the standard web application development world is these frameworks that I've described everything from React to Angular to View to Ember everything else are moving towards a concept more the concept that's a framework or a paradigm called progressive web apps. And what progressive web apps are all about that's really the mainstream of web application development now is blurring the distinction between mobile and web and desktop applications because you build applications JavaScript applications for browsers the apps look and behave as if they were real-time interactive in-memory mobile apps. What that means is that they download fresh content throughout a browsing session progressively I'm putting the term in air quotes because that's where the progressive web app comes in and they don't require the end user to visit an app store or download software they don't require anything in terms of any special capabilities in terms of synchronizing data from servers to run in memory natively inside of web accessible containers that are local to the browser. They just feel mobile, even though excuse me they may be running on a standard desktop with narrow band connectivity and so forth. So they scream and they scream in the context of their standard JavaScript Ajax browser session. So when we think about this, it got, geez Jim it almost sounds like client side Java but I think we're talking about something as you said that evolves as the customer uses it and there's a lot of techniques and approaches that we've been using to do some of those things but George Gilbert, the reason I bring up the notion of client side Java is because we've seen other initiatives over the years try to do this. Now partly they failed because they focused on too much and tried to standardize or presume that everything required a common approach and we know that that's always going to fail. But what are some of the other things we need to think about as we think about ways of creating derivative use out of software oriented digital assets. Okay, so I come at it from two angles and as Jim pointed out there's been just a Cambrian explosion of creativity and innovation on frankly on client side development and server side development. But if you look at how we're going to recombine our application assets, we tried 20 years ago with EAI but that was sort of like MuleSoft but only was for on-prem apps and it didn't work because every app was bespoke. It worked for point-to-point classes of applications. Yeah, but it required bespoke development for every instance because the apps were so customized. And the interfaces were so customized. Yes. At the same time, we were trying to build higher level application development capabilities on desktop productivity tools with macros and then scripting languages, cross application and visual development or using applications as visual development and building blocks. Now you put those two things together and you have the ability to work with user interfaces by building on, I'm sorry, to work with applications that have user interfaces and you have the functionality that's in the richer enterprise applications and now we have the technology to say, let's program by example on essentially a concrete use case and a concrete workflow and then you go back in and you progressively generalize it so it can handle more exception conditions and edge conditions. In other words, you start with, it's like you start with the concrete and you get progressively more abstract. You start with the work that the application performs and not knowledge of the application itself. Yes, but the key thing is, as you said, recombining assets because we're sort of marrying the best of the EAI world with the best of the visual client side development world where as Jim points out, machine learning is making it easier for the tools to stay up to date as the user interfaces change across releases. This means that I wouldn't say this is easy as spreadsheet development, it's just not. It's not like building spreadsheet macros but it's more along those lines. Yeah, but it's not as low level as just building raw JavaScript because and Jim's great example of JavaScript client side frameworks. Look at our Gmail inbox application that millions of people use. That just downloads a new version whenever they want to drop it and they're just shipping JavaScript over to us. But the key thing and this is Peter, your point about digital business by combining user interfaces we can bridge applications that were silos then we can automate the work that humans were doing to bridge those silos and then we can reconstitute workflows in much more efficient and automated. Around the digital assets which is kind of how business ultimately evolves and that's a crucial element of this whole thing. So let's change direction a little bit because we're talking about, as Jim said, we've been talking about the fact that there are all these frameworks out there. There may be some consolidation on the horizon. We're researching that right now although there's not a lot of evidence that's happening but there clearly is an enormous number of digital assets that are in place inside these web-based applications where they'd be relative to mobile or something else. We want to create derivative views out of them and there's some new tools that allow us to do that in a relatively simple straightforward way like RPA and there are certainly others but that's not where this ends up. We know that this is increasingly going to be a target for AI, what we've been calling augmented programming and the ability to use machine learning and related types of technologies to be able to reveal, make transparent, gain visibility into patterns within applications and within the use of data and then have that become a crucial feature of the development process and increasingly even potentially to start actually creating code automatically based on very clear guidance about what work needs to be performed. Jim, what's happening in that world right now? Oh, let's see. So basically, I think what's going to happen over time is that more of the development cycle for web applications will incorporate not just the derivative assets, the AI to be able to decompose existing UI elements and recombine them, enable flexible and automated recombination in various ways, but also will enable greater tuning of the UI in an automated fashion through A-B testing that's in line to the development cycle based on metrics that AI is able to sift through in terms of different UI designs can be put out into production applications in real time and then really tested with different categories of users and then the best suited or best fit design based on reducing user abandonment rates and speeding up access to commonly required capabilities and so forth. The metrics can be rolled in line to the automation process to automatically select the best fit UI design that had been developed through automated means. In other words, this real world experimentation of the UI has been going on for quite some time in many enterprises and it's often increasingly involves data scientists who are managing the predictive models to very much drive the whole promotion process of promoting the best fit design to production status. I think this will accelerate, we'll take more of these in-line metrics on UI and they'll be brought I believe into more RPA style environments so that the rest of us building out these front ends or automating more of our transactions and we're animating more of the UIs can't take advantage of the fact that we'll let the infrastructure choose the best fit of the designs for us without us having to worry about doing A, B testing and all that stuff that the cloud will handle it. So it's a big vision, this notion of even eventually through more concrete standard well-understood processes to apply some of these AI ML technologies to being able to choose options for the developer and even automate some elements of those options based on policy and rules. Neil Raiden, again, we've been looking at similar types of things for years. How has that worked in the past and let's talk a little bit about what needs to happen now to make sure that if it's going to work, it's going to work this time? Well, it really hasn't worked very well and the reason it hasn't worked very well is because no one has figured out a representational framework to really capture all the important information about these objects. It's just too hard to find them, isn't it? Everybody knows that when you develop software 80% of it is grunt work. It's just junk, it's taking out the trash and it's setting things up and whatever and the real creative stuff is a very small part of it. So if you could alleviate the developer from having to do all that junk by just picking up pieces of code that have already been written and tested, that would be big, but the idea of this has been overwhelmed by the scale and the complexity and people have tried to create libraries like Java beans and object-oriented programming and that sort of thing. They've tried to create catalogs of these things. They've used relational databases, it doesn't work. My feeling, and I hate to use the word because it always puts people to sleep is some kind of an ontology that's deep enough and rich enough to really do this. Hold on, Neal, I'm feeling that. Yeah. Well, I mean, what good is it? I mean, go to Git, right? You can find a thousand things but you don't know which one is really gonna work for you because it's not rich enough. It doesn't have enough information. It needs to have quality metrics. It needs to have reviews by people who have used converging and whatever. So that's where I think we run into trouble. As far as robots, yeah. Go ahead. As far as robots writing code, we're going to have the same problem. No, well, here's where I think it's different this time and I want to throw it out to you guys and see if it's accurate and we'll get to the actual items. Here's where I think it's different. In the past, partly perhaps because it's where developers were most fascinated, we try to create object-oriented database and object-oriented representations of data using object-oriented models as we were thinking about it and object-oriented code and object-oriented this and a lot of it was relatively low in the stack and we tried to create everything from scratch and it turned out that whenever we did that, it was almost like case from many years ago. You create it in the tool and then you maintain it out of the tool and you lose all organization of how it worked. What we're talking about here and the reason why I think this is different, or I think Neil's absolutely right, is because we're focusing our attention on the assets within an application that create the actual business value. What does the application do and try to encapsulate those and render those as things that are reusable without necessarily doing an enormous amount of work on the backend. Now, we have to be worried about the backend. It's not going to do you any good to do a whole bunch of RPA or related types of stuff on the front end that kicks off an enormous number of transactions goes after a little server that's 15 years old that's historically only handled a few transactions a minute. So we have to be very careful about how we do this. But nonetheless, by focusing more attention on what is generating value in the business, namely the actions that the application delivers as opposed to knowledge of the application itself, namely how it does it, then I think that we're constraining the problem pretty dramatically subject to the realities of what it means to actually be able to maintain and scale applications that maybe ask to do more work. What do you guys think about that? Now, Peter, let me say one more thing about this now about robots. I think you're all a lot more sanguine about AI and robots doing these kinds of things, I'm not. Let me read to you three pickup lines that a deep neural network developed after being trained to do pickup lines. You must be a tringle because you're the only thing here. Hey, baby, you're to be a key because I can bear your toot. Now, what kind of code would? Well, look, the problem is, look, we go back, we go back 50 years and Eliza and the whole notion of whatever it was, the interactive psychology. Look, let's be honest about this. Neil, you're making a great point. I don't know if any of us are more or less sanguine and that probably is a good topic for a future action item. What are the practical limits of AI and how is that going to change over time? But let's be relatively simple here. The good news about applying AI inside IT problems is that you're starting with engineered systems with engineered data forms and engineered data types and you're working with engineers and a lot of that stuff is relatively well structured, certainly more structured than the outside world and it starts with digital assets. That's why AI for IT operations management is more likely. That's why AI for application programming is more likely to work as opposed to AI to, do pickup lines, which is, as you said, semantically, it's all over the place. There's very, very few people that are going to conform to a set of conventions for, well, I want to move away from the concept of pickup lines and set of conventions for other social interactions that are very, very complex. We don't look at a face and get excited or not in a way that corresponds to an obvious, well-understood semantic problem. Exactly, the value that these applications deliver is in their engagement with the real world of experience and that's not, you can't encode the real world of human lived experience in any crisp, clear way. It simply has to be proven out in the applications or engagement through people or not through people with the real world outcome. And then some outcomes like the ones that Neil read off there in terms of those ridiculous pick lines, most of those kinds of automated solutions won't make a fricking bit of sense because you need humans with their... Leave human engagement. So coming back to this, so coming back to this key point, the constraint that we're putting on this right now and the reason why certainly, perhaps I'm a little bit more abolient than you might be, Neil, but I want to be careful about this because I have some pretty, also have some pretty strong feelings about what the limits of AI are, regardless of what Elon Musk says, that at the end of the day, we're talking about digital objects, not real objects that are engineered, not have evolved over a few billion years to deliver certain outputs and data that's been tested and relatively well verified as opposed to have an unlimited, at least from a human experience standpoint, potential set of outcomes. So in that small world, and certainly the infrastructure universe is part of that, and what we're saying is increasingly the application development universe is going to be part of that as part of the digital business transformation. I think it's fair to say that we're going to start seeing AI and machine learning and some of these other things being applied to that realm with some degree of success, but something to watch for. All right, so let's do the action item. David Fore, why don't we start with you, action item. In addressing this, I think that the keys in terms of business focus is first of all, mobiles, you have to design things for mobile. So any use of any particular platform or particular set of tools has to lead to mobile being first. And the mobiles are changing rapidly with the amount of data that's being generated on the mobile itself or around the mobile. So that's the first point I would make from a business perspective. And the second is that from a business perspective, one of the key things is that you can reduce costs. Automation must be a key element of this. And therefore designing things that will take out tasks, and remove tasks, make things more efficient is going to be an incredibly important part of- And reduce errors. And reduce errors, absolutely. Probably most important is reduce errors is to take those out of the chain and where you can speed things up by removing human intervention and human tasks and raising what humans are doing to a higher level. Other things. George Gilbert, action on him. Okay, so really quickly on David's point that we have many more application forms and expressions that we have to present like mobile first. And going back to using RPA as an example, the UI path product that we've been working with, the core of its capability is to be able to identify specific UI elements in a very complex presentation, whether it's on a web browser, whether it's on a native app on your desktop, or whether it's mobile. I don't know how complete they are on mobile because I'm not sure if they did that first. But that core capability to identify in a complex, essentially collection and hierarchy of UI elements, that's what makes it powerful. Now on the AI part, I don't think it's as easy as pointing it at one app and then another and say, go make them talk. It's more like helping you on the parts that where they might be a little ambiguous, like if pieces move around from release to release, things like that. So my action item is to say, start prototyping with the RPA tools because that's probably, they're probably robust enough to start integrating your enterprise apps. The only big new wrinkle that's come out in the last several weeks that is now in everyone's consciousness is the MuleSoft acquisition by Salesforce because that's going back to the EAI model. And we will see more app to app integration at the cloud level that's now possible. Neil Raiden, action item. Well, you know, Mark Twain said there's only two kinds of people in the world. The kinds who think there are only two kinds of people in the world and the ones who know better. I'm going to deviate from that a little and say that there's really two kinds of software developers in the world. They're the true computer scientists who want to write great code. It's elegant, it's maintainable, it adheres to all the rules it's creative. And then there's an army of people who are just trying to get something done. So the boss comes to you and says, we've got to get a new website up, apologizing for selling the data of 50 million of our customers and you need to do it in three days. Now those are the kind of people who need access to things that can be reduced. And I think there's a huge market for that as well as all these other software development robots so to speak. Jim Cabela's action item. Yeah, for simplifying web application development, I think that developers need to distinguish between back end and front end framework. There's a lot of convergence around the back end framework specifically Node.js. So you can basically decouple the decision in terms of front end frameworks from that and you need to write up front. Make sure that you have a back end that supports many front ends because there are many front ends in the world. Secondly, the front ends themselves seem to be moving towards React and Angular and Vue as being the predominant ones. You'll find more programmers who are familiar with those. And then thirdly, as you move towards consolidation onto fewer frameworks on the front end, move towards local tools that allow you just with the push of a button of visual development, be able to deploy the built out UI to a full range of mobile devices and web applications. And I'll close my action item or my second what David said, move toward a mobile first development approach for web applications with a focus on progressive web applications that can run on mobiles and others. Where they give a mobile experience, though with intermittent connectivity with push notifications, but with a real time in memory, fast experience. Move towards a mobile first development paradigm for all of your browser facing applications. And that really is the simplification strategy you can and should pursue right now on the development side, because web apps are so important, you need a strategy. Yeah, so mobile irrespective of the underlying biology or what have you of the user. All right, so here's our action item. Our view on digital business is that a digital business uses data differently than a normal business. And a digital business transformation ultimately is about how do we increase our visibility into our data assets and find new ways of creating new types of value so that we can better compete in markets. Now that includes data, but it also includes application elements, which also are data. And we think increasingly enterprises must take a more planful and purposeful approach to identifying new ways of deriving additional streams of value out of application assets, especially web application assets. Now this is a dream that's been put forward for a number of years, and sometimes it's worked better than others. But in today's world, we see a number of technologies emerging that are likely, at least in this more constrained world, to present a significant new set of avenues for creating new types of digital value. Specifically tools like RPA, Remote Process Automation, that are looking at the outcomes of an application and allow programmers to use a by example approach to start identifying what are the UI elements, what those UI elements do, how they could be combined so that they can be composed into new things and thereby provide a new application approach, a new application integration approach, which is not at the data and not at the code, but more at the work that a human being would naturally do. These allow for greater scaling, greater automation, and a number of other benefits. The reality, though, is that you also have to be very cognizant as you do this, even though you can find these assets, find new derivative uses for them and apply them very quickly to new potential business opportunities, that you have to know what's happening at the back end as well. Whether it's how you go about creating the assets of some of the front end tooling or and being very cognizant of which front ends are going to be better or not better or better able at creating these more reusable assets or whether you're talking about still how relatively mundane things like how a database serializes access to data and will fall over because you've created an automated front end that's just throwing a lot of transactions at it. The reality is there's always going to be complexity. We're not going to see all the problems being solved, but some of the new tools allow us to focus more attention on where the real business values created by apps, find ways to reuse that and apply it and bring it into a digital business transformation approach. All right, once again, George Gilbert, David Foyer here in the studio, Neil Raden, Jim Kobielus, remote. You've been watching Wikibon's Action Item. Until next time, thanks for joining us.