Help educate a non user of the Agile Platform

Help educate a non user of the Agile Platform

  
The following blog post was recently discovered and I felt that it was only fair to give the actual users of the Agile Platform an opportunity to share their experiences. Thus, I have provided the original blogger a link to the site here and am hoping everyone will give this a quick read and add some 'real world' insights to using the Agile Platform. Here is the original (an a bit negative) post:


Agility: and the design of Relational applications.

Since building the AgilEntity platform I've noticed the tactics that many companies claiming to use agile development methodologies use to market their own development platforms built over the last 7 years. I've isolated these tricks and list them below.

Any change to existing software is called "an application".

One of the tricks that I've seen used by many of the stand alone or web based providers is to generalize the definition of the well known term "application" to include updates and modifications to existing applications. This is a subtle point , as it allows them to describe changes such as adding new views of data in existing database tables using supposedly advanced visual modification tools, as deployments of entire applications. In reality, these are not application deployments, they are application modifications. The systems are not building entire layers of back end data base tables , business logic and front end UI components but instead are adding or modifying elements to an existing application. The underlying datastore remains a unique constraint to the flexibility of application redeployment. Any development platform that purports to redeploy an application is also implying that they are some how destroying and rebuilding database tables that conformed to an existing schema, and this is never done as , destroying a table destroys its data unless a complex migration process is set up and in that case , such change can never be performed "instantly" or "in a matter of minutes" as many of these products like to indicate. A few that come to mind that use the "modification as application" trick are Outsystems Agility platform, Zoho.

Deploy an application in minutes!

This claim is constant and for the platforms that use it, the reason why is seen in the demo. videos they often compile to "prove" their case. The applications that are deployed are always highly linear applications with no relational mappings between database tables , such as one to many or many to many relationships between extracted data. The most efficient of developed applications will involve such relationships ...unfortunately for "deploy in minutes!" claims these applications are difficult to design and built in a UI that is not aware of the precise relationship between the tables and more importantly , how the underlying datastore expresses those relationships most efficiently. In most cases the use of entity relations tables in the design establish these relationships on the data end and then more complex business logic for relating created tables to one another in the required ways must be designed as well...however this process can not be performed and deployed in minutes. It is true, that changes to an established application of this level of complexity can be performed rapidly but that is more a hallmark of the design rather than the UI tools used to create and map the relational changes. Often the demos show examples of creating User tables and retrieving or updating data from such tables...obviously this is easy to do in minutes as no relationships between the user table and any other table are established in the demo...however what happens if the changes require addition of new columns to an existing User table with 5,000 records? Now more complex actions are required on the datastore and these often take the process outside of the simple development automation created by the platform.

Claims of redundancy that are not true.

One important aspect of runtime applications that are accessible to a varied user community is the ability to scale smoothly. Often the development platform providers claim that scalability is easy but hide the fact that this often involves patches and script additions beyond simply just installing the development tools on a new machine. Others claim that their systems lack single points of failure but their design diagrams clearly show this is not a generally true claim. Outsystems Agility package only lacks single points of failure in the execution environment, the deployment server which is unique could suffer a failure and put the application development process in a disarray. They are careful to qualify their statement but they don't address the real dangers of failure onf the deployment server. I've only given cursory examination of the many available "platforms" but I am sure they are equally filled with wild claims cleverly hidden behind slick web page designs and many demos narrated by attractive young women.
As a user of the platform for the past 6 years, I've seen it evolve and improve in many ways, but the claims done in this post were never true, not even in the first version of the platform.

- Any change to existing software is called "an application".
One of the first strong tag lines about the platform was "built to change!" and that is what it always delivered. The ability to perceive the code in the visual development environment and change it in a really fast and efficient way was, and still is, one of the main advantages of the platform.
The extent of the modifications done using the OutSystems Platform has no boundaries, it can go from correcting a misspelled word to redoing the application from scratch, and this includes adding new tables or new fields to existing tables without losing any data or needing migration processes.
What the deployment of a new version of an application does, is update the data model and replace all the application code. So, in fact it is a deployment and no, it doesn't destroy and rebuild the database, just updates it with the changes done by the developers.

- Deploy an application in minutes!
Actually, for simple applications it deploys in seconds ...
What happens in the deployment process was already described in the previous item, and although the time necessary increases with the complexity of the applications, it really takes only minutes.
"however what happens if the changes require addition of new columns to an existing User table with 5,000 records?" ... if adding new columns to tables with 5000 records didn't execute in seconds I would be very worried about my database performance, not the OutSystems Platform performance ... even if it was 50.000 or 500.000 records!

- Claims of redundancy that are not true.
"Outsystems Agility package only lacks single points of failure in the execution environment" ... well, if i have an application up and running, that is the place where i want the redundancy working like a charm, to avoid having someone or other automatic way of surveillance to check if the applications are up and running.
"the deployment server which is unique could suffer a failure and put the application development process in a disarray" ... true, but this is easily detected, because there is someone trying to deploy some application. And then again, how often does a machine completely dies? And how long does it take to deploy a new server from a backed-up server image?


"I've only given cursory examination of the many available "platforms" but I am sure they are equally filled with wild claims cleverly hidden behind slick web page designs and many demos narrated by attractive young women."
It shows that at least for the OutSystems Platform the examination was less than cursory. I would advise downloading the OutSystems Agile Platform Trial and try it himself, and discover if the many demos are true or not.
"demos narrated by attractive young women"

I didn't know that Mike is an attractive young woman. It's a strange name for a girl...

:P

But seriously:

"Any change to existing software is called "an application".

No it isn't. Every delivery at the end of a sprint is "an application". In a sprint there can be dozens, hundreds of changes to the application. Calling each one "an application" would be silly. At the end of the sprint it is called "an application", since that's what it is: it is a usable application that delivers some of the required functionality.

"Deploy an application in minutes! "

End users don't care about "datastores" or adding columns to tables or how many lines of code you wrote or how brilliant your code or data schema are, they care about listing and validating orders or customers or whatever their job actually is. If at the end the sprint they can do that, or at least do some of it (knowing that in the next sprint more is coming) they'll be happy.

"Claims of redundancy that are not true."

Sure, if he ignores the actual statement, he can always say it's not true.
Hi,

I think the analysis made on the platform is incomplete in many aspects and plain wrong on others. Just reading this sentence ("obviously this is easy to do in minutes as no relationships between the user table and any other table are established in the demo") shows me that the person who analysed it, didn't do a good job.

Even on the simplest of demos, there are always relationships between the various tables.

I would suggest to the person who wrote the analysis to do as Filipe Rodrigues said. Download the trial version and play around with the functionalities of the platform. I'll bet you, that within a week you'll see why, we, users of the plarform can't agree with your analysis.

best regards
Here is another interesting source of information re the Agile Platform! And within the next couple of weeks a business case on a project delivered by Atos Origin using the Agile Platform will be posted here first in Dutch and later in English. Check it out at...

http://adi.atosoriginblog.nl/2008/12/18/outsystems-agile-application-lifecycle-management-voor-java/