Align Application Development Strategies to
Gartner’s Pace-Layer Model



Jeff: During the webinar, we will share OutSystems' recent research with Gartner on applying their Pace-Layering approach within enterprise IT organizations. We'll be presenting key concepts of the model, identifying common challenges the model presents to IT organizations, and propose recommendations to overcome those challenges while working to improve IT effectiveness. My name is Jeff Newlin, and I'm the General Manager for OutSystems in North America. I'll be the host and moderator for today's session. Joining me today is Mike Jones, OutSystems Vice- President of Marketing. Now don't let Mike's current title fool you. Mike may be in marketing now, but he started out almost 30 years ago as the COBOL programmer at EDS. After a few laborious years of programming at EDS, Mike realized there had to be a better way to design and code applications. So he joined the newly formed software division at Texas Instruments and over the next 10+ years, he advised hundreds of organizations on how to adopt the information engineering methodology and how to use TI's model-based development tools to modernize application delivery. Since then and 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 firsthand IT's struggles dealing with these shifts, trying to use various approaches from waterfall to object-oriented to component-based development and now Agile. I'll turn things now over to Mike so we can learn how IT effectiveness can be greatly improved through Gartner's Pace-Layering approach. Mike?

Mike: Thanks, Jeff. That's a great introduction and I'm still a marketing guy in denial for all of you folks who are listening. But it is what it is, as I like to say. So let's get to it. I've asked Jeff to play the straight man and really sharing the content today is pulled from a lot of different discussions and research that not only I've been doing but really the team at OutSystems. The center point here is talking about Gartner's Pace-Layer application architecture. This is a model that these guys have been presenting for well over a year and a half now. You can go Google it, find their research online. It's some pretty interesting stuff and they actually give a portion of it away for free. Another piece that we're going to share today is based on another piece of content from Gartner, which is what they call the framework for the lifetime total cost of ownership of an application. I find this very compelling and it's part of thinking strategic around how this Pace-Layer model can impact your current challenges with your IT investments today. We also borrow from Forrester and even Jeffrey Moore in his book "Dealing with Darwin" to round out the concepts that we want to present to you. So to get started, Jeff and I thought maybe we should actually share some current IT challenges, which really set the stage for the Pace-Layer approach. So these challenges, as we all know, come from multiple fronts but the stage that we want to set is really around two core challenges. The first one is pretty straightforward and I think we're all aware of this. The demand for new business applications is increasing at an unprecedented rate and the general thinking as I go out and talk to lots of different people is this is driven by a couple of things. One, it's really driven by the business who's faced with a challenge to deliver new, innovative ways to go to market, new products, etc., and they're realizing that technology's at the forefront of this more than ever; especially as they're trying to deal with the global nature of the economic situation we're all in today with our businesses. So the Internet has really broken down tons of boundaries and it's easy to serve customers around the world if you can embrace a strategy that lets you do that. So this demand is presenting some interesting challenges so let's take a look at the pressures that we're seeing and hearing from the analysts. This chart is really based on some research that one of the Gartner folks, a gentleman named Andy Kyte presented earlier this year, and I happened to be in the audience. What Andy said is that research is showing that application backlogs are now growing at a 10% to 20% compounded annual growth rate. Now, I don't know the situation each of you guys are in, but more than likely, you've got a backlog that you probably can't realistically deal with as it is, and if it's growing at this rate, this means that within the next five years, your backlog's going to be double what it is today. My guess is that your budgets and your ability to deal with that backlog will not increase at the same rate. So we all know that keeping up with business demand is an issue and if this trend is really true, what impact is it really going to have? This is obviously some speculation, if you will, but certainly the trends that we're seeing in the market make this feel very, very right. The first thing that we think is going to happen is that your businesses are going to turn more and more to software as a service solutions. Quite frankly, while this might suffice in the short term, long term, you're going to find the situation that we've been calling "cloud sprawl" or, effectively, the rise of legacy 2.0 because this new wave of applications that the business is going to go purchase is going to present different challenges than our traditional legacy has presented in the past. These challenges are going to come at us because it's not going to be about sort of the daily maintenance grind but it's going to be driven by a loss of control of your corporate data and demand for complex integrations to effectively break down the silos that our business partners effectively create. So the rise of legacy 2.0. The second thing that we think this need for more applications is going to put on us as IT professionals is a demand for great applications. You may be scratching your head thinking, "Mike, what the heck is a 'great application?'" Well, a great application isn't an application that's just delivered on-time and on budget that meets the business requirements. A great application is really an application that is something that the business finds very easy and intuitive to use and really delivers on the value proposition that is being driven by consumerization of IT today. So the new millenniums are really pushing a wave of user experience that, quite frankly, as IT professionals, we haven't had to deal with in the past. So really, we believe, and if you start looking at what's being written about in some of the leading indicator trend magazines, UX skills are paramount today, and they're jumping right into the mix in terms of what we, as enterprise IT professionals have to be able to deliver and manage to as we're building out the next generation of applications to support our business.

