Business Innovation at the Intersection of Mobile and ERP



Mike Jones Mike Jones
Chief Evangelist at OutSystems
Ameet Shah Ameet Shah
CEO at Conigent



Heather: Welcome, everyone, to today's webinar. Before we get started I do have some housekeeping items to share with you. This is a live webinar and it is being recorded. All of our participants are in listen-only mode. Now, during the webinar you can submit questions to the presenters via the chat window. Go ahead and please change your setting now to "select all panelists" so we make sure that we do get your questions and those that by doing this, they will be private and only be sent to the presenters and the moderator. Finally, we will provide a recording of the webinar that will be available tomorrow on the events page of the OutSystems website. Let's get started. Thank you again for joining us today. Our webinar topic is "Business Innovation at the Intersection of Mobile and ERP". During the webinar we will be sharing strategies for adapting systems of record with current business needs. We also have joining us business consulting firm Conigent, who will share a specific case study from Sheetz, which is one of the top convenience store chains in the U.S. The case study will show how they extended their Infor M3 ERP implementation to the field, fully accessible via mobile devices. My name is Heather Pritchett. I am the Director of Marketing for OutSystems North America. I am joined in the room with Jeff Newlin, our GM for North America and we will be the host and moderator for today's session. Also joining me today is Mike Jones. He is the Evangelist for OutSystems. Mike started out almost 30 years ago as a COBOL programmer with EDS. After a few laborious years of programming at EDS, Mike realized that there had to be a better way to design and code applications. Then he joined the newly formed software division of Texas Instruments and over the next 10+ years he advised hundreds of organizations on how to adopt the information engineering methodology and to use TI's model-based tools to modernize application development. During his career, Mike has participated in the key industry shifts, from the mainframe, to client server, to the web and now to cloud and mobile. He's experienced first-hand IT's struggles dealing with these shifts using various approaches from waterfall to object-oriented to component-based development and to Agile. We also have a guest speaker with us today from Conigent. We have Ameet Shah, the CEO of Conigent. He brings much expertise in providing strategic direction, requirements gathering, redesign of processes, development of practical solutions and oversight of his implementation team. His business focus is to get to the heart of a company's operations and application and build a solution that improves business strategy and the end user experience. This approach towards business, combined with Mr. Shah's 15 years of experience working as a consultant has allowed him to expand his business from a one-man show to a 30-person enterprise. In fact, Mr. Shah was named one of South Jersey's Men of the Year and Philadelphia Business Journal's 40 Under 40 for his personal and corporate success and his commitment to philanthropic endeavors so a big congrats to Ameet for that. I'll now turn things over to Mike so he can go ahead and set the stage for the challenge that we're going to address during today's discussion. Over to you, Mike.

