INSIGHT | Building modern composable business solutions Mike Facemire, Forrester

So good afternoon. Thanks for the introduction. I feel like I have to justify that a little bit. I say over 23 because the number is 24, but it sounds really grandiose. So building modern composable business solutions. I'll start off by saying that I feel incredibly fortunate to be here. I speak at a lot of events, but this one being the developer conference for communications makes me feel at home because by trade, by schooling, by who I am, I'm a developer. I grew up writing code, but I'll get to that in a second. As was mentioned, I am the principal analyst at Forrester that covers web and mobile development, and that's front to back, top to bottom. I cover front end development, middleware stacks, how do you get access to your data, and all these things. And for a long time, when I did that professionally, we built technology because folks just bought technology. You were a Java shop, we built Java stuff, and you bought it. .NET same thing. But the world has changed, and the world is changing right now very, very quickly, and a lot of that change was detailed by Jeff and folks in the keynote this morning. But I'm here to talk about how we do that, how we actually build these composable modern solutions. Now, often times these solutions today are built on mobile devices, so I'll talk a lot about mobile, but a lot of what I'm going to talk about applies equally to the web, applies to the upcoming IoT. I've got to put the word IoT in here like five times to meet my buzz criteria, but they'll apply there as well. So let's jump into that.

I'll start off with this quote, which I absolutely love. If you heard me before, you've probably heard this. Any sufficiently advanced technology is indistinguishable from magic. When I was a kid, I sat and watched TV one night, and David Copperfield got on the TV. This is back when we only had one TV, so we all had to watch it. He got on TV and made the Statue of Liberty disappear. I grew up on a farm, seeing the Statue of Liberty was an awesome thing. It meant so much, had symbolism. And he made it disappear, and I was like, holy cow, that guy is amazing. The feeling of awe inside of me was incredible. I was sitting there with my mom, and I looked at my mom. My mom was a banker, and she understood the value of money and how money could make your life better, at least a little bit easier. I looked at her, and she could see the look in my eye, and she had the fear of what I was going to say. And I said it: 'Mom, I want to be a magician.' To this day, I remind her of that. And she goes, 'I was honestly worried that you were serious.' But the great thing is I got my wish, because if you think about it, if we were to go back in time way back, like three years ago, maybe even four years ago, if I were to give you a device, a phone, and said, if you touch this three or four times, a pizza might show up. Or if you touch it three or four times and hold it the right way, a cab might show up. You don't have to go out and wave or do anything. It'll give you its license plate number and a guy's name, and he'll open the door for you. You don't even have to give him money. He'll just take you places. And after this, I'll do that and I'll get in the Uber, and it'll take me to the airport. I don't have to give them any money. It's just magic. I love that magic. But the very cool thing is what we're creating today, what we're creating tomorrow, in the very near past looks like absolute magic. And that's what really excites me about what's going on. But important to this crowd and what we're all here for is how do we actually succeed with our customers, how do we actually get them excited and engaged with what we're doing.

I'll take you through a quick piece of history. We've gone through a number of ages in business. We had the age of manufacturing, when we were just trying to build things. And the age of distribution, where we took those things and distributed them as far as we could to make more money. Then we had the age of information, which is kind of where I jumped into this game professionally, when the web came along. And that was the definition of how we did it: we built things on the web. And now we are in what us at Forrester called the age of the customer. And the age of the customer means we need to be obsessed about what our customers want and give them what they want when they want it, wherever they are. You hear us talk about mobile moments. Mobile moments are when I'm out in the world and something happens and I need something. I just had a wreck and I need my insurance information, or a cop just pulled me over and I need my insurance information, or I'm buying a car and I go to a dealership and I know these guys are doing some shady stuff and I need to find out what are the real numbers. That's the mobile moment. You have to be right there. If you do that, you'll drive great success within your customers. But how do we do that? How do we build that? That's causing a number of changes in technology, and it's layered out into three things: what we're building, when we're building it, and how we do so. So I'm going to walk us through here.