Jeff: Hey, Mike, one of the things that comes up quite a bit when you talk about great UX is around the consumerization of IT, the proliferation of mobile and social and the expectations of the new workforce that's coming on. It's the downloaded app mentality for everything. Can you comment on how organizations are dealing with that? Not just on the UX, but how training becomes involved as well.

Mike: Well, you know, Jeff, it's an issue that at OutSystems we've been looking into for, gosh, a year and a half, two years now where we're putting together not only recommendations within the solutions we bring to bear in the marketplace and the training that we give our own people, but we're now rolling this out to customers, so there are things we can do on the training front. Of course, historically we've always seen usability experts, if you will, get in the middle of our application development projects, and I chose those words very carefully because that's really what it feels like is we get these UX guys that they sort of screw things up. The problem is that this is now a paramount issue. We can't expect that we can bring in a UX expert to help solve the problem. As IT professionals, we all need to become UX experts. That's really the challenge I think we're faced with.

Jeff: That's great. Thanks, Mike.

Mike: You bet. So the rise of a huge backlog of application demand is the first challenge that really sets the stage for what we want to drill into today around the Pace-Layer model. The second one is really a little more strategic in nature and I like to call it the "KTLO dilemma". All right, so I probably have some more head scratching, right Jeff? What is KTLO? This is pretty straightforward. It stands for "Keep the Lights On" and sometimes I like to say, "Keep the Lights On Dummy". We all know that we're challenged at IT pros to deal with legacy and that lots of times over 80% of our annual investment goes to the care and feeding of all the stuff that's gone behind. We use terms like "technical debt" and all kinds of stuff but the reality is that only a small portion of our annual investments go to really driving business innovation. As I said already, the business is looking more and more to IT to be a center of innovation, so sort of the crux of the problem. But it actually gets a little deeper than that because when we think about it from a business perspective, what we find is that-I like to use the iceberg image here - the business only sees IT as what's above the water. They really don't have an appreciation, nor do they really care, quite frankly, for all the stuff that we have to do under the water to keep the lights on. So that's a real problem. A good way to illustrate this is through some of this additional research that I mentioned that I want to present today from Gartner around the total lifetime cost of an application. The first interesting finding, really, from this research was the average lifespan of a business critical application. Let's take a minute to think about that. For you guys in the audience that's listening, how long do your applications live? These business critical apps, are they one year? Nah, we know that's not realistic. Do they last five years? That's probably the horizon we think about when we're building one of these applications, but in reality, they probably last 10 years or longer. Jeff, you've been in this business as long as I have, really. Share with the audience an application that from your past that has lasted longer than you probably ever dreamed.

Jeff: It's amazing how fast the time goes, and this is one of the most interesting pieces that I had from the Gartner research that we were working on, which is you only think you're building an application with an ROI or total cost over three to five years, and that's just not the case when you really look at the statistics. So I became a believer, and I thought back to an application used in my previous company where I was for just about a decade, and we brought in a CRM application,, in 2001 into that company. It is a package, not a custom application. We were a startup at the time, but to think that that application is now going into its second decade of use within that company, and when I think back to how much of a legacy we were creating with it, without any kind of architecture or structure. So it almost ties back to what Mike was saying earlier that that is definitely legacy 2.0. Not only do you have an application that's aged quite a bit, it's evolved as they've done upgrades, but the way a company uses it doesn't always keep up and eventually we just had to turn it over to IT because the business couldn't keep up with it anymore, and IT was none too happy to have to take on the burden of maintaining and extending that application.

