Mike: Welcome to today's webinar, The New Productivity Platforms. My name is Mike Jones and I'm your host for today's session where we've asked John Rymer, Vice President and Principal Analyst with Forrester Research, to share his insight into a new class of application development environment that Forrester calls the new productivity platforms. Before I turn the show over to John I'd like to let everyone know that today's session is the first in a series of webinars on IT productivity. Today we're going to focus on application development tooling. For our second webinar, we will shift gears and look at application delivery methods. Specifically, Session 2 will focus on 10 best practices for applying Agile in the enterprise. The last in the IT productivity series will look into the area of DevOps and offer some advice and tips on how to further streamline your delivery processes across the entire IT organization. I hope you'll join us for these upcoming sessions, but now it's time for the show. Guys, let me turn the show over to John Rymer. John, over to you.
John: Thanks Mike. Thanks very much. Hi everyone. The new productivity platform is a term that I coined to describe a collection of products that I had begun to observe in my work analyzing application development platforms. During the course of about 18 months, I just was amazed at the number of companies, and OutSystems was one of them of course, that had been able to create development environments and runtime platforms that really were quite different from the typical Java, C Sharp, Java, Microsoft, or any kind of development platforms. It seemed to me like there was really something going on here. Then at the same time I was dealing with a constant stream of client request. "Help us figure out how to be more productive. We cannot keep up with the business. We cannot deliver fast enough." I think these two developments, one is a development in customer requirements and the other is a set of developments in the industry, some technical innovations in the industry, are coming together at a very nice timing because certainly the need is there to deliver faster among end-user organizations. Here's this new generation of application delivery platforms that is squarely aimed at satisfying that need. There's a really nice convergence here that's going on. That's why I say this new generation of delivery platforms is arriving just in time to meet the needs. I think it's a very nice happenstance here. This chart just shows some of the data. We've got lots of other survey results as well that illustrate this problem I was highlighting earlier. Our clients are really struggling to keep up with the business. They just cannot deliver fast enough. They can't deliver initial applications, first releases, fast enough. They also can't deliver changes to business processes, business rules, forms, etc. fast enough. You can see in this particular survey the inability to deliver software fast enough, by far, is the primary concern. It eclipses other concerns that we oftentimes hear about from clients as well. This has become second nature to me. It's something we've been working on with clients for so many months and really years at this stage. How are we going to solve this problem? Like I say, there's a new set of products that are out there that I think are squarely aimed at this problem. The collection of products that I looked at literally includes 20 to 25 companies at this rate. I've added some others to my thinking since I published my report on this. That's a large number of companies and the products have some differences. There are differences in the specific customers they target. There are differences in the kids of applications they're good for. Some are very general purpose, some are more specific, but they all share these six characteristics that you see on the slide in front of you. First and foremost, they're all designed to speed delivery and they generally employ different levels or higher levels of extraction so a developer or even a business person sometimes can create applications, they can create forms, data spaces, flows, rules, etc. within an application. They can create those very quickly and deploy them very quickly. That's in the first release. Then beyond that, these products are designed to allow for changes very rapidly. Making changes to business rules in a day, making changes to business processes in a day, and making changes to forms very quickly and without spending a million dollars to add that field to the form. They're aimed at deploying applications very, very fast. Part of the method here is: deploy quickly so you can test. You can actually use the application or put it in front a set of users to run it through its paces. That's how you basically quality assurance. Use it in a controlled environment before you get the production. It's different from the typical test-build- deploy cycle. Empowerment of business experts in the delivery of apps is a very important aspect here. Even the products that are aimed at professional developers incorporate features that make it very easy for business people to essentially look over the shoulders of developers or sit with the developers and work through the creations of applications. Some products actually provide tools that are directly aimed at non-developers to help them create applications. Some aim at non-developers for maintenance only. There's a very strong theme here an empowerment. Lastly, the last couple here I think are very new. One is the leveraging of platform and internet standards. In the past, we've seen things like fourth generation languages that sought to raise the developer productivity, but they were all propriety technology. A lot of people were burned by that generation of technology. They got orphaned when the companies were acquired or what have you. It's different this time. Most of these products, the vast majority of them, either generate or are aligned with Java.net, HTML, HTML5 now and other sort of commonly used standards. There's much less of a chance that you're going to get orphaned if a vendor gets acquired or goes out of business. Then the last one here is that cloud has become an option at about the same time that all the technical developments have been going on so the vast majority of these companies give you the option of deploying either on-premise or in a cloud. They give you the option of doing hybrid architectures. The ones that are moving really quickly here, which is a fair number of them, are embracing mobile. A lot of our clients are trying to basically incorporate mobile into their strategies now without having to create entirely new environments. These are the characteristics that really define these products even though there are some differences between them, as I mentioned earlier.
Mike: John, let me ask you a couple of questions. I guess the first one that certainly is probably on the minds of the audience is that a lot of the characteristics you describe sounds like these tools are probably a really good fit for some of the departmental or tactical type applications but do some of them actually really scale and support more enterprise class type application development environments where you need complex integrations with other type of systems and you want to support more of a service-oriented architecture, etc.?
John: Yes. Some do. Some of the products, some of these platforms, are what I consider to be general purpose which means they are capable of handling a variety of application scenarios, like analysis scenarios, transaction processing scenarios, web applications, work flow, you name it. They are also capable of handling a variety of scale, small scale, as you said with the departmental level applications, but also large scale applications, applications that are either complex, involving a lot of integration as you mentioned, or are very large, they handle large user loads. Not all of them are capable of handling complex apps large scale, but a surprising number of them are. Yeah, there is that possibility within this category of products, Mike.
Mike: Okay. Sort of the category's really a mixed bag to some degree. That's good. The other thing I wanted to ask and probe on a little bit was sort of the no test-build-deploy type cycle. That's interesting and aligns nicely with Agile methods and lean methods and things like that. What I'm curious about is if you think of the mix of the platforms that are covered in the research that the reports based on, do they support really just deploy into the Dev environment or they really supporting deployment across the infrastructure, from Dev to QA, QA to Prod, etc.?
John: It's the latter, although it's usually up to the customer to set up the lifecycle, the different environments that they want to deploy in. The products will make that straightforward, will make setting up your Dev test staging production, whatever the sequence is that you're interested in. They'll make that straightforward for you to do. When it comes time to change applications, of course if change needs to happen very quickly, you also have the opportunity to compress those cycles. You'll find some folks that will shortcut a crucial change, a really urgent change. They'll shortcut the normal lifecycle so that they can get, say, a new rule or a variation of a process tool into to production very quickly. A lot of it is the products give the customer a lot of flexibility here to set up the environments that they need.
Mike: I would assume that while these productivity platforms offer great promise for speed and efficiency and effectiveness, they're also going to require organizations to really look at their operational procedures, if you will, and probably evolve those to be a little more streamlined as well.
John: Absolutely. Solving the problem of fast delivery requires much more than picking an effective product.
Mike: Exactly.
John: You've got to organize yourself as well and that's a whole other topic. You're absolutely right. You have to organize yourself effectively to use whatever platform you choose and you have to master the platform as well, as we know.
Mike: John, obviously at OutSystems we're in this business, we think we've got one of these productivity platforms. We were obviously included in the research, but, quite frankly, we've sort of seen this before, haven't we? I know you got a slide to address that, so what do you have to say?
John: I get this question a lot. I get this comment a lot, Mike, when I present this research. A lot of folks, certainly a lot of folks in our client base and a lot of folks I talk to, they've been around for a while. They've lived through the 4GL era and they lived through the CASE era, as you and I both have. They've seen these kinds of promises before. We have to acknowledge that those two eras didn't work out so well. I think we have to be mindful of that. Promises are promises and we have to actually be able to deliver. I really do think there are differences here. When I did the research this is one of the questions that I had to grapple with. Is this just old wine in new bottles or is there really something different that's going on here? This chart shows what I found in my search here, in my analysis, to be different. In the orange column here on this chart, I've just highlighted briefly the factors that I think are really different here. You can see. Just real briefly I'll go through the highlights. First of all, the tooling is different. This is not the kind of tooling we saw with 4GLs. You've got some very interesting ideas I think in the products in terms of how to present the authoring or the creation of artifacts, how to evolve them, how to get feedback on them. There are some really interesting ideas. How to automate creation of artifacts from very high level descriptions and so forth. Then also most of these products do not rely on the old co- generation techniques. The co-generation techniques of the past didn't work out primarily because they would generate code that was incomplete and then a developer would have to go in and write code or modify the generated code. You just broke the link. When you modified that code you broke the link to the tooling. You just completely frustrated the potential benefit. Well, that's not the case here. These products are generating complete applications and they don't break the link between the powerful tooling and the artifacts and the code that's actually being created or generated. Most of the platforms allow immediate changes, as I've said. I find they're very good. They're very flexible allowing for changes to running applications, at a very deep level as well. In the old days, you could change certain parts of maybe the visualization or the presentation layer, but you couldn't change the schema of the database. Most of these tools allow you to go in and change the schema if you need to. Adding fields is something that's very straightforward to do. It's because of the way they're managing the definition of that schema. It's not hard wired to the database. It's expressed in metadata. There are a couple other points I'll make here. The real effort to address business experts here is, I think, really notable. I've put Lotus Notes in here as an example simply because so many people have experience with Lotus Notes. Their experience was that business people could do quite a lot with that product. Think about that sort of involvement by your business people, but even more so because there are only certain things you can do in Lotus Notes. Open up the lens and basically allow them to make contributions to all kinds of different applications, not just in Lotus Notes, document database and work flow things. Really stretch your imagination. It's there. There are really no proprietary languages here like there was in the 4GL days. This was all about metadata. It's all about generating metadata definitions out of these tools then creating the runtime instantiations that are required. Then the last couple, the cloud deployment options, that's completely new. We didn't have that before and that gives us a really interesting opportunities. Then lastly, in the past, the productivity environments were really aimed at desktops and 4GLs were really born to satisfy the needs of the client server era. Well, most of these products have proven that they can address browsers. Some of them address native desktops. Now we're seeing mobile. Single code base, multiple deployment targets and multiple access points. Very different from the past. I think there are some real differences here, Mike. I think there are basically advances from the past that we should recognize and that I think reduce the risks of the past in this current generation of product.
Mike: All right. Interesting. Obviously we get hit with a lot of these questions as well and the feeling is this looks like the last RAD tool I used at 15, 20 years ago and it was painful when I was done. We certainly see this. I think it really requires folks to experience these types of technologies, play with them a little bit, and realize how powerful they can ultimately be. At least that's certainly the advice we try to give our prospective customers.
John: Yep. Agreed.
Mike: All right. Before you jump to this one, I did have one other thing to probe on.
John: Sure.
Mike: We have an interesting question from one of the guys in the audience. I thought it made sense to throw it out here. It's somewhat aligned with the message you're giving, but David Chapel asks, "John, how would you compare the products in this category to vendors who view themselves as private paths? The two seem similar." Do you have an opinion on that, John?
John: Yeah. Thanks for the question. I think some of these products could be and probably should be considered candidates for private paths. Private paths, my understanding of that term, is that a path is a cloud-based development environment so platform as a service, and private usually means that the cloud is installed internally in a customer's data center. It's installed in one of Citibank's data centers or something like that as opposed to being installed in Amazon or in Azure or one the public environments. There is intersection between paths because, as I said, some of these environments support the cloud. Some of them I think should be considered paths. We are undertaking the next round of research on paths at Forrester in the next couple of quarters. Some of these new productivity platforms, I believe, are going to make it into that research.
Mike: Well, certainly from a private paths definition then I would have to say that we would throw the Agile platform in that stack because that's certainly what the U.S. Army, for example, is doing on top of CA's private cloud infrastructure. They're using the Agile platform as the path's tooling. All right. Makes sense.
John: Yeah.
Mike: What else? What's next?
John: The next chart is about empowerment of business experts. I just think this is a very important topic overall. You mentioned the term Agile, Mike, and you guys have done a lot of working on aligning with Agile development methods. Agile development methods, as far as I'm concerned, at the core are about a very close relationship between the folks building and delivering the applications and the business folks who are transmitting, who are creating the requirements for those apps and ultimately will use them and direct how those apps evolve. There's a variety of techniques for doing that, for achieving those goals. One of which is to actually allow business experts to create software artifacts, entire applications, maintenance, new rules, etc. I think it's a very important trend and something I constantly advise my clients that they ought to be pushing this very hard. Essentially there are not enough IT people in the world to deliver everything we need so we have to share the load. Some of the new platforms address this head on, as I said. There's a variety of things you'll see in a platform that really takes this on. What I've listed here are the kinds of tools that you'll find that directly empower business experts to create software. New tools, you can see, there's some very interesting work that's been done, I think, with spreadsheet, Excel-like environments that allow business experts who are usually very comfortable with spreadsheets to create whole applications using that metaphor as their authoring environment. Some very interesting work there. There's what I call build by doing tools. This was the point earlier, Mike, about you build the application by essentially describing the flow or using a WYSIWYG tool to create a form and define the database. then you deploy it into your little development environment and you see how it works. You see what it looks like, you see how it works, you see where the problems are, and then you go back and you do some more. Business experts are very comfortable with this way of working. They like to discover. It's almost like discovering your way towards the application as opposed to sitting down and doing a more formal design kind of like a developer would do. Data and work flow diagraming, people are very comfortable with those concepts. There are products that incorporate those things. Then you'll see various forms of modeling, like data modeling, process modeling. This tends to be more formal. It tends to be more rigorous. It tends to force more a design. Again, it can be very helpful for certain for some business people. They like this approach. The point here is there's a lot going on. There are a lot of different approaches here, a lot of good experimentation I think about how to address and empower these folks that you'll find in these products. Last two, we mentioned test by doing which I think is far more effective for these sorts of professionals than the typical developer, test the bug tools. Lastly templates, one of the things that very helpful, and this should be primarily useful in the departmental case, Mike, is to basically give the business expert a template for a tracking database. How many tracking databases do we build in Excel? Then approval work flows, how many zillion approval work flows are there? Things like team sites. These can be templatized very easily and the business expert just has to add the content, maybe make a few little changes and boom you're done. These are the kinds of things that are important to the operation of any company and IT never gets to them because they're too small. Now, what I haven't listed here is there are other approaches that you'll see where the product's aimed at a professional developer. Really? The product has built-in features to allow business experts to get very deeply involved in the creation of that application. You'll find like the feedback mechanisms that are near and dear to you guys. You'll find just very effective means for very quickly generating a view of the application or running a prototype so that the business can see it can and comment on it and understand it. There are some other techniques here that are even for the products they're aimed at professional developers. A lot of good work here that should not go over looked.
Mike: I agree, John. Obviously we don't really focus our technology at OutSystems on the business expert but we actually see a lot of our customers start with smaller department level apps to prove out the technology. What they find is that empowering shadow IT out in the departments of these larger companies make a whole lot of sense using the technology like these platforms provide because ultimately it is a standardized approach in that these applications do need to scale and ultimately be owned by IT. They're built into technology that IT's picked and approved and has confidence in that they can use it to scale. While we don't really believe that our technology is good for empowering business experts, we do see it used to empower what we like to call shadow IT.
John: Agree. Shadow IT, that's a whole other conversation. Shadow IT exists. It's usually over looked and it's usually undervalued. I think our opportunity is to begin to recognize its real value and begin to incorporate it into our thinking and our planning.
Mike: Exactly. I see your next chart really talks about all the different roles that these platforms address. Can you shed some light on this?
John: Sure. I say the best platforms here address many roles. The platforms meaning the ones that are going to be most broadly applicable. They're going to a whole variety of scenarios. They're going to handle high scale. They're capable of running a whole portfolio of applications rather than just individual projects or a small number of projects. Those platforms you see will in fact provide tooling and facilities for the full variety of contributors through application delivery. I've listed the major ones here. You've got certainly business experts, in some fashion, are going to contribute. Hopefully they're very deeply integrated into the process. You've got project managers that are worried about delivering, schedules, and they're worried about priorities and some of them are worried about portfolios. You've got architects that typically will provide a sort of high level guidance to developers and development teams. Security pros have to get involved in laying out the security architecture and mitigating risks the security risks. Then lastly QA pros. I mentioned that there are some different approaches here to testing and QA but oftentimes you'll still want to have QA pros looking at these applications and evaluating their quality. Sometimes these applications involve external services that you're going to want to test. If integration's involved you're going to have those QA pros looking at those kinds of linkages. Then lastly there's a bridge in here to the operations professionals, the folks that run the production environments and the data centers. These products provide run time environments. They are providing production environments. The operations pros are going to be looking for tools to make sure the environments are alive to understand performance within them, to deal with issues, outages, performance slowdowns, security incidents, etc. They're going to be looking to balance loads and look at capacity, etc. There's a set of administration and operation tools that are really important for these environments as well. I'll just make one comment about this operations point. One of the real crucial benefits here that's available to folks if they choose to pursue it is these are managed environments. Whether you're doing mission critical applications or whether you're doing departmental applications, all of those applications are running in a managed environment. Think of this. If you've got now control over not only the real critical applications, but all that shadow IT that's running in an environment that you can manage and you have visibility into those applications, that's a huge step forward in terms of control and really just understanding what where our investment's going and what's working what isn't. It's a very important point. I chuckle. A number of people have said to me, "Oh this is a new version of the Access nightmare." No, it isn't. These are managed platforms. It's not some piece of software that's running on a discarded laptop under Joe's desk.
Mike: It's interesting, John. I don't know if this is the right slide or not but I have a really interesting question from a gentleman named Burt Livran. It's a little controversial but I'm going to ask it anyway. He asks, "When do you expect Microsoft/Google/... to run over these tools and become the new standard?" Do you see the technology vendors that he listed here getting on board and making their technologies and development tools as streamlined and as productive as what this new class is doing?
John: Well, certainly Microsoft. We can see the work that Microsoft's done is SharePoint. I put that work in this category. There are two tools regimes. One for developers, one for business users. They will continue down that track. The visual basic environment for Microsoft is really sort of in decline so we expect that they'll probably step up and try to create something else there. They've got some other problems right now though like getting Azure really into broad adoption and dealing with their mobile problems. They've got some bigger fish to fry, I think, that may delay a broad assault on this category. You certainly have to recognize some of the work that they've done. In terms of Google, IBM, Oracle, SAP, the big vendors, they seem to shy away from this. If you look at Google, there are Google apps but that's different. That's sort of a programmable app. That's really a different value here. If you look at Google App engine, it's very much aimed at developers, at Python developers and Java developers and it's pretty conventional. It's just API development so I really don't see them going there. They seem to rather see this as a partner opportunity. They open up the opportunity and try and work with other companies to fill this need. Same with IBM, Oracle, etc. I just don't see them going here.
Mike: Well, for a lot of infrastructure guys, my perspective has always been that the last thing they want to do is actually build something. They'd much rather you have something and install it on top of their infrastructure, so it sort of makes sense even though they all have development tools as well. John: Well they're not doing too bad selling infrastructure, Mike.
Mike: Exactly. All right. The next slide here shows there are great rewards and then there are also some risks that you need to be aware of. What advice do you have for the audience today, John?
John: First of all, recognize the potential rewards here. As I've said, everybody's got this problem of faster delivery. Everybody's struggling with this. That's what these products are really aimed at. That's what they're really good at. Let's recognize that right up front and then your due diligence on these products. Really push hard on how they're going to work for you and your organization to help you deliver faster. I've listed here initial development, fast deployment, fast change management, support for Agile, business and IT collaboration to speed your yourself thorough results. You've also got multiplatform so single code base multiple targets, cloud, on-premise, sometimes Java.net in some cases, native client, web client or mobile. You've got a lot of flexibility there. You can see reduced costs here just in terms of the amount of time and the amount of infrastructure integrations and so forth that you're going to have to do to deliver applications. Compare acquiring one of these platforms, which it's an integrated whole, to assembling a Java environment. That takes time and money and a lot of effort. Just the configuration alone can take weeks if not months to get that right. It's just shortcutting all that. Then lastly application management. Again, these are managed platforms. If you've got a large portfolio of applications, particularly if you're going to include some of your shadow IT, you can institute application portfolio management that's far more streamlined than is typical. You're not managing things in spreadsheets. You're actually in the platform. They're instrumented, you can see what's running, what's used, what isn't, etc. It's far more efficient. On the risk side, there is a risk of vendor lock-in. Thinking about that, there's always a risk of vendor lock-in in some way. Clearly these are platforms that, even though they align with standards, there's proprietary content in them. That's the genius. That's where the innovation comes form. You've got to be comfortable that you understand where you're locked in and be comfortable with that level of lock in. Understand where you're not locked in and be sure that's going to suit your needs. There's always lock-in somewhere.
Mike: Sure.
John: Some of these other risks are essentially it's a big basket of products, a big category of products and they're not all the same. The best products, I think, the broadest ones give you a lot of deployment choices but not everybody gives you that range of deployment choices. Be careful about that. Make sure you've got the broad range of deployment choices that you need if that's what you need. Islands, cul-de-sacs, orphans. Some of the products if they're if they don't address a full range of applications scenarios, only a piece, they only process for example well, that could be an island. That could be just an investment that you make that doesn't really take off. Just be careful about matching the function and the breadth of the product to the needs that you're going to apply it to. The worst thing that can happen, I think, is that you bring one of these products in with the intent of applying it very broadly in your business and you end up using it for one project. That's it. That's just, like I say, the worst that could happen. These are really strategic investments. I mentioned the earlier 4GL risks where you had to write a lot of code. In fact some of these products will, either because they're incomplete or because of the way they're built, have you write some code or they give you the opportunity to write code to supplement the environment. Be careful about that. If you really are trying to avoid writing code, then make sure that the product's going to be complete and that the tooling that the product provides is actually going to generate the complete application that you need. If you find yourself writing a lot of code when you didn't want to, that's another really bad outcome. Scalability and reliability. We always have to put these products through their paces. Some of them I consider to be proven. I've seen the cases. I've seen the proof points, but I haven't seen that for all of them. Really put them through their paces on that. Lifecycle management. We mentioned early on and we saw the range of IT participants that the most complete products address. Not all of them have addressed all of those practitioners, so be careful there that you're getting the full range of tooling that you need. Then lastly not all of them have really strong manageability features. The emphasis here is first and foremost on application creation and deployment. Then typically the vendor gets to manageability. The manageability features are highly variable in the category so be careful about that because obviously, as I mentioned earlier, that could be a huge benefit.
Mike: John, we have an interesting question and I'm going to apologize to the participant because I'm going to probably kill your last name, but it's from Andreas Amunden. He asks if we could explore the poor lifecycle management risks a little bit more. It's interesting he asked that question because it's one of the ones that is near and dear to my heart here at OutSystems because this is something that we have always tried to focus on with the Agile platform. Of course as our customer base has grown and as their individual customers' application portfolios have grown and gotten more and more complex, well, we've always had lifecycle management capabilities built in. We found about a year and a half or two years ago that some of these environments are getting so complex that they needed additional support. It lead to one of the key features in our last release called Lifetime, which is that holistic management consult. They'll look across the entire infrastructure, understand your portfolio and really simplify the movement and understand of the movement of the applications through your environment. That's one of the things that we've done to address lifecycle management in addition to the complete instrumentation of all the applications etc. so you can monitor them and understand how they're performing. John, that's what we've done. You've talked about some general purpose type tooling, which maybe is the category out of this broad group you'd put OutSystems in. How do you classify the tools in the productivity platform research in terms of this lifecycle support? Do you have any more comments to add?
John: Yeah, I would just add other things to look for, Mike, that I think are important. One is your ability to set up your lifecycle management environment to your liking. Not everybody gives you that flexibility. What are the stages that you work through? What are the different environments you work through to ultimately get to production? There's version management and impact analysis of introducing different versions that I think is important when you're dealing with mission critical apps and with large portfolios of applications and the ability to roll back to prior versions if need be is very important. Applications are typically, these days, made of collections of services or collections of components perhaps. Sometimes people want to be able to create common components or common services that are used across applications. Those need to be managed as services separately from the applications that incorporate them. Being able to manage those components, being able to see them, manage their lifecycles, understand the relationships and the dependencies within applications is really important to be able to realize a full-serve enterprise environment.
Mike: All right. Obviously it's all about, at the end of the day, speed and flexibility, as your next slide is set up to talk about. There are some enemies of that. What do you have to share with the audience here, John?
John: As I was doing this research, I was constantly thinking, "You've got a big category of products here. You've got a lot of vendors. What are the things you should look for as you begin to evaluate them?" As I characterized them, as I began to try to understand how they actually achieve the benefits that they promise they would and so forth. Then I began to sort of think, "What are the gotchas to look for when you start to do an evaluation?" Under this category of enemies of speed and flexibility, these were the things that I came up with, the factors that I came up with. You can see a lot of is how hard wired are we in the platforms? Are apps being hardwired to a fixed database schema? That just limits your ability to change the data schema as you need to. It slows you down because you've got to go to a DBA or typically or somebody who's an expert in database and you've got to change that schema and then you've got to rewire it to the app and it just takes time. We want to eliminate that. Large generated code bases that are customized within line code. Don't do that. You're going back 20 years to 4GLs and we know how that worked out. Hardwiring to specific platforms or specific frameworks or specific conditions. Metadata that addresses only portions of the application. You've got metadata which is great, that tends to be flexible, but there are other parts of the application where you had to write code. You've sort of made a partial gain there. That's really an argument about completeness. Manual lifecycle management of application changes. If the product doesn't really help you change the application, it just helps you build the initial application, then that slows you down. I think changes are just as important, maybe even more so, once an application is deployed than the initial deployment. Then last, all app changes require an IT project. If changing a rule requires that we stand up an IT project and have a project manager and so forth, that's ridiculous. We can't that kind of bureaucracy required if we're going to hope to move quickly and respond to the business. In the orange side of the table, I listed some of the things that I've sort of found in my research that I concluded were sort of antidotes to those or how to fight back against that enemy of speed. I'm always looking for other ones here too. I think there's still a lot more we can understand about these products and what to look for. This was my initial cut of it.
Mike: I have a question. John, this will probably be right down your alley because you're an enterprise architect and technologist at heart. I'm not quite sure exactly where this gentleman's going but it's from a man named Mike Lloyd. He says, "No mention of declarative code. Is it not important anymore?" Any opinion on declarative code?
John: No, I think it is important. That's a term that's applied to a multitude of sins. I think essentially declarative coding is about metadata. It's about expressing system concepts and system structures using high level, hopefully close to natural, language kind of statements. If it comes down to just coding, if it comes down to just another arcane coding language, another arcane programming language, which I've seen that term declarative applied to some things that I look at and say, "Geez, that's just a programming language," I don't know. You've got be careful there. We may not get a huge productivity boost out of that. I guess I'd say it's part of the picture but I'd want to be specific about the specific product and look at how it's really going to advance our productivity. Frankly, I don't have much question that the visual tooling I've seen is going to provide huge advances. Declarative languages, I'd have to see the specific language.
Mike: All right. Good enough. Obviously we would have to drill a lot a deeper to understand that detail. Fair enough. John, I know in the last few minutes here you've got a couple of slides of how to position this stuff and to get going so go ahead and share that with the audience.
John: This chart I used to talk about how to position, as you said,
Mike. Just any IT shop generally has Java or C Sharp or even older, certainly Cobalt in the mainframe world and so forth in the house. How should you position these new products within your overall strategy? Well, I position them as I've shown here as products that really enable speed. They're all about providing a higher level of development and abstraction to enable speed. To get that speed, you are trading off a certain amount of control. Now, because essentially the vendor has put together an integrated package, the vendor's doing a lot of management for you, they're generating things, generating artifacts and code for you and so forth so you don't have complete control over the environment, over what's being written or what's being generated. You're giving up that control to get speed. In the Java and C Sharp world, you give up speed for control. I think a lot of what we've been doing with Agile methods and frameworks and other techniques is to add speed to try to speed up the environment but retain our control over the platform and over the code that's actually written. In the world of new productivity platforms, I think there are opportunities to add control to the environment through something I call cooperative development, which is using custom development for things like integration or specialized algorithms or analysis routines. You sort of build those as services and you then access them from within that highly productive environment. You're balancing a little bit more the control verses productivity divide. The idea here is that you'll always have some 3GL environment like Java or C Sharp for those projects that really demand tight control. Most people don't have an environment that's really aimed primarily at speed of delivery and I think they need it.
Mike: It's interesting you chose some of these words because I know that when we start talking to people about what we do here at OutSystems, the speed is usually considered as something that comes at a loss of control and even the loss of quality. I hope as you guys continue to do research around these productivity platforms you can help shed light on the fact that a lot of these tools today do give you enough control, enough quality in the delivered solution that they can truly be used to address a lot of the IT challenges that are faced today.
John: Sure. Understanding what I think a lot of shops sort of default to. We need total control therefore we'll always do everything in Java or do everything in C Sharp. I think to your point, Mike, we've got to deliver faster so we've got to be a little more clever about where we really need that level of control and where do we not. Where can we actually kind of let that go? Basically, these highly productive environments give us enough control and let's recognize that. I think there's some thinking that we all have to do as a community, sort of revisit our existing assumptions, frankly.
Mike: What's advice to get started? Here you go.
John: The last chart here that I have is really a piece of advice I guess masquerading as a point. I think we have to recognize these platforms as strategic investments. I think the greatest benefit that you'll get from investing in one of these products is you're going to invest in it, right? You're going to buy software and invest in training. You're going to invest in mastery of that platform. You're going to change your procedures, blah, blah, blah. It's a strategic investment. Approach it as such. There are far too many people that I see that basically bring in one of these products and use it for a very limited purpose and they never get beyond app 1 or app 2. I think it's because they don't really properly position it as a strategic investment. As a result, they're just not going to get the full benefits they might ordinarily get. Strategic use means that you're using one of these platforms for a whole variety of applications. You're managing a portfolio on the environment. You're going through cycles of releases over the course of 10 or 20 years. It's not just a departmental thing or it's not just a product we bring in for this one little project that we didn't know what else to do with it. It's really got to be a strategic investment to get the most benefit. The last is warning, product pitch ahead. Well I'm not going to do a product so I guess that's you.
Mike: Yeah. It is actually. I don't want to put you on the hook but we have one last question that I couldn't help throw out here. It's from Sean Keller who basically says, "John, can you provide a list of the top three software product vendors in the new productivity space?" I know that's not a fair question because, as you've already said the tools are, there's a mixed bag of tools. They all sort of serve some different purposes. I thought it would be a great lead-in question for me to share these two slides that I wanted to leave the audience with before you wrap up, John. Let's see if I can control here. Yeah. First, all this research is actually in a paper that John and some other folks at Forrester wrote. We'll be sending that to all the participants as a follow-up so you'll have a hard copy of this paper from John. Of course, at OutSystems, we do provide of one of the tools that are covered in this document. I think it's the one that gives you the most capabilities you could want. John sort of talked about different classes in general purpose for building complex mission critical apps. That's really what we're all about, but our product does scale all the way out to the department. I encourage you to, if you're interested, please go download it, play with it, and study the tutorials. They're all online. They're all free. Learn as much as you can. That's my product pitch. What I'm going to do now is turn it back to John. I know he's got just three last bullets with some key advice. John, back to you.
John: Thanks Mike. My advice is to engage. Look, I just don't believe anymore that we can satisfy the needs of the business, that we can deliver enough software fast enough if we stick to conventional coding. I just don't believe it anymore. There's too much evidence that that approach is going to fail. I think everyone ought to be looking at bringing in one of these environments, ought to be seriously studying bringing in one of these environments to supplement what they've got in their Java or .net or Cobalt or whatever it happens to be. There are a million variations here but I think everybody ought to be serious at looking at this. As you do your due diligence, you've got to think strategic use. If you bring one of these things in and use it for a limited purpose, there's just going to be a lot of disappointment, I think, in the benefits. You may achieve some wins initially but you've got to keep going over a course of years. Plot your strategy, build it around strategic use. Then, lastly, your business experts have got to be part of this world in every way, whether it's in your conventional development using 3GLs or using in this world of new productivity platforms. I find that most clients are just not set up effectively at all to incorporate their business people into the creation of software. It's a hard problem to solve but it really is an organizational problem. We get there one way or the other. We either have shadow IT or we have consultants slinging code or God knows what. Let's take the bull by the horns and really figure out how to incorporate these very important folks into our delivery cycles. That's what I've got.
Mike: All right. Well, John, thank you very much for sharing the research. To our audience, thank you for participating. Have a great day. Thank you very much everyone.