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.
Why the AgilEntity platform is proprietary
Recently I was asked by a fellow technology colleauge why I was choosing to keep the AgilEntity platform proprietary and not making the platform available for sales and marketing as the platforms indicated above have been doing. The main reason has to do with protection of my intellectual property in the form of an advantage derived from the tight integration of all development elements of the AgilEntity platform. Aside from maintaining the competitive advantage of the hyper efficient design for my own use, is the fact that no platform could ever truly achieve the promise of fast development and high application complexity. Salesforce.com started with the same sort of claims of fast RAD development and now with their force.com services are essentially an online version of the complex development shops of old. So rather than deploy endless options for building custom solutions, AgilEntity will be used internally to design specific vertical applications for complex problem spaces that will work more efficiently than anything being produced on the any of the other platforms. The numeroom.com commercial web site is a case in point, it is a multi-tenant , secure, distributed and scalable application. It employs a complex relational design that is most efficient for the problem of real time collaboration and simply could not be done on RAD development environments. The site is a proof of concept of the efficient design methodology of the underlying closed sourced AgilEntity platform, the proof of the design to be in how the varied unique features enabled by it are harnessed by the growing community while being allowed to scale as needed by the platform. I think this tactic is the best route to take to testing the true agility of the platform, and time will tell the tale.
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.
Why the AgilEntity platform is proprietary
Recently I was asked by a fellow technology colleauge why I was choosing to keep the AgilEntity platform proprietary and not making the platform available for sales and marketing as the platforms indicated above have been doing. The main reason has to do with protection of my intellectual property in the form of an advantage derived from the tight integration of all development elements of the AgilEntity platform. Aside from maintaining the competitive advantage of the hyper efficient design for my own use, is the fact that no platform could ever truly achieve the promise of fast development and high application complexity. Salesforce.com started with the same sort of claims of fast RAD development and now with their force.com services are essentially an online version of the complex development shops of old. So rather than deploy endless options for building custom solutions, AgilEntity will be used internally to design specific vertical applications for complex problem spaces that will work more efficiently than anything being produced on the any of the other platforms. The numeroom.com commercial web site is a case in point, it is a multi-tenant , secure, distributed and scalable application. It employs a complex relational design that is most efficient for the problem of real time collaboration and simply could not be done on RAD development environments. The site is a proof of concept of the efficient design methodology of the underlying closed sourced AgilEntity platform, the proof of the design to be in how the varied unique features enabled by it are harnessed by the growing community while being allowed to scale as needed by the platform. I think this tactic is the best route to take to testing the true agility of the platform, and time will tell the tale.
Comments
Note, our user forums are open to anyone for reading so when you get a minute go check to see what our users have to say. The direct link to the repost is at: http://www.outsystems.com/NetworkForums/ViewTopic.aspx?ForumId=27&TopicId=5405
Mike