Mike: So the reality that these business critical applications do end up lasting a very, very long time and really the research that Gartner found is that business critical applications, on average, live 15 years. That was the average from the research finding. That's really, as we think about it, probably isn't all that surprising, but it's a sobering reality. The second piece of research that was really interesting from findings from this research that was really interesting was the cost of that application when we originally built it, the initial cost of the application when it was first delivered, first time it went to production versus what it cost over that 15-year lifetime. What Gartner has found is that it's actually a very small percentage. What drives the initial application cost as a percentage of total cost of ownership were two key things. One, how volatile will the business processes and effectively that application be over its life? So Jeff's example of simple, you put down your credit card and you get it but then we start configuring it and trying to adjust it to work for a process, but then the process changes as we grown in scale so it's continuously being changed. So the rate of change is a big driver that impacts this initial cost percentage, and then the other one was whether or not the application was originally built and designed to support change. If you look at a model, if you look at some numbers, let's just throw out a simple example where let's say we're going to build a new application for a business process. Maybe it's a new market entry. It's been sort of proven out, and we invest $500,000 to get this application up, running, probably we outsource it today. Maybe we did all of the development in-house, but we got the application built. If this business process is one of those, it's going to continue to evolve and change, which, in this scenario I've described it probably will. And if we built this application under tight timeframes, and we sort of did it as quickly as we could, in other words we didn't really invest in architecting it for change; we'll suffer from that worst case scenario, which Gartner found was 2%. So what does that mean? The original application, as a percentage of long term total cost of ownership is only 2%. So if you do the math, some of you guys are probably pretty quick, that means that over 15 years, this application is going to cost the business $25 million year after year. If you do that, that's a big number. It's almost hard to believe. So don't panic, we're going to come back to this and drill into it a little more, but let's look at this ongoing technical debt, if you will, from a different perspective. So it's the same idea but let's look at it this way. Let's say that this year, we entered the year 2012, we knew we had a legacy portfolio that we're going to maintain, the KTLO stuff, and we're going to deliver two new apps. Great. We get those built and it's almost end of the year. They're in production, life is pretty good. When we roll into next year, probably what we didn't really budget for this year was the fact that those two new applications were going to add to our legacy maintenance burden. So therefore, unless our budgets grow at a bigger rate than they've historically done, we're going to get crunched to deliver new stuff in 2013. Of course if you play this out over several years, this is a situation most IT organizations find themselves in today. The majority, that 80% of their annual budget is going to keeping the lights on and maintaining existing stuff and very, very little is going to investments to help drive business innovation. This is really a great place to introduce the Pace-Layer Application Architecture. So here's the model from Gartner. It's pretty straightforward. It's got three layers. The first layer is called "systems of record". On top of that are "systems of differentiation." I never say that word right, guys, I apologize upfront. And of course, "systems of innovation" at the outermost layer. To help sort of get your head around, let's first look at some examples. In systems of record, we typically find things like payroll, financial systems, your ERP applications, etc. But the key things all these applications have in common is that they tend to support very stable business processes, which of course are critical to run your business but they don't make it unique from your competitors. That definition alone sort of sets the stage for the outer two layers in the model. Systems of differentiation, here's where we tend to find things like human resources. You may be saying, "Wait a minute, Mike. Human resources, isn't this a sort of stable commodity business process?" But if you really go back and look at it, we see a lot of churn in HR. You see a lot of new, innovative ways to go about managing your employees as they become a critical resource in today's world of sort of white collar workers. Also things like order management, energy trading, these are all great examples of systems of differentiation. Now, the key thing about applications in this layer is that they support business processes which are continuing to change and evolve to meet improvement to the operational processes, the business, new market demands, etc. So they're critical, but they're still evolving. Then, of course, out on the edge, the systems of innovation, this is where we find applications that I like to think of that are being invented out on the edge of the business where a lot of the trial and error is happening. Good examples today are applications for enterprise mobility, social, new market entry-type applications, etc. So those are some good examples, and before I sort of drill into the major concepts that form the model, I'd like to share a common confusion that we actually struggle with even within our own IT here at OutSystems because we're applying this model ourselves. It has to do with the bottom two layers. Really, I think it's based a lot, Jeff, on the name system of record, but the point I want to make is that in those two layers, you've got mission critical applications. In other words, if they go down, your business is in trouble. And they both actually have core data. Just because systems of record uses that name which lots of times we think around data, it's not that concept per se. So they're both mission critical. They both can have core data and, of course, there's obviously integrations between the two most of the time. So with that said, let's lead to the first concept that really defines a layer and it's this notion of rate of change. Applications within each layer have different rates of change ranging from really a snail's pace, all the way up to extremely fast. So if you drill into Gartner's model, what you find is that systems of record are typically very stable with minimal change requirements, usually annually, and it's more like annual upgrades in most cases. For systems of differentiation, we tend to see change that happens at a more frequent pace, effectively quarterly. Then out at the innovation layer, we see very, very rapid changes. The business is innovating and going through rapid change cycles, so we sort of think of these as weekly change or on- demand. In reality, guys, we all know that requirements come from lots of different places and actually impact different layers in this model. So the recommendation really is pushing you to focus on speed at the outer two layers while the bottom layers are focused on stability, security and performance. So that sort of puts the systems of differentiation in the middle in an interesting quandary. So that's the first key concept, Jeff. The second concept is you really need different governance and software development lifecycles to survive. So since applications evolve at different rates of change, one set of governance processes won't suffice. How many times have we been on a project where everything is done, we've got user acceptance tests, everything's signed off, and we're ready to go, but since we were a week, two weeks late, we missed the production window, so it's now delayed six weeks, two months, whatever it is, for the next release cycle? That really doesn't work in today's world where we need to be able to have different release cycles to support applications that really require a different amount of risk management and support the pace of change that they have to go through. So what Gartner recommends is that for systems of record we do apply a very low-risk, highly controlled approach often associated with what we've always called "the waterfall methodology". As Jeff indicated, my old life of information engineering played very nicely here. However, as we move up for systems of differentiation, we really see an iterative approach is what Gartner says. At OutSystems we like to call this "controlled Agile". So it's an Agile approach. It's sort of a quarterly release cycle. There are maybe even some sprints in there, but it's a very controlled Agile process to manage the risk versus the need for change in these types of applications. Then of course, for systems of innovation, you really need a governance in SDLC that lets you move very, very fast. So Agile plays nicely here and what we really are seeing is this is more like what we call "extreme Agile" where applications are evolving almost on a weekly basis, literally in production, and sometimes they can almost be updated on a daily basis for some of the new mobile initiatives I see some of our customers trying to implement. So aligning the governance and software development approaches to the needs of change, the pace of change-now you understand why they named the model this way-at the different layers. Make sense?