Mike: All right. Thanks, Heather, and welcome, everyone. As Heather said, it's my opportunity and pleasure to get to set the stage for the story that Ameet and his team from Conigent will tell you today. I thought I'd start with this picture. The intersection is an interesting metaphor and I think it's very appropriate for the discussion we want to have today. You may be scratching your head right now and asking yourself, "OK, Mike, but what's really the point? Why an intersection?" so I thought I'd try to put it to you this way. When we look at mobile and we look at things like ERP and especially packaged implementations of enterprise resource planning, what we see is that things move at very, very different paces. Some more very fast and some are much more stable. While we're constantly thinking about software, the reality here is that from a business perspective, what moves fast and what's stable is really the business process. Processes evolve at different speeds and, of course, that puts an immense amount of pressure on us as IT professionals to be able to deliver software to really implement and support those business processes. To address this challenge, we've borrowed a model from Gartner which we think is very appropriate. This is called the "Pace Layered Application Architecture" and this is something that we started talking about towards the end of last year. It's a simple model conceptually. It basically says you should organize your applications into systems of record, systems of differentiation and systems of innovation. What it teaches us is that the way you classify applications into this model is based on their pace of change. So it's not really how fast the application changes, of course. It's how fast the business is changing and then putting demands on you as IT professionals to keep up with that change from a software point of view. What we tend to see is that systems of record tend to require very slow paces of change, almost annually. The reality here is, I think every year we tend to update these types of systems with maybe some new regulatory requirements or maybe we're taking and upgrading a package which implements those new regulatory requirements. But the change is fairly infrequent because the processes are very stable. Of course in that middle layer is where we see much more rapid change. In many cases it's monthly, sometimes quarterly, but the point here is that the applications that we tend to find in the middle layer are very important, critical applications for your business. They contain master data. However, they tend to change and evolve at a fairly rapid pace because they make your business unique and, of course, whenever you have something that makes you different, you're constantly evolving it and tweaking it to stay ahead of your competition. Then, of course, in the top layer, what I like to think of as sort of on the edge, if you will, of this model is systems of innovation and here's where we see weekly change and in many cases almost daily change because the business is typically in event mode and the types of things they're building here need to change and evolve at a very rapid pace and, quite frankly, there's a lot of disposable type of stuff. We build something, we event a little bit in a process, maybe we like to call it the "seek and engage mode". Then we eventually abandon it because it wasn't really the right thing. So very, very rapid pace of change. Now, when you look at the story that Ameet and his team are going to tell, it's really talking about a system of record which happens to be implemented in a package ERP and some mobile capabilities, which in this case were very innovative and were happy to evolve at a very, very rapid pace. The complexity, when you really think about this, guys, the complexity then bridging this intersection, if you want to call it that, brings is the integration points because that mobile application out there on the edge, guess what, it's providing data and insight to remote workers out in the field based on data that's stored back in that ERP package. When you have something moving very fast or something that's more stable and they need to work together, it puts a lot of pressure on us as IT professionals. I thought I'd share three guidelines that we talk about with our customers here at OutSystems for dealing with this and then Ameet and his team are going to tell you how they actually did it in the real world at Sheetz. The three guidelines, once again, very simple. I think everyone will nod their head and go, "Yeah, Mike, this makes a lot of sense." It all starts with this notion of, "I'm going to buy/rent some software and lots of times I want to customize it because I need to have it do different stuff." We know that if we start customizing packaged type stuff that we end up with a bit of a fire around this. The first guideline is to make sure that we isolate systems of record with good APIs. We want to keep them stable. We want to let them survive this slow-changing technology and the way to do that is by putting good APIs in place. Then, of course, when we need to extend them with the unique capabilities to support our differentiating business processes we want to do that with a build for change mentality because we've got to invest in that layer of systems of differentiation in such a way that the applications can evolve at a very rapid pace. This, once again, puts a lot of challenges on us as IT professionals because usually we have very tight deadlines. We don't have enough resources or budget to get everything done that the business would like to have done. Lots of times we don't really know exactly what they want. They're in a little bit of event mode and that puts pressure on us to sometimes not embrace all the build for change or flexible things that we would like to do with a piece of software when we build it to have it survive change. So this is something that we really need to pay attention to and invest in to survive systems of differentiation. Then, of course, the third guideline is, for systems of innovation, you need to really invest in supporting extreme release cycles. If you've got traditional build processes that take a couple of days and you're trying to release every day or every couple of times a day, you've got major problems. A lot of us have invested here but it becomes paramount and really full of pressure when those systems of innovation are, on day one, needing to integrate with your systems of record like the Sheetz example. I've set the stage. Hopefully everyone's nodding, going, "OK, Mike. This makes a lot of sense." Now, what I want to do is turn the controls over to Ameet and let him sort of tell the story of the Sheetz project. Ameet, I'm making you presenter. You now have the ball. Ladies and gentlemen, Ameet Shah.