What we're building: what defines success today with what we're building? I'll take you back to when I started building software professionally, getting paid to build software, back in the very late '90s. This was what success looked like. No offense to the National UFO Center, they do awesome stuff. But this was success: it was how much stuff can we jam onto a page? We have these things in our data center, we have these applications, these sets of data. If we put it all on one page, if we can fit it all on one page, that's a win, we're done. Product managers, that's blazing success. And then as we went further, we had the first wave of mobile. This is what I was actually hired to do out of college back in '99: build mobile apps on Palm Pilot and Pocket PC and Windows CE. Funny aside: now my job at Forrester, folks call me and say, 'Mobile development is really hard.' And I say, 'I agree, but it's crazy hard. We had one thread to do everything, and everything meant contacts, phone, and calendar, and that's it. Good luck building anything else.' But when the first wave of mobile came out, we said we have this new device, we can do all these new things, but success looked exactly the same: it was how much stuff can we jam in there? I don't care how big your fingers are, we'll give you a stylus that'll solve the problem. But today, success looks completely different. As W says, there's a better way. Success in today's digital world, in both mobile and we're seeing mobile influence the web now as well, is how do we present just what our customers want, just when they want it, and then get out of the way. That's what success looks like today.

So if that's what success looks like, what's changing about how we build it? This is the biggest one. As a developer, when you meet developers, one thing about us is that we always have that in our head. As Jeff was talking about this morning, we're builders. Anytime we see a problem, a challenge, we figure out how to solve it, how to build it. I still write code, and this is a challenge that makes me really happy. I get to stand on stage here today and not actually build these solutions because the timeframe in which we're being asked to deliver solutions is decreasing dramatically. Back in the day, way back like at least three or four years ago, we had roughly 12 to 18 months to build internal enterprise solutions. We had a very waterfall procedure to do it: it was very prescriptive. The design folks did their thing, then developers and testers and ops folks, and it was very, very detailed. And we did that over 12 to 18 months. For a developer, that was great because when it wasn't your time, you did professional development, which meant like play Warcraft or go have long lunches and hang out. And then development time came, and it was forced March, and we worked for 80 hours a week. And that was good because we're cool with that. Then once that was done, we gave it to the testers, and they broke our stuff. They broke our beautiful creation. That's why developers and testers don't get along. But what we're seeing is a massive change in that timeframe. We're going from a 12 to 18-month traditional cycle to now where business and customers and stakeholders want to see apps, websites in 2 to 4 months. And then if we take that to the extreme, if we listen to what Werner talked about this morning, about how often Amazon ships and how often Amazon updates software, development is approaching a zero-day event. It's approaching the point where when the business comes to development teams or IT organizations and says, 'Can you get this thing done?' The first question which is commonly asked is, 'Well, when do you want it?' I remember that answer always being, 'Well, if we could have it today.' And they would laugh, and I would laugh, and we'd get a little chuckle. Well, moving forward, they're going to say we want it today, and they're going to be serious, because if you can't deliver that today, folks go elsewhere. The amazing thing that we're seeing in mobile and is now pervading backwards into the web is there's a ton of choice. Folks have choice of where to go because the barrier to entry to creating software is incredibly low now. There's so many awesome opportunities to put things together, to create amazing experiences. So we know that we have to have a great experience to win in today's world, but we're being asked to do that incredibly fast.

The third one that we're seeing is how we do development. As I said, in the past we would often look at what's our data look like, how much data do we have, what our applications look like. We have all this stuff, then let's put that out there. And if we put it out there, then everybody will use it and they'll love us. But the problem is that's not very customer obsessed. Looking at our data and asking what our data can do on the web or in mobile is a lot different than asking what our customers want. So we have to change that mindset. We have to change how we go about thinking up, designing, and developing software. You've got to start top down. At Forrester, we talk a lot about our systems. We have systems of record. The systems of record are back-end systems, our data, ERP, or ugly, ugly backend stuff that we'd prefer that people don't see. Then we have our systems of engagement, which is the great user experiences on top of that that we do want folks to see. We've got to think about building top down: start with your systems of engagement, start with what your customers want, and then start to federate in. Now, how does the data fulfill that need? How do new systems of automation, beacons, continuous input systems, how do they influence how that data fills in our systems of engagement? And then finally use what we call systems of insight: predictive measures, data-driven solutions. How do we use those to fully personalize exactly what people want? If we do it in that process and we always keep our customer first and keep their needs first, we have a much better chance of succeeding with the solutions that we build. In the past, it was a complete crapshoot. We had data and we threw it out there, and maybe you liked it, maybe you didn't. But back then there wasn't choice. Back then, you only had one or two solutions, so you like it or you don't. If you don't like me, this guy's probably marginally better or marginally worse. But today, choice changes this whole equation. So how do we do this? We have to create great experiences, we have to do it right now, and we have to do it with our customers in mind.