Jeff: It does. Hey, Mike, can you comment a bit on when you go through there, we think about development, and we think waterfall, I think in most companies release management or dev ops is much more comfortable and much more aligned with the risk of a systems of record approach versus waterfall. Not a lot of updates, highly planned, you think about it for weeks or months at a time. Then you kind of do the release. Can you comment on how organizations are dealing with the changes they have to go through in release management or more than dev ops or development operations?

Mike: Well, actually I think, you know, you said that maybe it's a sort of a marketing high-tech term called dev ops because we see a big push in our industry around this notion of dev ops, which is really the realization that we need to identify different ways of governance for different types of applications. The movement isn't necessarily couched in exactly this model but it's been sort of professed more around as Agile has become more and more a way of delivering the reality that, "I do want to release more often, so I've got to change some of the governance processes that new moniker, "dev ops". So the good news is that organizations are, in many cases, already starting to deal with the governance side and, in effect, with the SDL side of this challenge, just not maybe from an architectural approach like Gartner's professing with the model. Okay?

Jeff: Yep. Thanks.

Mike: Cool. Good question. So this leads to the third concept. The third concept is that applications change layers. It's pretty straightforward, right? Think about this. I think of this as most common when a systems of innovation that was for a fairly volatile, we're in invent mode-type process all of the sudden starts to get traction and becomes more business critical, the next thing you know, and we see this all the time, is, "Hey, IT, you've got to take this over." You sort of said that with your Salesforce example, Jeff, right? At some point it was like, "Well, wait a minute, this is too important and too critical . . ."

Jeff: Too hard