Ameet: All right. Well, thanks, Mike. My name, again, is Ameet Shah and I'm the founder of Conigent. I founded Conigent in 2007 and we are focused on implementing enterprise business applications and really extending those applications through custom web and mobile development. I'm joined by my colleague Eric Henningsen, who's an Engagement Manager at Conigen. I've asked him to join us because he has intimate knowledge with some of the sample applications we want to talk to you today about Sheetz. I'll give you a little bit of background about our organization and our competencies. We're really three main focuses. The first is enterprise application consulting. So our roots lie in implementing enterprise applications like ERP systems and CRM systems. We work with a variety of clients. Today most of our clients are $1 billion or greater in revenue. I think our differentiator lies in our ability to develop practical solutions. So all of our consultants come from some kind of industry background. They've sat in the role of a production planner or a scheduler or a manufacturing supervisor. They come from different verticals. It could be health and medical or it could be the fashion industry. What it means is that our consultants bring real world experience to all of our solutions. This ultimately translates for our customers into solutions that have off the charts user adoption rates. Our second main focus of our business is something that we term "edge process development". What we find is that we can go into organizations that may be very stable in their ERP environment. They may be stable with, perhaps, as their CRM solution. They have these outliers, these requirements that allow them to differentiate themselves in the market and create something really unique and something that makes them, them. What we do is we fill those edge process gaps through custom web and mobile development leveraging OutSystems Platform or the Agile Platform. The third and final part of our business is something referred to as "consulting services". This is really talent acquisition. We try and create a trusted advisor relationship with our clients and oftentimes we're asked to source either a permanent or a contract role in a technical function. That's a little bit about our organization. Mike did a great job of introducing this Gartner Pace Layered Model and what I'd like to do now is use that Pace Layered Model as a lens to look at our business kind of historically and how our approach to implementing systems. You can see here I've listed a number of different ERP packages so this is a typical engagement for us. In the past we would be implementing a ERP package and inevitably, our client would ask us to extend the functionality through some custom requirement. As good business analysts, we would encourage our customer to avoid the customization, instead, try and leverage the best in common business practices that are built innately in these ERP packages. Sometimes, we'd kind of win that battle. Other times, they'd say, "Hey, this is an absolute show-stopper. We can't move on without this," so we sort of concede and we build this custom solution denoting kind of the risks that are at hand. We might use some common pools like Visual Studio or Microsoft SQL server or maybe we're building a SharePoint application and we'll build out this customer point solution. Now, above and beyond that, we find needs that we kind of call "innovating" and these are things like, "Geez, it would be really great if we could provide a mobile app for our drivers or if we could communicate with folks out in the field by a two-way SMS messaging." In the past, our response was typically, "Hey, that's going to be out of scope or we're going to have to put that into "X" because, kind of standing back, our mission is to implement this core system of record." We've agreed to kind of take on this challenge with this higher risk custom solution of differentiating layer and, frankly, anything above and beyond that we're just going to move into another phase. It begs the question, well, why was that our approach? I think the easiest way to explain it is to walk you through an example. I'm going to walk you through an example of a client we had about six years ago. This client was in the commoditized business and one of their differentiators, oddly enough, was simply to know and control their costs, important in a commoditized market. We were helping them implement an ERP system and they were using a standard cost accounting system and kind of standard cost accounting systems would dictate that you're going to report production orders one at a time. For this client, they said, "That's not going to work for us because we can't envision our production personnel entering that much data. It's just simply too much. We need to find an easier way." What they asked us to do was build them a web portal that would allow them to report the production at the end of a shift, across multiple production orders as opposed to individually. We did that. The end result was that they were very happy with it, that they loved the application. They loved the application so much that they said, "Well, now we need it to scale for 1,000 users or more and, oh by the way, we need you to make this multilingual to support our French-speaking users and also can we mobilize the solution." If we stand back for a moment, remember our core mission was to implement the system of record, we noted the risks and built this point solution but we did it with a set of requirements that didn't include scalability or multilingual capabilities. Now, we're faced with new requirements and, unfortunately, we're really faced with rewriting this application and what we originally created now became a legacy application. This is kind of why, as business analysts, we shied away from these custom solutions in the past. Today, we actually welcome this change. What we do is we implement standard ERP systems as a system of record along with the Agile Platform to accommodate differentiating and innovating needs. We do this concurrently so no longer are we saying that we need to move those custom requirements into phase two or three. Instead, we're saying we can do them in phase one and we can deliver them really quickly so we can keep up with the pace of the ERP implementation and the Agile Platform welcomes change. Since we're building something innovating, it's not uncommon for us to create a new requirement that really turns the application on its head and we can do that with the Agile Platform. Then there are other, what we term, "nonfunctional requirements" that come along with the Agile Platform that allow us to accommodate those unanticipated requirements. Things like scalability and automatic optimization are already built into it. A very robust security model was already built into it and we can integrate not only to your ERP system but maybe to some of those other best of breed applications. For us at Conigent, this has become a huge differentiator for us so now rather than saying, "Well, we're another B2 implementer of ERP application," we can also accommodate custom requirements and put them into phase one and make them a reality. I want to talk to you today, with the help of Eric, about one of our favorite clients. They are Sheetz. They are in the convenient store business and they are headquartered in Altoona, PA, which is the northeastern part of the U.S., founded in 1952. They currently have 400+ locations and they're privately owned. They have an aggressive growth strategy to grow to 600 stores in the next three to five years. What's unique about Sheetz, is that you can see from this image, they're rather large convenience stores. They pride themselves on being extremely clean. They pride themselves on having fully functioning stores and having amazingly friendly staff. The Sheetz family has invested millions into their brand. Customer loyalty is critical to them so when you talk about business process change or implementing a new IT system, it's always centered around the idea of the customer experience and how is that going to positively or adversely affect that customer experience. We titled this the intersection of mobile and ERP. Let's talk about Sheetz from an IT perspective. So from an IT strategy perspective it's a business-driven IT organization. It follows that mantra of the customer experience being number one. The result of that is that there are 150+ business applications in their IT ecosystem. They recently created an ERP strategy to move to a fully integrated ERP system, namely Infor M3. This will allow them to consolidate some of those systems and ultimately replace a legacy finance application. Like many European implementations, we've decided to take a phased approach. In phase one we're focused on what we're calling "maintenance mobilization" so I'm going to give you a little bit of background on what that means. Here's a graphical depiction of the northeastern region of the U.S. and what those 400 stores look like geographically. This chart is showing you the call volumes. They have a central call center and they can receive during the busy season, which is usually the summer, June, July, August, they can receive over 1,000 calls a day. That's 1,000 calls with issues related to the stores (a gas pump is down, a soda machine is down, a parking light is out). The resources they have to service those calls are about 400 technicians, 150 of them are internal employees. Those internal employees also have vans with inventory on them and then they leverage a partner network through 250 subcontractors. What I want to do is talk to you about one example of a maintenance call. So what you're looking at is a gas pump at Sheetz. Now, fully functioning gas pumps are critically important to the Sheetz model. With a gas pump down or inoperable you form lines or queues and we really run the risk of having a customer drive a few miles further down the road to an alternative gas station. Ultimately it's the act of pumping gas that gets customers in the door and buying convenience items like sandwiches and sodas. So from a maintenance perspective we have a few challenges. The first is who can we deploy to this gas pump immediately to triage the issue. Once there, are there any special skills we need to solve the issue and if there are those special skills in our internal/external network, where are they and how quickly can we deploy them. Above and beyond this, we also may have special parts requirements so if we do have a parts requirement where is that part. So we have moving inventory at 150 vans and we have some local warehouses but where are those parts in real time. So we're going to need to leverage some GPS technology. What does this mean for us in terms of requirements and maintenance mobilization as it relates to the pace layered model? At a system of record level it's the usual suspects that you would expect from an ERP system (warehouse management, costing, finance, etc.) At a differentiating layer, you see things like a map-based dispatching tool. You see a web portal for internal and external technicians. So you may stand back and say, "Hold on a second. Map-based dispatching across a web portal, these are not new concepts." However, requirements at Sheetz are unique. Remember everything is centered around that customer experience so they have a process in place that works perfectly for them. It may not necessarily fall into best in common business practices built into other systems. The Sheetz team decided that really the answer here was to build a custom solution and to extend the functionality of a solid foundation of an Infor M3 product. At an innovating layer we see both mobile and SMS needs. Remember I talked to you about the 400 technicians and 250 of them are external vendors. When we talk about mobile requirements we introduce this concept of "bring your own device". Remember, while they're a trusted vendor and an extension of our staff, they're not actually our employees and therefore we can't dictate the hardware they're going to bring. Whatever mobile application we build needs to be able to be supported on Blackberry, Android device or in iOS. At this point what I'm going to do is turn the reins over to my colleague Eric and Eric's going to walk us through some examples of how we leveraged the Agile Platform to deliver some highly differentiated applications at Sheetz. Take it away, Eric.