To solve this, I believe we at Forrester believe, based on our discussions with our customers and the folks that we talk to, that composition is the future. We simply don't have time to build software line by line anymore. We have to look at what exists out there and simply compose solutions for our customers. And those solutions have to be flexible. They've got to be changeable. Werner talked about this morning about being adaptable. These solutions have to be adaptable because customers' needs change every single day. I don't know about you, but when I wake up in the morning and I look at my phone, I see all these new updates on my phone, and that makes me think, 'Oh, I'm going to use those apps.' So I have this mindset that there's always new stuff every day. So then we get into a mindset: well, every app I use should be new every day. And then you know Amazon updates 117 times per second or something like that, and I think, 'Wow, everything should be new.' And so when it's not new, I get this mindset of, 'Wow, what are you all doing? Just sitting around waiting for some magic to happen?' And that's from a developer perspective a terrible mindset because it's a constant race. But that's the world we live in now. So we've got to compose solutions.

Then it comes down to where can we compose? Where does this composition happen? The big areas are happening on both the front end and the back end of these software systems. On the front end, we have things like the web component spec in HTML that says don't just write pure HTML and pure CSS and pure JavaScript. Instead, take pre-built components, or almost pre-built components that are configurable to a degree, and stitch them together. I remember it wasn't too long ago I was looking for some solution somewhere and I came across Yahoo Pipes. I thought this was amazing. It said I don't have to build anything. I simply connect this one service to another service to a UI, and it magically happens. Well, the web wasn't quite ready back then, but it is now. Web browsers have power. The web browsers on our phones have power. All of a sudden they can make a number of connections pretty quickly, apply styling to it through CSS, as long as you don't write too bad CSS, and create a really unique, personalized solution. So web components, as you see the four parts of it on the left, Google's Polymer is a great example of web components and how that can be used. Essentially you can drag and drop pieces of the web together to dynamically create your solution. And if I can drag and drop pieces together, that means I can probably also programmatically do it. And if I can do it programmatically, I can use data to influence what that looks like, and so I can always be personalizing to exactly what my customers need.

But it's not only on the front end. Traditionally, backends were built with this very model-view-controller type paradigm. Any of you folks that are computer people are very familiar with MVC, which said the model is your data, the view is what you look at, and the controller is that which puts the two together. Well, that traditionally is very monolithic, very big. That's being broken up as well. And we're starting to compose on the back end. We're separating the model, the data, from the controller from the application using technology such as Node.js, very popular, growing rapidly in popularity. We'll talk about that in a second. We're disintermediating the controller, the application, from the view using a ton of things. Literally every day new stuff comes out: Angular, Ember, Ionic, all of these things to make your views amazing and dynamic, but separating it from the application that creates that view. So we can compose on the front end, we can compose on the back end.

Now this is the interesting thing. We can compose. We have this awesome opportunity to quickly build software by composing it, not writing it. But where do we do it and who does it? Because I'll tell you right now, all of us sitting in this room with mobile phones or tablets, and I'm hoping that's everybody, if you're here and you don't have a phone or a tablet, you're probably wondering what I'm talking about. But right now you are composing your own solutions. I don't know about you, but when I need to book a flight, I tend to pull up my Delta app. I look and I see, 'Okay, I think this flight will work.' And here the seats that it's presenting me with, I'm a big guy, there's a lot of seats on a plane I don't fit in, so I use a site called SeatGuru to figure out which are the good seats. So then what I have to do is close the Delta app, then pull up the SeatGuru app, and I look, 'Okay, that's a good seat.' And I go back to the Delta app, and oh, there's not an open seat next to it, here's a better seat. And I go back and forth. And then if I book the flight and I need to change something, then I have to pull out my Delta card and call them. There's all this stuff. All I want to do is book a seat. And that's an experience that Delta or the other airlines would love for me to do, that's how they get revenue. But it's difficult today because I have to compose my own solution to all of that. We need to do one step better.