Mike: ". . . too hard. Let someone else take this off of my hands." The guy that's holding the bag has always been the IT organization, right? So when applications need to move down, because that's really what Gartner says is they sort of move down from outer layers to inner layers, it happens because processes start to stabilize. It doesn't mean they get completely stable. And they become more business critical, so the apps have to support scale and all kinds of stuff. A good side note is from Forrester research recently where they talked about the amount of investment organizations make to systems of innovation, and the fact that it's okay to fail out there. It's sort of interesting, as IT pros, we want every application to be perfect and never not be a success. But the reality is that at this outer layer, a lot of this stuff is almost disposable in nature. We build it, we play with it, we try it, "You know what? This isn't going to work," and we kill it. And that's okay. The research from Forrester said, "If you don't have about a 20-50% failure rate for your systems of innovation, you're probably not taking on enough risk from an IT perspective and a business perspective." So it's sort of cool. It almost says, "Guys, if you layer this stuff right and you organize, then you should realize it's okay to fail at certain layers in the model." So those are the concepts that form the Pace-Layer model from Gartner. And to sort of wrap it up, Jeff, actually, Jeff, why don't you wrap it up? Let's see if you got it.

Jeff: Well, I think I do and we see an example of it. When you think about the last item you were going through, which was the applications changing layers, there's an example that I think everybody can relate to that we see a lot in the projects that we're talking on and our customers are taking on with our applications and that's Lotus Notes. So I've been around long enough to remember when Lotus Notes was an innovative application and it was being brought into organizations where IT was struggling to keep up with the needs. Lotus Notes groupware was an easy way to go in and quickly build applications that business needed to track whatever they wanted to track. Those applications started to move into the differentiating area where it was necessary for the business to continue to compete and differentiate in how they were going to market. Where we're seeing it now is folks are trying to get away from that as quickly as possible. There are challenges with no new development on that. It has become a legacy. It's a licensing issue, and it's not keeping up with the new and innovative ways people are wanting to look at applications. The UX isn't as good as it should be. It doesn't go to mobile. It doesn't integrate well into a better UX environment. So Lotus Notes is a great example, if you go back and look at it, we're working with two companies right now that have thousands of applications each in their application portfolio that are Lotus Notes and they need them to run the business, and they're going through the approach to replace those that they go through because they're now part of the system of record and they're preventing differentiation and innovation.

Mike: Good summary there, Jeff. Really it leads to one of the major challenges that we see presented by the model, and that is what happens when the applications built out of the systems of innovation do need to scale, and it usually becomes a rewrite scenario. We've seen this time and time again where organizations have to effectively redeploy these applications. This is due to that often these applications are built out of the department, sometimes they bring consultants in, sometimes they use IT or they have their own IT teams, which we refer to as shadow IT. Lots of times we see technologies, like you mentioned, Jeff, today, even more modern stuff like SharePoint, obviously Excel is huge. We see a huge number of people with Excel databases or now Google docs, stuff in the cloud if you will. But I don't want to mislead the audience because it's not necessarily the technologies that cause the rewrite problem. The problem is a little more endemic than that. The rewrite is really due to the reality that it's very slow and complex, and expensive, to deliver a highly volatile systems of innovation that's architected for change. It's just too expensive to do that so we do use a technology that lets me go fast, but I don't ever invest in that technology being able to scale, etc. We effectively don't make an investment in what I call the "non- functional requirements" when we're initially building systems of innovation and thus we end up having to rewrite them. So that's a challenge we have to pay attention to and think about. The second challenge the model presents is really down at the bottom in systems of record. This is something that we've all dealt with and understand, but it really puts a good light on it when you think of your application portfolio from this perspective. In this layer, if you remember, we have applications that are supporting business processes, which are very stable, thus the applications are fairly slow to change. Therefore, the functions, while they're critical to your business, are not providing a lot of differentiation. We often see packages dominate today, down here, at this bottom layer. But, once again, I don't really believe it's the package itself that's the problem. The problem is when we go and start making changes to the package and the way in which we go about making those changes because, in many cases, there are some levels of differentiation even around a system of record that need to be handled. In many cases, we make these customizations in such a way, either leveraging technology from the package vendor itself, but the reality is that the applications become hard to change, hard to maintain; therefore, upgrades become much more complex and effectively, we get locked in to our package vendor. We've heard time and time again from different organizations that today they feel "held hostage" - is the word I hear a lot - by their package vendors. So it's a challenge. The third challenge that the model really brings to bear is that the systems of differentiation layer. This is really where those applications that, by definition, are unique, it's hard to go buy a package for these most of the time so they really demand custom development but what we really find is that we tend to make one of two key mistakes. The first mistake is that the business often wants to pursue purchasing a package even though it's a very differentiating business process and they're doing this because of the risk associated with hand-building, hand-coding. However, it ultimately results in the same exact challenge number two was except - guess what - we did it knowingly. We bought a package knowing we were going to customize it and now we're in deep doodoo.