Eric: Thanks, Ameet. I want to welcome everybody. When we start looking at Sheetz and their environment, we can't understate the importance of servicing calls to the Sheetz business. It's not just quick fix issues that these technicians are dealing with. It's also preventative maintenance. These technicians have as much impact on the success of their stores as the general staff that are working behind the counter. They're maybe responsible for washing windows, fixing light bulbs, sweeping up the parking lot. They really own the stores from things that break that they have to service that are immediately in the line of revenue but also preventative maintenance and all those things that make the stores appealing to their customers. If we look at the first example that we're going to talk about today it's what we call the "dispatch portal". The dispatch portal is one screen that we wanted to make easy, functional, straightforward. The dispatchers that are triaging these calls and sending technicians out on the road to do their work have years of experience and they use all that experience when they're building and assigning calls to technicians. They're building routes and getting teched out on the road to do things. We put the screen that you're looking at in two places. The first place we highlight, it's down at the bottom and that is the triage area. The dispatcher comes in, they see the list of all the calls and they can quickly see what the problem is and triage them, get them onto a schedule. The top half of the screen is the second function, what we call the "routing". The dispatchers can add the calls to a specific technician's schedule and right now we're just looking at utilization level. They can quickly see that this technician, over the course of a day, will be at 130% of their utilization. If they worked according to all the estimated timeframes, they worked, let's say, 10 hours out of a 8-hour day. The goal was one page functional, easy to use that keeps all of Sheetz unique requirements and utilizes that dispatcher's experience to quickly get calls addressed and technicians out on the road quickly. The next app that we're going to talk about is a Google Map. This is just another way that we can present information to the dispatcher or other users that are looking at it. Right now, we're looking all the Sheetz stores and the stores are categorized according to calls that are open. These are service calls and it takes the highest priority of any of the calls that are open and color codes the store on the map. You can click on that store and see the open work orders at a specific store and see the priority order associated with them. You can also drill into details around that. What the map does is just another way to present information. We can clearly and easily see geographic problems. We can provide heat maps of the different calls with the type and show that in another way for users to digest. It also provides real time information. The technician's GPS can show up so if I have a call at a store, I know where the technician is. The next thing we're going to talk about, number three, is what we're calling "targeted mobile apps". There's a couple things but if I just take a step back and talk about a day in the life of a technician, the technician goes to his home store and that's where he parks the van. He has the van full of parts and its inventory and it's integrated fully with ERP package. They have a laptop in their van and that is what they're going to communicate with the system. They're going to report all their work orders, they're going to get their assignments for the day, all on their laptop. They're not going to carry their laptop in the store. We wanted to give a couple targeted mobile apps that will help them in their day to make their life easier. The first thing is the work order listing. This is a list of the calls. If we recall from the dispatch portal, this is the list of calls that the technician has been assigned for the day so he can take his tablet with him into the store and he can interact with the work orders so he won't have to print out a list of the things that he has to do. He has whatever mobile device he's using, he can bring that in the store and see everything and interact with the system right on his handheld or on his phone. The next targeted mobile app is, it's labeled "cycle count", which you see is the industry term, but I just call it "inventory tracking". Like I said, the technician has the van and it's filled with parts. He uses these parts to fix things but he's also responsible for everything that he has in his van. So cycle count is just an easy way for the technician to update the system with an accurate inventory level. If you imagine the technician's in the back of his van counting washers or nuts or bolts, he's not going to have his laptop around but this allows him to have a tablet or a phone so he can have this right in his hand while he's counting washers and it will provide a picture of the item, the item name, the item description and then he can, right from here, enter the quantity he has. He can count 10 washers, put 10 in, process it and now the ERP system has a fully trusted and accurate inventory level for his van and all the other vans in the field. The last example is something I just wanted to show the SMS integration. So if we remember, we talked about 400 technicians, 1,000+ calls on a daily basis during their heavy season. Sheetz really does rely on their vendors to provide that best experience for the customer. If we're looking at 1,000 calls on a typical summer day, they don't have all the technicians to work on these calls. They're going to assign some of these calls that need to be addressed right away to vendors. If you think about the vendors that they're using, they're plumbers or maybe they're landscapers. They're out there doing their work already. You don't want to require them to go into a system or do something to get in the way of their business so we send them a text message saying, "Hey, you've been assigned this work order," and they can reply quickly, 'yes' or 'no', whether they want to work on it, whether they accept it or not. If they accept it, great, it's assigned to them and then they can take care of the issue. If they say no or let's say a period of time has elapsed, we'll set an hour time period as an example, if they haven't heard back from a technician for an hour then the system will recognize that and then go to the next trusted vendor on the list, send them a text message and so on and so forth until they can get their problem resolved and continue the wonderful customer experience that they strive for. That's it for the examples, the specific examples that we're going to talk about for Sheetz.