With what we have today, with this app-centric model and web-centric model, we're asking your customers to compose themselves. The next step is what we're calling embedded experiences. We're starting to see sparks of this: things like Google Now, Siri, Microsoft's Cortana, where the devices themselves take a look at what I as a user am doing and look at my calendar and look at things I might want to be doing, look at my context as Jeff talked about earlier, and figure out for me the things that I should do, stitch together the experience, give me some cards in the Google Now sense that solve my mobile moment, that solve exactly what I need. I use this quite a bit already. Going back to that Delta example, I actually never open their app if I don't have to, because I'd much rather just pull up Google Now and find out here's the gate you're at, oh your flight's been delayed, here's when it's going to take off, here's when it's going to land. And often times that data that Google gives me is more accurate than that which the provider gives me. But that's what I need. I can quickly see the information, get in, get out, have my problem solved, and then go watch the CNN thing at the airport, because that's the only time I watch CNN. These embedded experiences are the next step in composability. They are helping you compose that solution for your customers. But what we ultimately want, we want you, each of you, to be able to compose the solution for your customer exactly when they want and give them exactly what they want. This is also very, very early. We're starting to see this with WeChat in the Asia Pacific market. WeChat is a platform that folks are building apps on top of such that they can have a full set of experiences right within WeChat. Facebook announced a couple weeks ago, now probably about a month ago, that I can now start to build apps on Messenger. When I want to have collaboration, it allows me to pop up that little floating head thing, and I can not interrupt the things I'm doing by talking to that little floating head and then just touching it and it goes away. It doesn't completely context switch me away from what I'm doing. It's very early, definitely not a final solution, but it's that type of model: don't distract me, don't take me away from what I'm doing, because as brands, if you have a composition that takes them away from your app or your website, there's always a chance that they don't come back. That's exactly what you do not want.

So then how do we build it? How do we go about building these compositions? First thing, when I think back to how we've traditionally built software, we always started out with a set of requirements, and that list of requirements was 40, 50, 60 things long. And who came up with those requirements? It was folks like this. I can say that because I used to be a part of that. I didn't have quite that level of gray hair, I'm quickly getting there. But we would go in a room and sit around and think, 'Okay, we're going to build some software. Here's the 80 things we come up with.' And we knew exactly what you wanted. We didn't even have to ask you what you wanted. We wrote it all down in a massive tome of text, we gave it to the developers and said, 'Build this, and it'll be amazing.' And once you're done building it, we don't even need to ask if it was amazing. We know it was. We didn't even ask you if it was awesome. Unfortunately, that didn't work very well, because every now and again one of us would come into contact with a customer. I was one of those engineers that IBM allowed out of the lab to talk to customers. Those weren't always good experiences. They would tell me what they thought of our software at times, and it wasn't always pleasant. So we need to switch from this very requirements-driven development life cycle to a feedback-driven life cycle. If we think about the lean, minimum viable product model, that's what we need to build. And so how do we do that? We need to define what the success criteria is for our customer, for this event, for this thing that we're trying to solve. Define what we're trying to solve at a high level, not define objects, not define requirements, but define the problem. Establish the success criteria, the performance criteria. Then build just the core of what solves that problem. Build just that core. Why? Because we can do it quickly. We can throw analytics in there, we can get feedback, and we can immediately know if that solves our problem. We can immediately know if our customers like it, because oftentimes what we think they'll like, sometimes we get it right, sometimes we get it completely wrong. But you've got to know quickly. We've got to be able to fail fast. If we take 18 months and then fail, we all lose our jobs. We can't have that anymore. I got kids, I got to feed.

Then we need to quantify that feedback. How quickly can I get this minimum viable product out there that can collect feedback, and then quantify that feedback? One of the major challenges that we have as developers is we start writing it, and then all of a sudden folks will come to us, executives, customers, others, and say, 'Wouldn't it be nice if...' and then whatever happens after the 'if' is what we call scope creep. 'Wouldn't it be nice if you could just add this one thing?' 'Wouldn't it be nice if this button was moved to a different place?' Well, if we quantify the feedback we get from our customers, we can simply look at that and say, 'If we did that, what changes?' And then all of a sudden we can have a very data-driven process in how we build these modern applications, how we compose what our customers need. And then finally, once we have that quantified, we align it with the success criteria that we laid out earlier, and then rinse and repeat. That rinse and repeat model means that we didn't come up with an idea, build it, ship it, and we're done. Solutions today are very iterative. They tend to go on and on and on. That model earlier, I talked about waking up and looking at my phone and seeing all those updates. This is why we've got to continue with that mindset.

