Justin James recently got to spend some time talking with the team at OutSystems to learn about their Agile Platform. He says this tool goes beyond everything he has seen to change how you approach development.
Are you prepared to throw out every process and piece of software that you use to develop software? Not just what is done at the programmer's desk, but for the QA team, the BAs, the architects... everyone? If not, OutSystems' Agile Platform is not for you. It goes beyond "the kitchen sink" to be "the whole doggone house" in terms of handling the development process.
OutSystems was started because the founders were doing consulting work, and they kept hitting the same barriers that most IT projects hit, which include the following:
- You can't capture the true requirements when trying to automate a manual process, because no one actually knows the current process.
- The current process is filled with logical holes and gaps that workers make assumptions about during their day-to-day work, which makes it impossible to write a complete spec.
- End users and stakeholders do not have a concrete idea of what they truly want or need.
Agile development made sense, but there was a lack of tools to work with Agile "cradle-to-grave." So they decided to stop consulting and write a tool to do just that. They based the tool on the Scrum school of Agile thought.
OutSystems shipped version 1 of its Agile Platform in 2002, and the company released version 4.2 of the platform on November 18, 2008.
The platform starts at the requirements gathering process, and due to the nature of Agile development, it does not really have an end point. The BAs start using it by defining requirements in it, modeling the application, and so on. From there, the system is able to determine an approximate amount of time that the project should take based upon the project design. This approximation is known as a timebox. Once the timebox is created, a cycle of Scrum sprints begins until the time limit is reached. At the end of each sprint, the system feature automates deployment. Once the code is deployed, users are able to provide feedback directly within the system (an insanely innovative idea), which ties back to the requirements system and can be the basis of another sprint.
The platform is only capable of writing Web applications, but the tools are primarily standard desktop applications (some aspects of the platform have Web interfaces) that communicate with a central server via Web services in a traditional client/server model. There are also some aspects of the platform that are provided in a SaaS model and hosted by OutSystems.
OutSystems replaces your IDE, the language you develop in, your version control, your deployment methods, your project planning tools, and your data modeling systems. In fact, the only parts of your existing development systems that you will be keeping are your Web server (OutSystems can deploy code to J2EE servers and IIS) and your database backend.
If you have existing COM components, Java or .NET components, and Web services that you want to reuse, there is the Integration Studio, which allows these items to be transparently wrapped so that they may be used within the platform.
In terms of writing code, OutSystems has created a very high-level domain-specific language (DSL) for Web development. In fact, the IDE that they showed me is nothing like a traditional IDE. It is more like a flowcharting tool, in which code acts as a type of metadata attached to each node on the chart. Instead of writing functions or subroutines, you write workflows that can optionally have return results.
Watching OutSystems' online demos and the demos that their team did for me, the reuse of existing code and use of underlying databases is really slick. Like some of the high-end reporting tools out there, it does a very good job of abstracting the database so that you are not thinking in terms of tables and rows but discrete pieces of data. I like how, when they wrap a COM component up, it is really transparent to use.
Each change that you make creates a new version of the workflow. Once you perform the development needed on a workflow, you deploy it to the server. Deployment is a single click and completely automated. The OutSystems platform straddles your Web server, outputs the appropriate code (Java for J2EE servers, C# for IIS), and places it on the servers. Rolling back deployments is equally simple: You republish the previous version. If a new version adds database attributes, and it is rolled back, they are left in the database. However, in some circumstances, you may need to manually resolve database differences after rolling back. The deployments of workflows, rather than entire applications, means that you can discretely roll out functionality and roll it back as needed.
The applications themselves look very polished. Like most systems now, there is liberal usage of AJAX. One thing that I like is that the AJAX is a lot smarter than the usual stuff I am used to seeing being triggered on the "onChange" event of various controls. For example, validation occurs once the user finishes typing, not while they are still typing. One of the optimizations in the system is that they build a message queue that filters out duplicate messages; this prevents the constant flood of redundant communications with the server that plagues some AJAXed systems.
Once the application is deployed, users can instantly provide feedback on it. They can click the screen and bring up a feedback box. The feedback items go into a queue. When viewing the feedback, the developer or BA can see exactly which part of the screen the user clicked on to provide feedback, allowing them to pinpoint exactly what is being asked for, instead of the usual back-and-forth interrogation that is commonplace for development teams.
Another kind of available feedback is performance metrics. The system has a screen where you can easily see how long requests are taking to be fulfilled, allowing you to pinpoint performance bottlenecks. This kind of information is available in other systems. The difference is that the systems administrators usually do not look at the log files themselves; they only give them to developers when there is a problem they are trying to solve. The OutSystems platform puts this information in a place where it is much easier for the development team to be proactive about it.
Finally, the system allows for security to be set on various pieces of the code so that only certain individuals or teams can alter components, workflows, etc. This kind of functionality exists in traditional version control systems too, but it is good to see it here in a way that blends well with the rest of the platform.
What I find especially compelling is the overall flow. I think the idea of appending code to a workflow is interesting. We're starting to see this in the .NET world with Windows Workflow Foundation, and the UML folks seem to have had this for a while (I can't say for sure, since I never used UML).
I am also impressed by the flow: diagram, code, deployment, feedback. I said a while back that the tools we use to develop need a complete overhaul in terms of their approach to the process and applications themselves. I still stick by that, too. I think the idea of writing imperative code to create 100% of an application is a dead idea. I think that some parts of an application make sense to be written declaratively, some parts are best suited for a functional approach, and others are best suited for imperative programming. Is OutSystems a perfect answer? Doubtful. But it is a breath of fresh air in a market crowded with vendors trying to help us do old tasks marginally better, instead of giving us new paradigms to get our work done.
I think that developers who are more "old school" will hate this product. It takes away a huge amount of the fine-grained control that these kinds of developers (and much of my heart is set in this pattern too) are accustomed to. Indeed, the OutSystems Agile Platform is, by far, the most drag/drop-oriented development tool I can ever remember seeing; it's not just the UI, but the entire code logic. On the other hand, I like that the code's flow is automatically charted (and therefore, documented), which seems to be a dying art, especially in the various "code first, document later" schools of thinking that have become popular. For someone who hails from a more Waterfall-oriented background like I do, the idea of the project starting with well defined (although changeable) specs that have code appended to them is, in a strange way, extremely appealing.
Additional tools aimed at developers using Agile development
J.JaDisclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.
———————————————————————————————————————————————————————-Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!