Ameet: OK. Thanks, Eric. Nice job. Guys, let's see if we can quickly summarize. I hope that today we were able to demonstrate how the Agile Platform fits into the pace layered model well and how it's created, really, an amazing differentiator for us at Conigent and ultimately how at Sheetz we were able to deliver highly differentiated applications at record speed without modifying source code of the ERP application.  All the while, we're doing this while maintaining quality and preventing ourselves from ever having to refer to these applications as legacy applications. I think what I'd like to do is I'm going to have this slide here. It shows more information so if you'd like to learn more about OutSystems or Conigent you can visit or If you have any questions for Mike or myself, you've got our e- mail addresses listed there. I think at this point, Heather, we're going to field some questions that have been coming in?

Heather: Yes. I would like to do just a quick summary and then we've already got questions coming in which we want to address as quickly as possible. Thank you, Mike, Ameet and Eric. I think that was a great discussion. I also think it was a great example of how unique applications that serve unique business needs can quickly and easily be combined with systems of record. What I want to do for just a moment is just to go back and summarize the key concepts. We covered a lot of information today so I just wanted to make sure everyone's got the key takeaways. What I was thinking is the first one is around taking a pace layered approach being a very effective way of dealing with application change and following those guidelines that Mike addressed right up front at the beginning of the discussion. The first one being isolating your ERP within API. Number two, embracing a build to change mentality and, three, supporting extreme release cycle for mobile development. I think the Sheetz example demonstrated how to do that by starting with their system of record, their Infor ERP, and extending it out with web and mobile technologies, which is something that was basically innovating and differentiating them from the competition. The second key takeaway is just that a high-productivity platform such as the OutSystems Agile Platform, it does offer the abilities to build those innovative applications that had previously been out of scope. These platforms really should just be an essential element to develop applications or extend packages because with a platform like that, applications are inherently already built for change. They're supporting those extreme release cycles. They can easily integrate with other systems, ultimately enabling IT to more effectively support those goals and missions from the business. Mike and Ameet, did I summarize these concepts correctly or do you have anything to add?