Jeff: Mike, I'm sure it's going to be an 80% debt. I'm sure we'll just be customizing around the edges, right? Our business is just like every other business in these applications, right?

Mike: We hear it all the time, and I know you guys do as well. The second challenge, of course, is that when we do go and do custom development, we tend to use technologies like Java or .net. The issue that this presents is applications built in these languages, they tend to be slower to deliver. They do take time. It's usually very complex, and last but not least, the applications tend to be hard to change. This happens from lots of different reasons but the primary one is most of the time, we either outsource the entire development project or we bring in third parties to help, and the reality is that when it gets turned over to us in IT to maintain, the learning curve is huge because the documentation isn't there, we didn't invest in build to change, usually, for these types of projects.

Jeff: You know, Mike, we talked about even in those applications where it is built within the organization, within the IT team itself over time, due to workforce mobility and people moving forward in their careers, people changing companies, is even if it doesn't start outside the business, those who are actually maintaining this application in year 5, 7, 10, 15, they're nearing retirement like you, or it's just a whole different team. As much as we try, maintaining that knowledge of the application, documented and so forth, just doesn't exist.

Mike: Very difficult and it's all part of the problem. Exactly. So, guys, some recommendations to try to overcome some of these challenges. First, go and continue to invest in dev ops. You need to organize your portfolio differently than maybe you have in the past, and if you invest appropriately in different governance to support applications of the different layers, you're going to streamline operations and make it easier to deal with the process and the backlog that some of these applications that are in the upper layers of the model. The second recommendation is embrace a development platform that lets you build fast, change faster and really, most importantly, handles all your nonfunctional requirements. In other words, makes you automatically deliver an application that's built for change. Sounds like nirvana, but it's really important, and it's starting to get a lot of push in the marketplace today. The third one is really go about breaking this chain of what I like to call "bad legacy," but it's any type of legacy project that is today hard to maintain and puts you into a dilemma, the KTLO dilemma quite frankly, from an ongoing maintenance perspective. For example, if you've done bad customizations of a package, invest in one at a time rewrites of those customizations into a technology that's more flexible, easier to change, really giving you the ability to upgrade the package easier, maintain those extensions, etc. The last piece, Jeff, is really to aggressively start to retire and replace low-value legacy apps. We tend to do a very, very poor job of retiring stuff. If you think about this, guys, it can have a pretty interesting impact on the KTLO dilemma.

Jeff: Mike, we had a couple of questions and just some commentary coming in from some of the folks in the audience, if you could pop up one slide again regarding some of these concepts. Can you comment a little bit on the approach you need to take in managing the risk of taking these applications and replacing them? Some of the comments were lost. When you do that replacement, the original knowledge of the application's trapped in the application so how do you pull that out? Then along that same line, how much of the existing app do you really want to focus on, assuming it's aligned with the business, as opposed to looking at business process change that the application's trying to support? So with those comments and questions we've had from the audience, can you kind of pull in some of those ideas?

Mike: Yeah, I mean, it's obviously a fairly complex challenge, and we see our customers do a couple of different things. The cloud actually, believe it or not, is doing a lot of fuel for getting customers who want to move some of their legacy portfolio really to a more modern infrastructure. A lot of these applications that we're talking about, quite frankly, are really still mainframe-based apps. They're classical-type stuff, so it's really a rewrite exercise. The business process is, in many cases, fairly stable, but the maintenance side and just the upkeep is what's killing them; so therefore, they really don't need to invest a lot in reinventing the wheel, but they do need to invest in moving the technology base. So this is a great opportunity to redeliver the applications, leveraging a productivity platform almost, if you will, but putting them into a base that lets them be more flexible for ongoing maintenance. Now, of course, if look at what our customers are doing, guys, if you think about your own portfolios and where you probably have done some of this already, you always end up investing in some incremental improvements. By default, by re-architecting the application, it usually gives you the ability, if you do it right, to put a mobile interface on where it makes sense to address some of the new mobility needs. Obviously you're probably going to deploy in a much more flexible architecture or web-based architecture today than the old pipe servers, certainly mainframe-based approaches of the past.