Now with that in mind, what this does is bring us a lot closer to our customers. That's great. We want to know what our customers want. We want to know if we succeeded in meeting what they want. But I'll warn you, they'll tell you. They'll tell you if you did a good job. I went and took a look in app stores, just to see a random selection of feedback of what people tell us. You get feedback like this: 'I use it all the time. It's very simple and clear. Highly recommended.' As a developer, I see that and I'm like, 'This is awesome. I met our customers' needs. This is awesome.' Then we see stuff like: 'I just downloaded. Less than one minute later, I'm uninstalling. The developers are complete idiots.' Yikes. 'Complete idiots.' That's harsh. I got a degree. I'm not an idiot. We say things like, 'Please, please, please allow an option that allows both buttons to be moved to the right side of the screen.' That's exactly what you want. You want them to say exactly these types of things. I'll move it. It's quantifiable. We succeed. And then there's the really painful stuff: 'Do not download this. PS: if you don't fix this, I'm going to send out buttloads of hate.' I mean, that's tough to hear. I don't even know how much a buttload is. It's like a box of hate. That's not a good day. So you're going to get a lot closer to your customers. Be prepared, because that customer feedback isn't what we're used to hearing on a day-to-day basis.

To wrap this up, what do we need to do to win right now? Number one: understand the modern business technology platform. Understand what we're needing to build around this. I recently put out a report on what that platform looks like. Number one: be very data-driven. Analytics is critical. I do not believe in building any software that does not have analytics built into it. We have so much opportunity to get data, especially with mobile devices. You have so much opportunity to understand the context of your user: what they're doing, where they're doing it, what other things they're doing, what mood they're in based on how much the device moves and things like that. We're really starting to understand, and as we get into things like the Apple Watch and others, we can see so much more. Don't lose that opportunity. So analytics has to be central to everything that you do. To know what your customers want. The second thing is a cloud delivery model. Especially in mobile, if you're successful, all of a sudden you're going to see strange spikes in when people use things. Often times those come from known events, things like Black Friday, we will spike e-commerce apps. Or tragedies, we'll spike apps for folks that respond to those tragedies. You don't want to have servers sitting around just waiting for that to happen that you pay for and they don't do anything 99% of the year. A cloud delivery model makes this happen. But unfortunately, it's not as easy as just taking what you have and putting it up in the cloud. We kind of have to rethink how we build software to work in the cloud: very microservice-driven, very API-driven, a lot going back to what Werner talked about this morning.

The third thing: identity. Mark Benioff over at Salesforce has said this many times, and I'll steal from him: this isn't a mobile revolution, this is an identity revolution. We've got to know who our customers are and treat them as a human. So many times that we build software, we treat our customers as user IDs or UUIDs, and that changes on my phone versus my tablet versus the web. I cannot stand that. When I go to an e-commerce or retailer and I log in and it seems like I'm a brand new person yet I use their mobile app all the time, that infuriates me. It's simply understanding that I am one person no matter what channel I'm on. So federate identities, and understand how to do that and have security around them. And then finally, have a consistent data access layer. APIs, creating a well-defined set of consumable APIs, is critical to speed and critical to time to market. Your front-end developers, whether they be web developers, mobile developers, IoT, watch, wearables, Glass, HoloLens, whatever they're on, and I can keep talking about that list, the front-end channels are not slimming, we're expanding. Those front-end developers don't care what the schema of your backend looks like. They don't care what your HR systems look like. They don't care what your WSDs look like, your web services, your SOA. They just want data. So make it easy. Make it easy for them to get that data. Whether it's your internals, whether it's third parties, whether it's business partners, or even externals, make it easy to get that data. RESTful APIs. Consistent, consumable RESTful APIs. I'm sure the folks at Twilio would agree because this is what's really benefited them: how easy it is to consume their service from a developer perspective. It's simply an API call away. Leverage that internally as well.

When it comes to how we create these consumable APIs, keep in mind when it comes to composition, consumable APIs is the way composition happens. Let's stitch some APIs together to create an experience. This is what it looks like these days. Most every scalable performance solution out there, from Netflix to PayPal to Walmart and on and on, looks just like this. At its core, Node.js is the orchestration engine for all of these services or all these data touchpoints, front-ended by a web server, more and more often Nginx, because it also performs at that same level of scale. What this does is we're not actually ripping and replacing our existing infrastructure. We're simply layering Node on top and allowing Node and Nginx working together to be the orchestrator of all of this backend data, orchestrator of new microservices, orchestrator of data that you have maybe behind your ESB or in your SOA infrastructure already. Orchestrate these third-party new services like Twilio and Box and Salesforce and on and on. All these new services. And what this allows me to do is as new services come around, really cool ones like we heard about this morning, as these new ones come around, I don't have to take my website offline and rebuild it. I simply add in that new API, add in a new piece of user interface to expose that data, and we magically have a new experience that meets our evolving customer need.