Mike: From my side, Heather, that was great. Very good. Ameet?

Ameet: Nope. I'm in agreement.

Heather: Excellent. Well, thank you again. While these questions are coming in I did want to just remind you guys if you want to get more information, if you want more info on the pace layered model, the information is easily accessible via the Gartner website. On the OutSystems website we do have a couple of more resources for you as well. We have the recent Forrester report on the value of new high-productivity platform and their perspective on the OutSystems Agile Platform as well as other products in that category. We have case studies of some of our 300+ enterprise customers are dealing with some of these challenges we've discussed and then finally, if you do want to experience first-hand the power of a high-productivity platform from our site, you can also download a trail of the Agile Platform for free and start developing those applications that are built for change. We also have the Conigent website where you can learn more about their team, their services and the clients and the work that they do to help solve those challenges as well. That's my final plug. We have quite a few questions coming in. I did want to jump into a couple right up front as, at the end of the webinar we were talking about integration and we do have a couple of questions right now related to that topic. The first one is, "You mentioned being able to integrate. How did you use the Agile Platform to integrate to Infor?" Then, while you're addressing that, if you could also talk about the other question, "Are you using a third party for SMS integration?" If you could touch on those two, we'll go ahead and let you address that question.

Ameet: OK. Well, this is Ameet speaking. I can address that. The first question was around integrations. The Agile Platform provides something called "integration studio" so we're able to leverage that and Infor exposes their API by a Silk web services. It's as simple as pointing at the whistles and, frankly, we're off and running. It's very straightforward and easy to extend via those isolated APIs. Then the platform also supports native DB integration so Oracle, SQL server. Then there's also some common connectors. For applications like SAP, or Oracle there's common connectors already prebuilt into the Agile Platform. Then I think your second question, Heather, was it around SMS?