Jeff: I would imagine-just to follow onto that quickly-when you look at the enhancement backlog that is being asked for, a lot of times the rewrites can really address those. Because a lot of those, especially for older applications with the modernizing workforce, a lot of those, and we see it with our customers, as you know, that the request they're making are to put it onto a better user interface, more modern, easier workflow. Why can't this integrate with email? Why can't it do this? Why can't it do that? And this is a chance to get those enhancements in with the full rewrite.

Mike: It really is, and I like to think of myself as a pragmatist. Maybe I'm very jaded in my old age at this point, but I've seen a lot of technologies and approaches sort of go under the bridge, if you will, to try to put a modern interface on an old app and do different stuff.

Jeff: That would be the lipstick on the . . .

Mike: On the proverbial pig, which quite frankly, guys, is a further investment in your legacy nightmare. The reality today with the technologies that are available to us is that it's cheaper and faster to actually rebuild the app in a more modern architecture. So don't kid yourself. Don't let your business folks kid you that these old approaches of the past are going to help. The reality is, in most cases, we need to rewrite and then when we do, we do knock out a lot of the backlog and we end up delivering a much better app. So good questions from the field. All right. So what I'd like to do is sort of wrap up, Jeff, and try to help everyone get their head around the value of the Pace- Layered approach and the impact it can have on the overall portfolio, and the best place to start is by looking at the KTLO dilemma. So, guys, if we take the bottom two recommendations of really trying to reduce the impact of the bad legacy and aggressively start retiring older applications, which in many cases, 80% of the functionality is really no longer business critical. It's not even needed. It can be replaced with a much smaller, lighter weight app. If we do that, the impact is pretty obvious. Now I'm mostly throwing a hypothetical here by showing this but the white space it creates allows us to innovate and do more with a budget that we're going to have moving forward in the future. The second way to look at this is to go back to the individual application investments and the impact that build to change can have on your long-term technical debt. So if you remember, guys, the worst case scenario from Gartner was a 2% application cost as a percentage of the lifetime total cost of ownership, which resulted in these very hard to believe, but proven numbers. So if you do the math, if you were to take that initial application investment and deliver it at really the average that Gartner found, which was 8%, on the high end they saw 16% and those are for low change of volatility apps, and they were built to change, so they saw 16%. But if you go for the middle 8%, look at the impact it has long term. If this app really survives those 15 years, you're going to save 75%, roughly $19 million on this one $500,000 investment.

Jeff: With better architecture.

Mike: With better architecture. That's it. That's huge. It's worth the investment. Now as I said, there's always a catch, right? The catch is that it usually doesn't cost $500,000 to build an app that's designed for change, so let's just hypothetically say it costs half, again, as much, so $750,000 for that application. Maybe it takes a little more time, but the long-term cost savings is still huge. The value of doing this is obvious. It's reducing technical debt on the long-term consequence of an application you're building today. So it's worth making that investment, and I guess this is where I'd like to wrap up with a little infomercial from OutSystems and how we help. So, guys, if you don't already know, as a sponsor of the webinar, OutSystems provides one of these new productivity platforms that Forrester wrote about in their research, and it fits nicely into the Pace-Layer model. For applications where custom development is really in need, the outer two layers, we provide a platform that for systems of innovation lets you build incredibly fast and change even faster. But more importantly, when these apps need to scale, the Agile Platform has built-in support for all the non-functional requirements. Of course, that means that you don't have to incur the cost from a development perspective upfront. In addition, the platform supposed your systems of differentiation so not only can you deliver fast and change faster, but you're going to build highly scalable, secure, and easy to integrate applications from day one. So if you look at this from the KTLO perspective, that $750,000 investment for this mission critical application that should only last 5 years ends up lasting 15, Jeff, if you make the assumption that the platform is going to just get us to the average percent of application, initial investment to TCO, the reality, and we've proven this time and time again, is that the Agile Platform is going to let you deliver that application faster and with higher quality than you could using traditional technologies. There's some great research on that. You can get it from our website around function point analysis, etc. But the reality is that the cost savings are huge with leveraging one of these new productivity platforms. Don't believe us. Go listen to what the analysts are saying. There's some great research out there that is available to you on this topic.