As a real world example of who's using it, Black Friday of this past year. Black Friday, as most of you are aware, is the biggest e-commerce or overall commerce day of the year. We saw tweets like this from Best Buy saying that we know we're having problems with our website. Best Buy's website actually went down for an hour on Black Friday. I don't even want to know how much money you lose when a website goes down for an hour on Black Friday, but it's probably more than my check. They went down for an hour, and they sent out a tweet saying, 'Maybe you should try our mobile site.' That's a tough solution after the fact. After they got the website back up, they issued a statement that said this was the problem: 'a concentrated spike in mobile traffic triggering issues that led us to shutdown bestbuy.com in order to take proactive measures to restore full performance.' I read that and think, why do I care? I just want to buy stuff. When I needed you, you weren't there for me. So I probably went somewhere else. That is not the definition of customer obsession, and that is not how you'll succeed in this modern world where there is so much choice. We want to be solving problems, not solving ways to wordsmith our way around them. Not to be offensive to Best Buy, there were a lot of folks that had the same problem.

On the other side of the coin, we have Walmart. Back in 2011, Walmart had the same problem. Walmart's site went down under the weight of Black Friday in 2011. They went back and said we need to rethink how we do things and we need to re-architect. And so on Black Friday this year, they put out this tweet. One of the admins on their back end said, 'I haven't seen a response time over 8 milliseconds.' So we might release Chaos Monkey, we might put new things out there, we might do some more tests right in the middle of Black Friday. #nodebf, Node Black Friday. Every one of their transactions, 100% of Walmart's transactions on Black Friday went through their Node infrastructure. Why? Because it scales, and it performs at scale. It's as simple as that.

Number two: we've got to invest in modern skills to build these things. It's not your standard old school C, C++, and Java. There's a lot of new skills that come around. I take calls every day from clients, and they're asking me, 'Who do I need to hire? Do I need to hire jQuery developers? Do I need to hire Node developers? Do I need to hire Angular developers?' In reality, what you need to look for is the commonality across all of these. The commonality is that JavaScript development skills are incredibly important. I've not been more bullish about a language in quite some time, probably since Java. The problem is Java and JavaScript share the first four letters, which is a little bit challenging because they're not really that common. It's more than a new set of semicolons. Java and JavaScript are different in how we think about writing code. So that's why I say don't look for the best Angular person or the best Ember person. Get someone that understands JavaScript and how to think like JavaScript: think event-driven, asynchronous architectures, and how I handle things with event handlers and how I handle things without having context of objects around me. It's a different way of thinking, but it's a critical skill as we move forward, because so many of these solutions are built using these technologies.

Number three: compose your customer solution. Compose, not write code. As a former developer, that hurts a little bit, because whenever we solve a challenge, we would just start writing code. That's what we do. It's how we solve problems. But we have to understand what that challenge is, figure out exactly what they need, and look around to see if there are already components out there. There are a lot. If you use things like Node, oftentimes it's one command-line instruction away to get all of those things. I can compose it and have something ready today. If you don't, if you start writing code and take all that time to write code, somebody else will compose that and will solve that problem. The barrier to entry for software-driven solutions is incredibly small today. Know your customer, know what they want, and address that mobile moment. Address what they need when they need it. And then finally, use data. Always use data to personalize their ideal composite solution. One thing I didn't put up here: if you can, don't make them compose it. Really understand their needs and compose it for them. If they need to talk to one of your folks in a call center or in the office, put the collaboration in there. If they need a map, don't make them go to Google Maps, put the map in there. So many times, I don't live in San Francisco, I live in Boston. This is essentially a second home of mine. I use the Order Ahead app every time I'm here because I love that it tells me where the best Thai food is no matter where I'm at. What I would love is when I'm done ordering, it would show me the map or show me directions of how to walk there, because this is an awesome chance to get some good exercise while being out here. I always want to walk. But I then have to look at my order and then get the address and then go to Google Maps. Or if my laptop isn't dead, I pull that up. Once again, I'm composing. Don't force your customers to compose. Give it all to them in one place.

Finally, I'll end with this. The future is already here, it's just not very evenly distributed. Out here in the valley and in the bay, I get the front end of that uneven distribution. I get to talk to you folks that are doing amazing things, and I get to take that back and help our other clients get to that same level. I put this up here because so many of my phone calls at Forrester start with the same phrase: 'I know I'm behind. But I know I'm behind the other folks in my vertical.' But you're not. Every conversation starts that way. But the good thing is there's so many tools, so many opportunities, so many chances to compose and to meet our customers' needs, and really accelerate how we excite and engage our customers. With that, I will say thank you.