Heather: Exactly, yes. It was, "Are you using a third party for SMS integration?"

Ameet: OK. So from an SMS integration perspective we leveraged a partner called "Twilio" and Twilio has a fantastic product. They've made an SMS kind of, what was a not so straightforward integration very straightforward. Leveraging the Agile Platform, as I recall, we were able to build that integration in about 45 minutes. It was really straightforward.

Heather: All right. Well, there is still time to submit questions. I see one more here. We talked a little bit about nonfunctional requirements and one of the questions is what do we mean by those and how does the Agile Platform help.

Eric: I can take that one, Heather. The Agile Platform, well, first of all, what we mean by a nonfunctional requirement is, effectively, what I like to call "the -abilities". For example there's usability, scalability, reliability, maintainability, which in many cases just means good documentation, and then of course performance and security. With the Agile Platform, since it's a model-driven development environment and we generate the backend source code, the generators take care of really addressing all these core, nonfunctional requirements other than usability of course, which is almost more a design thing. It has to be built-in but even there the platform provides a lot of support for usability so hopefully that answers the question.

Heather: Great. Thanks. Here's one that's kind of interesting. "What do you do about these mobile applications if you have no network?"

Mike: I don't know exactly how Sheetz has addressed this but of course with the Agile Platform we're generating HTML5 CSS3 compliant mobile applications because all of our customers sort of in the B2E world (business to employee world) are embracing BYOD (bring your own device) type mentality so they really can't afford to build for lots of different native platforms. They're building them mobile web and then of course when they need capabilities like offline, which is important in lot of situations, we see it a lot with warehousing apps, etc., where in the center of the warehouse, big, steel structure, you don't have any good network capability. If you're a sales guy walking in there you can't count on your 3G or 4G connection. In these cases, what we see our customers do is they leverage phone gap. They wrap the mobile web application with phone gaps so they can get access to native device capabilities and do some basic storing and queuing type capabilities so that's how they're solving it. I don't know if this was a requirement for the Sheetz implementation if the guys can talk about that or not. Ameet?

Ameet: Actually, it wasn't. All the stores are wired and have wireless access on their internal networks so for us that wasn't but certainly the phone gap solution is a great solution when you do need the native apps.

Mike: OK. Heather, anything else from the audience?

Heather: No, I think we've pretty much reached our time here and we've addressed most of the questions, so I want to thank everyone for attending. I want to thank our great speakers and just remind all of you to stay tuned to OutSystems this year. We've got several informative webinars that are already being scheduled so we'll have some great content to continue to invite you to attend. Thank you.

Mike: Thanks, guys.

Ameet: Thank you.

contact pricing