Mike: Welcome to our webinar, The Whys and Hows of PaaS for Enterprise IT. My name is Mike Jones. I'm the vice president of marketing for OutSystems, and joining me today is Michel Ozzello.
Say hello, Michel.
Michel: Hi, everyone.
Mike: Michel is one if our senior product managers here at OutSystems. Today, our webinar wants to focus on a central premise, and that premise is that without your applications, the cloud has no value. Now, we've been talking about this for some time, and quite frankly, when we talk to our existing customers and our prospective customers, it becomes very obvious that, while there's lots of hype around the cloud, the challenge of moving your legacy applications to this new infrastructure, this new environment - quite frankly, a new way of working, right, Michel? - is a challenge.
What we want to talk about today is how you get your core applications into a cloud infrastructure, so the focus of this presentation is really on enterprise IT. Now, historically, we have folks who come from consulting organizations that provide services to enterprise IT organizations, or maybe you're an integrated software vendor in ISE who's actually building SaaS applications, if you will, to be sold into the marketplace.
I think if you're one of those organizations that are not an enterprise IT shop, you'll find value in what we're going to talk about today. I think the perspectives will resonate with you, but really, our focus is on an enterprise IT organization and how they're going to go about embracing the cloud, specifically platform as a service.
With that said, let's focus a little bit on the cloud in terms of value. What I want to talk about, really, is what all the industry analysts are saying today, and I've tuned this a little bit to what a lot of the customers I talk to who are practicing and implementing cloud technologies are actually seeing when they head down the road to things in the sky, if you will.
With that said, I thought I'd start with IT operations. If you think of cloud value, there's a lot of value for IT ops. It's pretty straightforward. For the operations team, it simplifies a lot of what have really become commodity functions - spinning up servers, spinning up storage, the whole utility-on-demand type of approach that the cloud promises. Obviously, the value, here, is that it can help reduce a lot of the variable costs within the operational side of the information technology equation.
The type of cloud that obviously resonates here is what's called infrastructure as a service. A while back, I was with some analysts from Gartner and we were having this conversation, and one of the analysts said, "You know, IaaS, infrastructure as a service, is really purchased by the operations teams so they don't have to deal with procurement." I thought that was an interesting perspective, and it seems to resonate with all of our customers who are in the operational side of the house. IaaS gives them the ability to spin up servers and service the business without having to deal with the nightmarish paperwork involved with trying to procure a new server or a new piece of hardware, whatever it happens to be. So it's an interesting perspective.
Now, if you shift gears and think about cloud value for the business, it's actually different. The business really looks to this thing that they consider the cloud as a mechanism to help them get stuff done really fast. The speed of delivery is effectively the value for the business. Some interesting research that we stumbled upon a while back was that a lot of cloud acquisitions in corporations today are being driven by the business.
And what's quite interesting and a little bit scary, I believe, is that 20% of the business people reported that they make cloud purchases without IT's knowledge. If you're an IT guy, that should put some shivers down your spine because we all understand that when the business starts going around IT and doing things on their own, it ultimately comes back to haunt us. It leads to problems, whether they're transition problems, integration problems, you name it, it's going to lead to some sort of hiccup and headache down the road.
When we think about this, really what the business is doing is they're buying software as a service. They're not spinning up infrastructures, typically; they're buying SaaS packages, SaaS applications. Going back to my Gartner friends, they have a tidbit for this, as well. They said, "SaaS is really purchased by the business - guess why - so they don't have to deal with IT."
That could be looked at as a negative, if you choose, and quite frankly, I think this resonates quite well with all the people I talk to who purchase SaaS, like, "Look, I get it fast, I don't have to deal with IT, I can get this application running and it will help me solve my problems." Now, whether it's a perfect fit or not we can all debate, but that's why the business is purchasing SaaS, and that's where they see the value in software as a service.
The third organization I want to talk about is application development. We have to build a lot of these applications because there is not a package for every unique thing a business needs to do, so the cloud does promise some value there, as well. The value is around delivering those core applications - I like to use the word "core," and we'll explain this in a minute, right Michel?
Mike: But really, the value is that we can build applications at a fraction of what it takes to use traditional tools in terms of time and cost, so it's really going to simplify things and reduce the investment we have to make as an IT organization to get applications built.
A recent article published by Forrester talked about platform as a service and tools that . . . when you're using platform as a service tools, you really want to find solutions that address what they call the "ilities," - deliverability, maintainability, scalability, usability, availability, reliability - all of those things that, as an enterprise IT shop, you worry about when it comes time to deploy an application.
So a good PaaS solution is going to help you there, and when I was with my friends from Gartner, guess what? When we said, "PaaS is purchased by . . ." there really wasn't an answer. No one has come up with who is really going to buy PaaS and what value it's ultimately going to deliver.
I suggested some value, but the reality is that PaaS, or platform as a service, is really a market that's maturing rapidly right now. We've had a lot of interest in the cloud, especially infrastructure as a service. We're spinning up environments and we can do things much faster, but the reality is, remembering our premise, as an enterprise IT shop, I have a lot of legacy stuff that I've got to get to the cloud, and I have to integrate
whatever I'm putting in the cloud with probably a lot of stuff that's still running in my data center. How am I going to solve all these problems?
So there's a lot of maturing that's going to happen in next 18 months - it's happening already - and I think that eventually, we will go back to this statement and find that PaaS is purchased by enterprise application development teams who really want the ability to respond at the speed of business. They want to be able to react to business change and demand for building core applications very, very quickly to meet the business need.
So what does that really mean? Well, if PaaS can help us get core applications to the cloud, maybe we should just take a few minutes and think about what a core application is. A core application is really a term that we've borrowed from Jeffrey Moore, and he documented this quite nicely in a book called Dealing with Darwin. If you haven't read the book, you really should, but I'm going to give you a snippet right now.
What Moore said was that if you look at applications and businesses, you can segment them into two different paths. One path contains those applications that he called core, and I like to use the word differentiate. They truly add value. They're unique to the business. And then, there are a whole bunch of commodity - Moore's word was "context" - applications that the business needs to acquire.
Then what Moore said was, "You know, when I think about the way applications evolve, we need to further categorize applications into non mission-critical and mission-critical," and effectively, he formed four quadrants. He named them the "invent quadrant," for non mission-critical differentiating stuff; the "deploy to scale quadrant," for mission-critical differentiating stuff; the "manage to scale quadrant," for those commodity applications that are mission-critical; and last, but not least, the "offload quadrant."
What's really interesting about this model is that you can use it to explain how applications evolve from a lifecycle perspective. Let's look at that, because this becomes really important as we think about where the different flavors of cloud play in an enterprise IT shop and the types of tools that we've used to deliver applications historically.
Bear with me a second and let me tell the story. Out on the edge of the business, someone has a great idea - the, "What if we did this? Maybe we could capture a new piece of the market or service a new need." Lots of times, those cool ideas are managed with emails and spread sheets. Maybe they mature a little bit, and we deploy a SharePoint server to help keep track of all this stuff, or, God forbid, we end up with an access database.
But eventually, if this non mission-critical, highly inventive type of process the supporting bits and tidbits of software actually need to scale, i.e., they become more mission-critical, what we see is that the applications evolve up into the "deploy to scale" quadrant where IT typically takes them over and usually has to rewrite everything - put it into the right format, use a real database, all the stuff that IT does.
That's how applications sort of initially evolve. Then, we find something very, very interesting that happens: for some of these innovative ideas, we see entrepreneurs, usually within that first company that came up with the cool idea, spin themselves out, create a niche software company and start selling software to help the competitors of the original company follow the same process.
If that starts to grow, if it becomes fairly commonplace, then those neat solutions ultimately move over to the right and become commoditized. Because everyone in that particular industry does that process now, it becomes the de facto standard way of doing business, and when that happens, we usually see the large ERP vendors - the SAPs and the Oracles of the world, if you will - gobble up those niche solutions because
they can add them to their portfolios and have something else to sell.
To finish off the model, in some cases, those processes and the supporting software become so commoditized that a business doesn't even need to run the application; they completely offload that business process. The classic example, or the one that always comes to my mind, at least, is payroll processing. How many of us actually manage our own cutting of checks and depositing then into our employees bank accounts? We give that to a third party who does it in a completely offloaded mode.
So that's an interesting perspective on how applications move from the invent quadrant up to deploy to scale, and then become standard practice within an industry so they become commoditized. You can buy those packages at that point, they get gobbled up by ERP suites and in some cases, get completely outsourced and offloaded if they become a true commodity.
It's now interesting to think about that model in the way that we traditionally built applications, and then we can compare that to the way we're going to build applications in the cloud. Let's think about this: A business comes up with a cool new idea. They use casual development tools - they use Excel, they use Access, maybe SharePoint, but that's what we typically see out on the edge of the business in a department. And then, of course, as it becomes more mission-critical, that application is usually redone by IT, typically at a low-level language - DocNet, Java, something like that. Then, of course, when they become commoditized, they become packaged software. We go buy them "off the shelf."
Now, along comes the cloud and it changes this just a little bit. Probably the biggest change in some regards, really, Michel, is the terminology, right?
Michel: Yeah. It's all in the names, basically.
Mike: So if you think about it, we have this name, "software as a service." Well, guess what? These were commodity applications. They fit on the right side of Moore's model, and they replace what we used to call a package. We no longer buy a package and install it on premise; we effectively license it in the cloud and we run it there. It's multi-tenant software as a service application.
Now, a good lesson, here: think about where software as a service fits. It's on the commodity side, right? All your competitors do those business processes and buy the sale applications, effectively, so they do stuff the same way. I like to call these the Zero Value Cloud Lessons," and here's the first lesson that I want to share today: SaaS reduces cost but doesn't add any business value. So let's think about that for one second. It doesn't add any business value.
What I'm getting at here is that software as a service, a package, will help you be more efficient, you can buy some best practices because everyone else in an industry does it that way, but it's not going to allow you do be innovative. By definition, a commodity application, a SaaS package, is not innovative; it's got the industry best practices, the way everyone else does that business process. So that's why I say it doesn't add value.
SaaS also comes with a very traditional problem, something, and I'm an old guy, that I was talking about back in the late '80s and '90s. It was called "buy versus bill." Let's look at this. We said that the business is typically going around IT and buying a lot of this software as a service stuff, but guess what happens? In many cases, the business has a problem that's sort of differentiating. They need a new piece of software, and guess what they do? They go around IT and they buy a package, and what they're really trying to do is take that software as a service and extend it to meet the needs that they have that are very unique, and we all know that that's a problem.
This leads to my Zero Value Cloud Lesson 2. So if you want to avoid this, if you're an IT guy, these slides will help you explain to the business why you have to be very careful in picking a SaaS package because you can't fit a square peg into a round hole. That SaaS package is not really going to solve their innovative, unique, differentiating business need. It's just too hard to do.
So, to make it really simple, what this means is that, for those core applications, you can't pull the SaaS over. You're going to have to build those apps.
The best advice, of course, is if the package has 90% of what you need, make sure it has really good APIs and just build the 10%, but do it in such a way that you won't inhibit the package from taking upgrades, etc. You'll minimize your exposure, but you're going to have to build those core apps.
How do you do that? Well, that's where platform as a service comes in. This is that, "Oh no - the immature stuff," right? So let's shift gears here and talk a little bit about PaaS, about what's happening and how it's maturing in the marketplace.
The first thing I want to say is that platform as a service, in my opinion - and this truly is my opinion, Michel - is being positioned as something for ISVs, and you may scratch you head and go, "Mike, why is that?" The reality is that ISVs are thinking about using platform as a service to build SaaS applications to sell to customers. Well, that's very true and that's where PaaS can play, but for enterprise IT, what you're going to find is that a PaaS solution is going to have to serve a very different set of needs, because while ISVs and enterprise ITs are both trying to build apps, they're really very different. You don't have the same requirements.
Let's look at that for just a second. Let's think about what's not the same. I think that's the more interesting way to look at this. If you think about an enterprise IT shop versus an integrated software vendor, the first thing you see is application change. Wow. In enterprise IT, it's meteoric, right? You're helping your business come up with new business processes and applications to support those processes. They're in invent mode. What they told you yesterday was totally wrong because they woke up in the middle of the night with an epiphany and realized it would be much better to do it a different way, so throw away all that code you wrote and start over. Yeehaw!
Michel: We can relate to that, Mike.
Mike: Absolutely. On the ISV side, they're addressing the commodity stuff, right? You've already been through all the invention. It's all worked out, so it's very stable. That's a key difference, and it impacts the way the tools you use need to behave.
Requirements management, the process of building the software, is very, very different. On the enterprise IT side, the process and requirements are really driven by a combination of some IT guys, or maybe they've even been outsourced to a third-party consulting firm, and the business folks. And we all know that we always get the requirements wrong. It's not because we aren't good at requirements; it's because we don't know what we really need because we're in invent mode.
The ISV side, on the other hand, has product managers. They take requirements and they measure them across all of their customers and decide which ones are the best ones to deliver in the next six months. They have a roadmap and a long-term investment plan, and once again, it's somewhat stable.
What about resource availability? This is an interesting one because on the enterprise IT side, you have what we like to call, "flowing teams." What this means is that in many cases, the business needs an app, you don't have enough internal resources, so what do you do? You outsource it. You bring some guys in house, maybe you manage the project with one of your experts, but at the end of the day, the people that build the software aren't the same people that maintain it. You constantly have shifting resources across you application portfolio.
That's totally different in the ISV world. In the ISV world, their development teams are stable. This is a long-term investment. This is our business, right? So those guys, sometimes I want to say they're professional developers. We're all professional developers, but the reality is that they stick together and they're continually evolving one application or a suite of applications.
Michel: They are an engineering department, or an R&D sort of department.
Michel: Exactly. Very rarely do we hear our enterprise IT shops call themselves R&D teams because they're not. They do app. dev., so it's very different.
The budgeting process is very different. In enterprise IT, out budgets are typically project-based; they're fixed. We go deal with procurement, we get some dollars, we scope and estimate, we get it wrong, we get some dollars . . . it's always problematic. Whereas on the ISV side, it's not that way; it's a multi-year R&D investment. That changes a big dynamic in the way that projects work.
Last but not least, for an enterprise IT shop, you've got one end customer, and this is the one where it's a little more complex on the ISV side. The ISV has many customers, so they're worried about multi-tenancy and parameterization and a bunch of complexity that we don't have to worry about in enterprise IT.
But all of this ties back to this last point, and the final point is application architecture. From an enterprise IT shop, the applications that you tend to build, especially on the core side of the model, are composite. They need to talk to the systems of record, which in many cases, are the those commodity packages that you've purchased, or SaaS applications. But by composite, that means they have to integrate with a lot of stuff. Conversely, if you're an ISV, you're trying to build the next system of record. You aren't really worrying about integrating with a lot of things; you're trying to build enough of the functionality that it becomes the system of record, so it changes there, as well.
All of these differences really impact the nature of the platform as a service technology that you want to consider to meet your needs because you have different lifecycles, different tools, ultimately different challenges with different resources.
So let's think about this. This leads to my last Zero Value Cloud lesson, and that is: Don't fall for a one-size-fits-all PaaS. If you're an enterprise IT shop, what I find is that PaaS will play an important role for you to build those core applications. You can find a solution to meet your needs, but, be very, very careful. A lot of the industry hype today is around PaaS that's really defined for supporting ISVs, and it will bring complexity and introduce features that you really don't necessarily need and won't serve you in an enterprise IT capacity.
This sort of leads me to the final section of our webinar today, and this is where I want to provide a little bit of advice on how to go about selecting an enterprise PaaS solution. There are some suggestions here. We're going to actually show some things that we've done from a company perspective at OutSystems with our PaaS offering, so a bit of a warning, there's a bit of a product edge, and actually, at the end, Michel is going to wrap up and do a very quick demo so you can actually experience a PaaS for the enterprise in building an application.
So that's what we're going to talk about. I think there are four things that you should consider. The first one is to deploy a RAD PaaS solution for those invent opportunities. That's the lower-left quadrant. Let's think about what that means. We're talking here, and we call this "RAD PaaS." "RAD" means Rapid Application Development, a term from, what, the '90s, right?
Mike: But today, RAD PaaS is a term we're using that's starting to get a lot of traction in the marketplace. We're starting to hear analysts talk about high-performance cloud-based development solutions, etc. There's a lot of fragmentation and maturation that's going on, but we're using the term RAD PaaS.
The first thing to consider for a RAD PaaS is that it has to really provide a lot of flexibility for the department-level developer. It has to be distributive so you can get it out into their hands, which is the nature of the cloud. It obviously has to be multi-tenant because you have to let different development teams work simultaneously on this environment. And, more importantly, I think, is that there has to be centralized operation and
control. This allows IT to keep track of what's going on, but distribute the work out to the inventors out on the fringe of the business.
Now, to really power these guys, the slide indicates that this is probably a private PaaS type of environment. By private, we mean that it's running inside your data center, because these apps have to integrate with a lot of legacy stuff and that really needs to happen inside the data center. So something to keep in mind is that RAD PaaS, in many cases, is private, or installed within your own data center.
The RAD PaaS solution has to have the notion of elastic sandboxes. This is something that we've historically done with the Agile platform since we invented the technology back in 2001. This is the ability to spin up, as a utility service, a new development environment very easily.
The product has to help the development team out on the fringe of the business build stuff very, very fast, and this is something that we invested in proving with our technology about a year and a half ago. We used function-point analysis. We didn't just go off and analyze one favorite customer; we actually looked into over 240 different projects spread across a whole mix of customers across our customer base, and we proved without a doubt that on average, we were 10.9 times faster than using traditional development approaches.
If you want to learn more about this, go to OutSystems.com and just search our website for function points. You'll find the analysis report, all the findings, the third party that validated that what we did was accurate, etc. But we can really help you build apps fast.
We believe that to make this work, you need what's called a DSL, a domain-specific language. You have to simplify the development environment for the business people to give them the speed that we just talked about and that gives them the ability to build applications that can change, meeting that need for the invent quadrant.
It has to be complete, so it has to cover things like data. It has to be able to integrate with existing data stores. They have to be able to build some new ones. It has to be a fully integrated development environment.
The second thing is that your enterprise PaaS solution has to make integration part of a core capability, and this is important. Just think of that invent quadrant, and even as you move up into deploy to scale, whatever solution you use has to interface, and easily interface, with legacy packages, SaaS applications, etc., so it has to be a core capability in your RAD PaaS solution.
The third thing we recommend is that your RAD PaaS solution has to embrace the notion of universal applications, and this is critical for reducing the cost of maintenance. So let's take a second and think about a universal app. When I say universal app, what I'm getting at is a platform that will let you build applications that not only run in the web browser, like all cloud apps do, but also will run in a tablet environment, and in a smart phone form factor. You need a platform that supports all three of these, and gives you the ability to easily reuse objects across these different skins and form factors. We call that a universal app. So the PaaS solution has to support the delivery for mobile, tablet and the web, and it has to it in such a way that it makes it very easy to deliver highly usable, elegant interfaces because that's become the standard for business applications. The day of the clunky UI is rapidly going away.
Michel: Thank God.
Michel: Exactly. The fourth piece of advice - and I think this is the one where most people go, "Hmm. Mike, are we really going to find this?" - is to find one platform that will support both your invent and your deploy to scale needs. What I'm really saying is find a PaaS solution that will go and cover all of these. Don't piecemeal this. You don't want to have to rewrite what happens in the invent quadrant when it becomes mission- critical. You really want a solution, which I like to call an enterprise RAD PaaS, that meets the needs of both the non mission-critical invent quadrant and the mission-critical deploy to scale.
So let's think about that. Really, an enterprise RAD PaaS has to simplify the "ilities." It has to have an end-to-end support for the whole lifecycle. It has to be able to support staging, not just across development, but QAT, preproduction, production, all the stuff that we have to worry about when an application becomes mission-critical. It has to have sophisticated security, built-in management, built-in application instrumentation - remember, this stuff is running in a cloud or a private cloud implementation. It has to be instrumented.
It has to be behind a console because having all of these capabilities gives us the performance gains that we need if we're going to be successful in the cloud world. So the Agile platform has something called Service Center that allows you to manage all the versions of your application and effectively set up a factory environment.
It has complete deploy in staging, so we have the notion of one quick publish. It moves the models, it does all the continuous integration, and it allows you to do this across an elastic environment, so you can do this in the development environment, in the QAT environment and all the way to production with a single click. Very, very powerful.
It has to have sophisticated security. This slide here is showing that is has to have built-in application security, which is a must, but is has to go beyond that, right, Michel?
Michel: It has to support security all the way down to the component level, across your development team, etc., because we're talking about building applications that have to become mission-critical. So it has to have sophisticated security, it has to have the ability to manage the platform environment itself, you need to understand how your servers are performing and how your processes are performing, you have to have built-in capabilities for batch programs that we call timers. All of that has to be
built into your enterprise RAD PaaS solution.
Last but not least is application instrumentation. You have to be able to automatically instrument the app, understand how the app is performing, how the consumed components that make up that application are performing, etc. If you have to do this manually, it breaks down. It has to be built in.
Michel: And you'll never do it when you're in the invent quadrant. You never have time to build in monitoring functionality.
Mike: Exactly. It has to be part of the solution. So let's see an enterprise RAD PaaS in action. I'm going to turn the controls over to Michel and get him to demonstrate the Agile platform. Michel?
Michel: Okay. Thank you, Mike. What I'm going to show you is really quickly how to build a web app in the cloud. I'm going to use several accelerators in the Agile platform, and one of them will be the import of an existing Excel spreadsheet with some data, so this will be a way to speed up the definition of my database.
Mike: Michel, can we change one of the rows in here just to prove that you're not smoke and mirrors?
Michel: Yes, of course. So, let's put Mike Jones here, for example - let me change the email: MikeJones@outsystems.com.
Mike: Now I'm in engineering. Cool. I like it.
Michel: Yeah, you're in engineering. Okay, so, save this. So I'm going to move over to the Agile platform's IDE, which is Service Studio, and I'm going to follow pretty much the process that you would follow if you were to go to our website and try it out. After you download it and install it, you're invited to set up a cloud server for your trial.
Mike: So you're actually telling Service Studio, the IDE portion, that you want a platform server in the sky, so you're really doing this on the fly.
Michel: Exactly. Right now, I'm getting an Amazon server, or sorry, a platform server . . .
Mike: It happens to be in Amazon, right?
Michel: It happens to be. It's being set up, and now I'm getting connected to it so that I'll have someplace to deploy this application when I'm done.
Mike: So this is the notion of an elastic development environment. You just spun up a whole new instance in the cloud for you to build your custom app.
Michel: Exactly. I have the IDE on my machine, and I'm going to deploy it somewhere, which, I don't even need to know where it is.
Mike: Somewhere in the ether.
Michel: Exactly. Let me take you quickly through Service Studio and show you how to build the application. The first thing I want to talk about is the concept of the fully integrated environment that Mike was mentioning. If you look here, we can define all the business processes of your applications. We can define and design all the user interfaces, so all the user interaction - how the user navigates through screens, what the screens look like . . .
Mike: And I can do both mobile and web?
Michel: You can do both mobile and web here. All the business logic, so everything that's running behind the screens to make the application behave as you want. Also, you will see here that you can define security roles for you application right on the tool so you don't need to go anywhere else. It's all integrated. And finally, the data model, so everything that your application will use as its data model, and every data model that you want to hook up to get your legacy data, as Mike was saying.
The first thing I'm going to do is, really quickly, take the Excel file I was showing you guys and just drag it over here to speed up the definition of the data model that I'm going to do for this application. So I'm going to drop it over, and you'll see that the system was intelligent to go and look at the Excel file, figure out all the columns that we have. It even did data-type matching, so it identified that "Birthday" is a date, for example, and that "Email" is an actual email address data type. It also stored here the original Excel with all the data so that it can bootstrap it as seed data when I start my application. So my app, when it runs, it will not be empty; it will have the data in the Excel.
I'm going to do an additional thing, which is I'm going to drag a picture over this table and say that, "Okay, I want all my employees to have a picture," and you see that it automatically created an additional table which is linked to the employee table. This is a best practice in entity-relationship diagrams for databases, so this will store all the picture information and actually insure that the application performs well.
So at this point, I have my base definition of the database that I'm going to use, and I'm going to start creating the user interfaces. Over here, you can see the starting point - let's say I have a blank page - and what I'm going to do is I want to create a screen to list all my employees. So I only need to take that data table and drop it over the screen, and you will see some things will happen around here, namely, that if we double-click and go check it out, you will see that I got a full page, complete with header, navigation, and all the pieces, the UI, that I need to list records from this table.
Mike: So this includes all the business logic, everything, the queries?
Michel: Everything was created automatically, and I'm going to show you in a bit. I'm just changing the layout a bit. This is fully customizable, all of the labels, all of the elements, but the cool thing is that this accelerator created all the filtering, all the paging, all the table sorting, so everything is here.
Mike: A truly rapid application development.
Michel: Exactly, so I'm not wasting time doing this kind of documentation. And if we go to the screen, you will see that we have three pieces of logic. The first one is a simple query to get the employees feed it to the screen. We have this action to export employees to Excel, or the refreshment when you hit some filters. You will notice that all these have exception handling, so it's all, let's say, robust. It doesn't break.
All right. The second thing is, not I have a list of employees, and I want to say that if I click in the name of the employee, I want to go to a screen that will show me all the details. So I'm going to just link to a show screen, and if we go back to the user interface, you will see that now, we have two screens: the list linked to the employee show, and this shows actually the user navigation as well through the screens. Let's go and check this one out. Here it is. It automatically puts all the data there. This is a typical record trove screen. You operate up the label.
And I'm going to do one more thing, which is go back to the user flow, and say, okay, now I have an additional screen, here, and I want to add it to the employee data over there. So what I do is, again, I drag the entity over here, and automatically, it figured out that I already had a screen to list employees and one to show, so this third one would be an added. If we go there, we see that we have all the fields prepared for editing. You will notice that we have a little calendar here next to the dates, so it automatically assessed that this was a date field, so it will pop up a calendar and you'll see it in a minute.
Very simple application - two tables, three screens - and now, let's say I'm ready to publish this app in the server. I click the one-click publishing button, and this was one of the functionalities that Mike was talking about, is once you build your app using these rack tools, you need to quickly deploy it into your cloud server without having to go through some extensive scripting or running batch files or having to change the database manually. You need to do it fast, without any concerns.
Mike: So this is going to deploy the three screens you built. It's going to lay out, what, a new, what kind of database?
Michel: This environment that I'm working in, in Amazon, it basically is running on DocNet framework with a SQL server database, so the first step on the one-click publish you see here is the creation of all the DocNet code required to implement this solution. So the first step is to generate that CSharp code and to create all the SQL server scripts required to create the database. The second step is actually to take those scripts, run them against the server to effectively create the database tables, and then deploy the compiled code, which is standard ASP DocNet code and deploy it into the web application, which in this case is IIS.
Mike: And Michel, I noticed that the green button at the top that you had the "one" in is now blue with an arrow. What does that mean?
Michel: Exactly. It means that the one-click publish process is done, and I can just click it and open the web application I just built in the server. One thing is you will notice in the first load that it takes a while to show the screen. This is because we're taking all that data that was in the Excel and we are feeding it into the database to get some information already in. All the feed data that you saw in Excel will be here.
Mike: Hey, I didn't see you build the login screen.
Michel: I didn't build it, but part of the template that we used is Service Studio, as you saw, it already had the header, all the sidebars, all the navigation, and it also has an embedded security screen to ensure that you have to log in to see the application. Remember, we're working in the cloud, so this URL will actually stop being available in 15 days because this is a trial server, but if you go there now, you can actually access
it. And here it is. I'm going to check your details and actually add a few. I don't have your photo, though, so I'm going to use my photo. I'm just going to choose a file, here . . .
Mike: Oh, I'm getting younger, guys. Only a few years, but . . .
Michel: We have the picture, and here it is. The next thing I'm going to do is go back to the application and I'm going to do a change that is very typical when we're doing these kinds of applications in enterprise IT, and especially in the invent quadrant. Say someone comes up with the requirement, for this example, saying, "Birth date cannot be shown in the application because it's considered personal and we shouldn't have it there."
Mike: So you're going to delete birthday.
Michel: I'm just going to delete the birthday field from the employee table.
Mike: Whoa. Our blue button went red.
Michel: Exactly. By doing that, I'm actually changing the database table, so I have a bunch of dependencies in the application that are broken right now. Service Studio shows me exactly where things are broken and what I need to fix.
Mike: So you just click on the list of errors, and it's navigating you to the place.
Michel: Exactly, and it's all visual so I don't have to read code and figure out what I need to change; it's really just navigating there. It tells me that there's something missing here. I don't have a birthday anymore, so I'm just going to drop that column, and very, very quickly, I am getting rid of all the dependencies of the birthday in the interface. The other cool thing is that all of the queries that I have to get employee data or to store employee data . . .
Mike: You're green again.
Michel: Yeah, I'm green again, so I'm going to click the one-click publishing button again to deploy this new version to the same server. But as I was saying, all the changes to the queries that retrieve data or store data are automatically done, so I didn't have to rewrite any query to, for example, populate the . . .
Mike: Ah, so it sort of self-healed.
Michel: Exactly. So there was a self-healing process and then there was a manual process to make sure that, "Hey, there's a problem in the interface. What do you want to do: get rid of it: Solve it?" In my scenario, I just got rid of the field from the interface.
So now, I am actually storing the new version in the server. I'm regenerating all the code, making all the changes to the database and I'm deploying the new version. So if I go back to the app and I hit refresh, you will see that now, the interface doesn't have the birthday anymore. So this is pretty fast to get new versions out without having to go through those extended processes and complicated . . .
Mike: So, Michel, typically, when I see something like this, what actually happened was that someone in the business said, "Hey, you can't show date of birth on these screens. You need to delete it," and IT said, "Well, okay," and deleted it. Then HR comes back and says, "You deleted date of birth out of this application, but I need to be able to see it. I know everyone else can't. So you screwed up."
Michel: Exactly, and this is the next step that I'm going to show you. Assuming that we messed up this version, I just click on the service center button to go to the management console that you were talking about before. So this is where IT has control over all the applications that are being built by all the departments or business units. In this case, I went directly to the application that I was building, and you can see that I have two versions, here: the first version that I originally built with the date of birth, and the second version where I deleted the birth date field. So what I'm going to do, here - you will see that the second version is the one that's running - so what I'm going to do is, basically, I'm going to roll back to the previous version. I'm going to version one, and I say, "Hey, I want to republish this version," because I want to go back to where I was before I messed it up. So I just click the "OK" button, and what this will do is take the model of the first version of the application, regenerate all the code and will get that code redeployed in the server, and when we go back to the web app, you will also see something very interesting with the data.
Mike: I was going to say, "How are you going to get all the data back?"
Michel: The data is still there. What happened was that during the deployment when I deleted the field, the original data was kept in the database just in case you need it after. You never lose anything that you do; you just change the application, you stop using that field, it doesn't appear anywhere, but the original data that was stored there still exists.
So the redeployment has been done and I'm going to switch back to the application. I'm just going to refresh the screen again, and you can see now that the birth date is back on.
This is the demo that I had for today. Obviously, there are more things that we could do. For example, we could say that the birth date in the interface is only available to users that have a profile of HR administration.
Mike: So that's where those roles would come into play.
Michel: Exactly. Come here, define the role of HR manager and make sure that in the interfaces, when we are, for example, in the employee list, the birth date or the email or the phone or whatever only shows to a specific role and fully changes the application.
Mike: So, Michel, very cool. Guys, there was an example of an enterprise RAD PaaS right in front of your eyes with all of the features we discussed. If you'd like to learn more, go to OutSystems.com. You can download the Agile platform and play with it there. If you have specific questions, feel free to send them to either me or Michel.
Thank you very much, and have a great day.