Jeff: When you think about building for change, then when you look at how a product like the Agile Platform, when it addresses all the stages that you have within the life cycle, not just changing the app but migrating the app, handling the dev ops, that's when you start to see that going from 8 to 12 to 16, and you really get the lifetime cost of the application to decrease.

Mike: That is the ultimate goal, really, from our perspective here at OutSystems is to reduce the impact to change on the long-term cost of an application. So, guys, with that, Jeff, you've been my straight man today so can you summarize this for the audience?

Jeff: I'll do my best. I think I took some pretty good notes. You think about the takeaways we'd all like you to have from the webinar today; they really come into three core concepts. Number one is you should be realizing if you don't live in it every day, IT's budget is wrapped up in legacy application maintenance simply trying to keep the lights on and keep the business running. It doesn't necessarily properly fund these innovative and differentiating applications, so the business has to look elsewhere, typically, than the IT budget to get these things done. I think Mike addressed some of the challenges along with that. So what happens, you just keep compounding it even further without the building application architecture for change. IT then continues to compounder for the dilemma and you're just adding more and more into that spiral you talked about that you can't get out of over time. So I think that's one of the key takeaways. The second key takeaway is that the Gartner's Pace-Layered model really is a good way to think about your application portfolio and how you're going to be not only maintaining it but building applications in the future. So when you think about these Pace Layers, and that's the pace of change, whether it's innovation or differentiation, the systems of record, having the right governance and development approach is going to be key to doing that. Then the third is that, although I'm sure there's folks in the audience, there are other examples that exist where organizations have been able to use traditional approaches in order to build these types of change-ready applications, what Gartner's seeing and what we've seen from some of the Forrester research is that IT needs help. You need some of these newer high-productivity tools. You need a better way than just code foundations in order to architect for change over time. So those were my three takeaways, and did I get them right?

Mike: You got them right. The only thing I want to throw out there, being the marketing guy that I am these days is go visit Gartner's website or actually Google search for Pace Layer. You'll find a lot of good information and, of course, come to our website. There you can get Forrester's new productivity platforms, your "Solutions to the AD&D Crunch" paper. We actually own rights to that, so we can let you have that for free. Download it. It doesn't just talk about OutSystems. It talks about the requirements for these platforms and lots of different technologies.

Jeff: It highlights several different products you can look at.

Mike: It does. So go check that out. Obviously, there's lots of case studies on our site for customers who really impacted the way they go about delivering applications, using the platform to speed development and deliver higher quality applications that can survive more change. Then if you're interested, try the Agile Platform for free. It's out there. All right? So that leads us back to one thing that we did with this webinar, which was sort of fun in the spirit of this season is a contribution to Make a Wish Foundation. So I know we've got the guys in back office. Did we surpass our 200 mark?

Heather: Well, I've been watching attendance, and we have met our goal of donating $1,000 to Make a Wish.

Mike: All right. Very good. Thank you, guys.

Jeff: We got a lot more than the 200 we needed, so that's really great. Thanks to everybody for participating today, not only to learn about OutSystems, learn a lot more about how to approach your application portfolio, but we all did this for a great cause at the holiday season by helping some children around the globe have their wishes met through the Make a Wish Foundation so we're glad to do our little part in helping to do that. So, Mike, I really appreciate what you provided today. It was some really good content and some great information. We've just got a couple of minutes left. Do we have any questions that we'd like to try to address? Heather, anything else coming in?

Heather: Let's see. We've got another minute for questions.

Mike: Sure.

Jeff: Okay.

Heather: People want to submit.

Jeff: Okay. We'll wait a second. I think we summarized several of those and got covered in a lot of the commentary we were going through anyway. We'll see if we have any. Nothing else, Heather?

Heather: Nope. Just some really good feedback from the comments side.

Mike: All right. Well, thanks, everyone. Thanks, Jeff, for moderating this and, guys, I hope this really helps as you guys think about your plans for 2013.

Jeff: Yep. Please stay tuned for what OutSystems is going to be providing in 2013. We're going to have several more informative webinars, and stay up to date with our website because we're going to be adding a lot of new content and expanding the way that we're communicating on these topics out in the marketplace. So on behalf of Mike and OutSystems, I'd like to wish everyone a very happy holidays, a prosperous New Year, and we look forward to seeing many of you on webinar next year. Thanks a lot.

contact pricing