Michael Facemire0:00
That up so about that tweak. Its opening. You have the same problem, but I live in Boston. My group is in Pittsburgh, Pennsylvania. And yes, yes, we travel. Not many of us stay home. So I have to watch all my sports either online or on DirecTV. For seeing DirecTV folks here, thank you. The $500 monthly payment probably goes to help somebody up. But I, for once, all my sports streaming, and the internet is faster now. Then the stream gets to me. And so, as I'm watching the Pirates games lately, all of a sudden all my devices ding, ding, ding, ding as one of our guys is hitting. And I know, okay, well he just got a hit and somebody scored because everything is telling me. And so I thought, sure would be nice if somebody was just timed to lay that, listen to what's going on in my room, in the room I'm in, because I've got one of these things that's listening. We all know our TVs are listening. So let's listen to see what's going on and help my experience do better. And I say that because I wrote a patent to do it. So if you do that, make a lot of money. So we can all help. I'll get paid. But I'm going to talk about perspectives on mobile software development and next-gen software architecture. Wow. So you all read that and thought, I'm going to come here and listen to this. Thank you. Thank you. I promise, I promise we will not write code. We will not dive crazy deep into technology. But what I do want to talk about is what's going on in the tech knowledge world, what's going on in the industry that we can leverage to give our customers a great customer experience, like I want when I watch sports. So we'll start off by saying, welcome to year five of the age of the customer. We've seen over time that companies succeed by excelling in certain areas. Initially, a company succeeded by building great things. Then that got moved forward to companies that can distribute it locally or around the world. Then the next step was the age of information, where folks excelled by making sure everybody knew what data they had and how to come to them on a website or at a URL to get that data. But now we are five years into what we have called the age of the customer, which means we need to build great customer experiences to succeed in our businesses. We need to create great customer experiences, not create a representation of our data that we have, because we've done that for many years. Just a little bit of brief background about me. I'm a computer engineer. Went to school in Cleveland, which, after I told you I grew up in Pittsburgh as a sports fan, going to school in Cleveland was difficult. I had to keep a lot of my feelings to myself because they're quite aggressive over there when they find out you're from Pittsburgh. But I was a computer engineer and then spent 13 years at IBM building software as a developer. I've built mobile apps back in the late 90s for Pocket PC and Palm Pilot and things like that. And when you think about building mobile today and think that it's pretty hard, it was really hard back then, really, really hard. But I headed a number of teams, so I'm well versed in making things look very pedestrian and very ancient. But today and moving forward, we have to think the opposite. We have to think about for the customer, what the customer wants. And to do that, to be customer obsessed, requires an operational reboot. How we do business has to change. What drives success in companies has to change. And this is all the way from the big companies with millions and millions of dollars to spend on their technology stack, all the way down through the mid-market and to SMB, because the customer experience is what changes things. Companies like USAA figured this out. As this transition was happening, a lot of banks said, we need to have a mobile app, we need to have a mobile experience. And so they took what they had on the web and shrunk it down on the small screen. USAA said, we want to be focused on our customer. What do our customers really want? It sure would be nice if I didn't have to go to a branch to cash my checks. So they were the first one to say, we'll let you cash your check, we'll deposit it, you can deposit a check through your mobile avenues by taking a picture of it. And that advanced their business by using mobile to create a great customer experience. We need to think differently. We need to reboot how we build things. So a big part of my day at Forrester is taking calls from our clients where they ask questions, oftentimes technology questions, oftentimes strategy around how we create digital experiences. And I get this question all the time: Mike, we want to create a great mobile app. And my immediate response every single time is, why? Why do you want to create a mobile app? We need to stop thinking about the channel that we deliver things and think about the customer experience that we want to build. So is your customer looking at their phones thinking, I need to open up this brand's app today? Generally, the answer is no. Generally, the answer is they don't want to open your app. Our data shows that folks spend about 50 hours of time per month on their phone, and they look at a little over six unique apps per day and about 25 unique apps per month. So six unique apps per day. And I don't have the data here, but I will tell you that those apps, the massive majority of that time is spent with Google, Apple, Facebook, and Microsoft. That's it. So that's four of them. Can you be the other two in a given day? But I'd argue the answer is no. Now, what you do want is when folks have a mobile moment, when they have that moment of need for your service, will you be there? Sometimes that means a mobile app, sometimes that means a website. But moving forward, it's going to be a lot of different things. And so how do we address that challenge? Because right now the focus is on these phones, but we also see a big rise in things like the Amazon Echo and voice interfaces. Now, I'll tell you, we're actually from a technology point of view still pretty long ways away from making these things really, really robust. And I know that because, as mentioned, I've got two boys. Mine are 21 and 18. I look forward to that day when I can start just hanging out. But my kids are nine and six, and so we're past the point where I have to worry about keeping them alive and up to the point where my two boys have to make sure all the people around them stay alive because they're two boys. But I know that we're still a little bit of ways away from making this happen because this is my kids' best friend right now. They love talking to their Amazon Echo. They love talking to Alexa and asking her questions, especially for my nine-year-old doing his homework. When he's asked in his homework, you know, who is George Washington? Who are the famous statesmen of Massachusetts? And he just asks her and she tells him, he writes it down. Now, the interesting thing is he gets excited and starts wiggling, my younger son starts giggling, and all of a sudden you start hearing from Alexa, I don't know the answer to your question. I can't understand what you're saying. So if you say things in well-formed, seeking query type statements, she's awesome. You say things like a nine-year-old says them, or like I say them, I get a little bit tired. I spent a lot of time growing up in the South, and the Southern starts coming out of me. She has no idea what I'm saying. Most people don't when that happens. So all the older gets her, but we still got a long way to go from a technology standpoint to make that happen. But when we think about mobile, it's not just about mobile apps and mobile websites. We also have things like these chat experiences: WeChat, Facebook Messenger, Kik, why I message. This is one of the platforms that's really starting to grow up in a hurry. So when you get that question around, I want to build a mobile app, we need to think, we need to build a mobile experience, or even larger, we need to build an experience that includes these things. Companies like KLM found out that folks didn't want to open their app to find out the gate changed. They just wanted a text message or they just wanted a Facebook Messenger message to tell them the gate changed. Or they found out that customers wanted to be able to ask them, where's the nearest lounge? Where is my gate? What time is my flight? And they now run almost an entire percentage of their customer service business over these chat interfaces. And for them, that's a lot of business. And then finally, on mobile devices, we also have these things: Siri, Cortana, Google Now. These are just a glimpse into how the future of mobile is actually going to work. Because in reality, not only does the customer not want to open your app, they don't want to open any app. I don't know about you, but what I would love to do is actually pull up my phone and say, I want to go somewhere. I want to do something. I want to go to the Pirates game. Get me there. Solve that problem. Because that's not an app for me. It's a collection of things. For me, that's a collection of things. Smartphones will soon be smart, but they're not right now. This thing is not smart. I am, well I think I am. My wife would often say otherwise. But we are the ones that kind of put these things together. When I say I want to go to a Pirates game, I have to look up and find out where they're at right now, where they're playing, where the tickets are, can I get a flight there, can I get an Uber from my flight to there, where's the hotel? That's a lot of things that I have to do. Soon these things will do this for us. And we're getting a glimpse into that thanks to Cortana, Google Now, and Siri. So keep that in mind. We have to build things to work with these new experiences. So it's the first set of challenges that I get moving forward. The second one is this: we need to build something quickly. And to that, I don't say why. I say you're absolutely right, and it's going to get even faster. The pace of development is going faster and faster and faster. And so we need to keep up. Or better, we need to know what we need to keep up with and put the blinders on to everything else. What do our customers want? Answer that question every day. What do our customers want? How do we meet that need? Let's find out the technology that meets that need. So I've been developing software since I was a little kid. Actually, I was that kid that growing up on a farm, we had one TV. On Friday nights, my mom would want to commandeer that TV from me because I had my Commodore 64 attached to it so I could write code to make a little worm move through a maze. That was a fun thing to do. It's what kids like me built back in the Commodore 64 days. But a Friday night, so my mom went to watch Dallas and Dynasty. Like my customer experience on TV had me on Dallas and Dynasty on Friday nights. My mom would watch TV. Things took a lot of time to build back then. And moving forward, they still take a lot of time. So I spent the first probably ten years of my career writing very waterfall-based process software, where we would spend the emerging 12 and 18 months designing, building, testing, delivering a piece of software. And it was a pretty static process. But when we asked business stakeholders and we asked consumers today, how soon do you want things? When you have an idea about something, how soon do you want it? The answer is roughly two to four months. And then they want to update it and get more and get better and how to meet their needs better. So this pattern is continuing to the point where software and software development is approaching a zero-day event. Where when I have an idea for something I want, I need it. If you can't give it to me today, I'll find someone else that can. Because software development and the tools and the patterns we have to build it are enabling folks to build things bigger, enabling folks to build experiences very, very quickly. But that doesn't mean everybody knows how to use them. And so we need to make sure that we have development processes and techniques to build things very, very quickly, because folks want things and they want it now, and they want it wherever they are, on whatever device, in whatever context. So to solve that problem, we look at folks like Netflix. Netflix is an amazing case because they support over 300 unique devices. You need things not just unique mobile phones, but games and TVs and phones and tablets and desktops. And what Netflix realized to solve this problem is, written quote from Reed Hastings: "We realize we learn best by getting into the market and then learning, even if we're less than perfect." So we need to change our mindset on when we go to market, when we deliver. It used to be we delivered when we had all of our nine months ago requirements met at a certain level of quality, quality defined by a set of test cases. Now we need to understand what our customers want, how quickly can we get to them, and we ship when we have that ability for them to tell us how much they like it, and then we move on from there. So how do we do this? How do we actually create this thing? What are we going to do? Most companies think of the mobile challenge as a front-end challenge. When I talk to folks and they say they want to build an app, they want to build a mobile website, the first thing they start talking about is what are the front-end technologies that we use to do it, to build an app, to build the web, to build one of these messenger type things. And that is part of the challenge, but as we get into it, that's not the big part of the challenge. So how do we think about these things? Modern applications are systems of systems. We talk about systems of engagement, which are the parts of the system that folks interact with. This is your mobile app and your mobile website, and this is what directly influences the customer's experiences. So we need to think about that first. The first part of the system that we think about is that system of engagement. And then we think about the systems of record to support it: our data systems, our HR, CRM, inventory management, things like that. So we think about first the customer experience. Let's build it, and then let's connect it to the data that supports that experience. And then we have things like systems of automation that also provide data: beacons and IoT and all these streaming things that can influence how we deliver data to customer experiences to make this work. And then if we look just a little bit into the future, and there's already a little bit of this happening, but then we have systems of insight to pull this all together. That says, for a given customer, given what they've done in the past, given other customers like them and their stage of the funnel or whatever type of filter you might have, what would they want to do next? So at that point, we'll think about not only what our customer experience is, but what it should be in context when they're doing something, which is what will they want to do, and let's build that. So what do you think about front ends? And think about how we built these front ends. There are a number of options there today. We can build native apps with things like Xcode and Android Studio and Microsoft Visual Studio. I'll tell you, as a developer, I started professionally in 1997. Every kid used Visual Studio. We all did. I was hired by IBM, and I told IBM, well, I'll come work for you, but you got to buy me that tool because that thing rocks. Fast forward to today, that situation is starting to come back. A lot of great things happening around Visual Studio. So when you think about building digital experiences, with an understanding that a lot of phones, not a lot of people have Microsoft phones, a lot of developers are using that tool. So keep that in mind. So you can build native apps using these tools, or we can build cross-channel or optimized experiences using things like Cordova, React Native, Xamarin. These are opportunities where we can write code one time, or maybe nearly one time, and not have a full second set of source code for every other device that's out there. But what we're all converging to is this: the web is still incredibly important. HTML5, HTML, CSS, and JavaScript are incredibly important because as we start getting all these devices, mobile devices, IoT devices, phones, wearables, watches, Alexa, all of these things, we need to optimize how we build these experiences. And we've had this ability to optimize for a long time. We tend to just be settled by the slow pace of adoption for things. That's going to speed up because the need for the web is incredibly huge. And so we're going to talk about that a little bit as well. Now, even though we're moving towards the web as a way to build a lot of these things, it's not always been easy. What this is, and I might be a little bit of an architect, what this is are the top four most popular web development libraries that are out there now and their popularity over time since April 2011 up through June of 2015. And this is a point of consternation for a lot of our clients. Folks call me because they say, I decided to use this thing called Ember, and then Angular came out. I decided to use this thing called Angular, and then React came out. My gosh, which one do I use? And do I have to change every day just because this craft changes every day? And the answer is no. These things all still work. There's a lot of buzz in the marketplace about what's the best thing, what's the coolest thing. But these things all work. So the better idea in development is to understand how are we as a company going to build things, how are we going to leverage the web, and what tools we need to build it. And then we can close your eyes to the rest of this buzz, the rest of this noise. Because like I said, all these things work. They just might not be what the coolest, hippest kids are using today, but they all still work. So that's the front-end challenge. Now, as I said, folks like to think about that a lot, but that's not the biggest challenge. The biggest challenge is the back end. How do we actually ensure that our systems are available and can be supported on all these new and crazy things that are coming out? And that challenge can be very, very daunting because we have all these traditional back-end systems, the things that we call systems of record. And these are the things that have powered our business, made it successful to this point. So we can't just throw them away. We've got to leverage them, and we've got to connect all of these back-end systems to the front-end things that are coming around: mobile devices, web experiences, folks building things with those native tools, folks building things with cross-platform tools like Cordova or React and React Native. The biggest challenge you will have in building digital experiences is connecting these two worlds, connecting your back end to the front end. I'll say it again: the biggest challenge you will have is connecting those back-end systems to these front-end experiences. So make that easy. Because if I asked a group of developers, raise your hand if you're a mobile developer, raise your hand if you're a web developer, all these folks are front-end developers. The last thing they want to do is figure out how to handle your web services, your SOAP, your REST protocols, the security protocols that hurt. I'm a back-end guy. That stuff hurts my brain even for me. It's just painful. We'd love to see these crazy awesome experiences, these Angry Birds-like experiences, and then we say, okay, here is the WSDL file you have to use to get this data. And developers are like, that sucks. And then they stopped doing their work because there's a lot more fun things to do. I'll tell you, developers, and I can say this, we are lazy creatures. And by lazy, I mean we will optimize how we do things so we have time to do other things that are enjoyable. So if you can make it fun, enjoyable, fast to do, I might prioritize the more enjoyable ones. So make this easy, because this is the hard challenge. So how does this look today? Oh, no, we're pretty graphics. Oh my god, I glee. So I'll talk about this a little bit. What this looks like today is how do we optimize for back-end data access? The two boxes that you don't see here are the important ones, and that's the second two technologies: Node.js and a front-end web server called Nginx. It's okay. Those two words, I'm sure you've heard about Node quite a bit. I've written about it. I wrote a report called "The Dawn of Enterprise JavaScript." Node.js will drive so many of the things that you build moving forward. And it's written in JavaScript. Four years ago, when I started doing this job, started being an analyst, one of the first things I told folks is you'd better have JavaScript developers because both front ends and back ends are written in them. And folks looked at me and said, you're crazy. I will never allow JavaScript in my back end. That's like MySpace. That's the things that make music play on websites and annoy me. Today, that JavaScript is driving a lot of what goes on. A third of the world's internet traffic is driven by Netflix, and that's mostly driven by JavaScript. So JavaScript and Node.js are the coordinators, the choreographers of all these systems. Now, as I touched on earlier, the future of mobile is the web, because the web provides us a ubiquitous way to deliver data over a transport channel and see that data with web browsers, with containers. Containers, we'll call mobile apps containers. We'll call things like Electron. Electron is another one that if you haven't heard of, you will. Because if you use things like Slack, Slack is an Electron app that allows me to build using web technologies desktop apps. Desktop apps will work on Mac, Windows, Linux. One language. I don't have to learn Swift, Objective-C, C++, things like that. I can use web technologies. The web is driving how we build digital experiences. But composition is the future of development. We don't have time to write code anymore. We don't have time to write new lines of code for everything we build. And this is a scary thing for folks like me as a developer, because when we hear something needs to be done, I know I'll take you back to when I was building software professionally. Folks, our executives would call me and say, Mike, we need to build something. Can you build it? And I would say, I'll build it. We're developers. We can build anything. Anything. I'm a golden god when it comes to this stuff. And then they ask, how long will it take? I don't know. Forever-ish. Tomorrow. I don't know. The point is, you can never trust us when it comes to timing. But it has to be done faster. And so to build it faster, we need to compose instead of writing code. Composition is the future of development. And I won't go into details of these things, but there are two things that we need to look for, two phrases you'll hear: web standards that we're waiting for to make composition a reality and will make the web the reality for building mobile, for building desktop, and for building a lot of things. Number one is web components. Web components, in short, is a way for me to bundle up how I build a web thing, how I bundle up both the front end, what it looks like, and that back-end data access paradigm. So a web component might be a list of items in your inventory with a number that says how many of them are still available. For me to build that system, I have to make at least probably three to five different back-end calls. But with web components, I can make all this one time and hand it out to my developers internally, my business partners, and they don't need to learn about any of that. So not only have we made that back-end data access easier, we've completely taken it away. We completely take away how hard it is by giving them a thing, a widget that they can drop on a web page, drop in a mobile app, drop the data part of it into a Google Now connector. So that when I walk into your store and pull out my Android phone or my iOS phone and open up the Google app, unfortunately, it will immediately tell me, hey, you're in an aisle and you're looking at something. We have more of these. So what composers will have to do is bundle that up and make it easier to develop. That's the first thing we need. The second thing we need to listen for is service workers. Once browsers support web components and service workers, any experience that you have with a mobile app today, I can build that in the web. Any experience that includes offline experiences, because that's the biggest thing that really slows down the web is when you run out of data connectivity or you have no connectivity or you have no Wi-Fi. So when you send your field force out into the field with a tablet that doesn't have a cellular connection, and most of them don't, roughly only 20% of them do upmarket today, it will work because service workers will allow us to store data locally and give you an offline experience. So two things we need to listen for: web components and service workers. That will make the web a very, very viable choice for building a lot of the digital experiences that we're thinking about. So we've talked about the challenges that we have with building digital experiences with the front end and the back end. So now what do we do? How do we think about moving forward? What do we need to do today and what do we need to do over the next three to five years to make this happen? The great thing is, and this quote sums it up so well, by William Gibson: "The future is already here. It's just not very evenly distributed." Folks are doing a lot of cool things. We have folks like Netflix and PayPal and Walmart, Home Depot of all people, Walmart, Condé Nast doing amazing things. But most of us aren't them. I'm not them. But we can look and listen and learn and see what they're doing. And fortunately, a lot of these folks are creating their tools using open source and sharing it with us. So don't look at them and think, my gosh, how far behind am I? Look at them and say, how can we adapt and start to use them? The good thing is, that's what I do. This keeps me employed. So you can look at them or you can talk to me. You do what. So the first thing we need to do is we need to move from a model of creating traditional requirements at the beginning of our software development lifecycle. And I love these folks because when I always thought when I was a kid, I started out working at IBM. I was a kid. I wasn't even 21 yet. But they brought me in. It was the beginning of the move to object-oriented, moved to things like C++ and quickly thereafter Java, which produced very structured C-type languages. And they brought me in.