Skip to main content

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.


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

Mike said…
Hi, I am the VP of Marketing for OutSystems and the Agile Platform. I had the chance to read your post and decided to share it with our user community to get them to provide some feedback on your thoughts. I took your post and re-posted it on our Agile Network’s user forums asking for feedback.

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
David Saintloth said…
No problem Mike, but next time ask first! I would have said yes anyway. ;)

Popular posts from this blog

the attributes of web 3.0...

As the US economy continues to suffer the doldrums of stagnant investment in many industries, belt tightening budgets in many of the largest cities and continuous rounds of lay offs at some of the oldest of corporations, it is little comfort to those suffering through economic problems that what is happening now, has happened before. True, the severity of the downturn might have been different but the common factors of people and businesses being forced to do more with less is the theme of the times. Like environmental shocks to an ecosystem, stresses to the economic system lead to people hunkering down to last the storm, but it is instructive to realize that during the storm, all that idle time in the shelter affords people the ability to solve previous or existing problems. Likewise, economic downturns enable enterprising individuals and corporations the ability to make bold decisions with regard to marketing , sales or product focus that can lead to incredible gains as the economic

How many cofactors for inducing expression of every cell type?

Another revolution in iPSC technology announced: "Also known as iPS cells, these cells can become virtually any cell type in the human body -- just like embryonic stem cells. Then last year, Gladstone Senior Investigator Sheng Ding, PhD, announced that he had used a combination of small molecules and genetic factors to transform skin cells directly into neural stem cells. Today, Dr. Huang takes a new tack by using one genetic factor -- Sox2 -- to directly reprogram one cell type into another without reverting to the pluripotent state." -- So the method invented by Yamanaka is now refined to rely only 1 cofactor and b) directly generate the target cell type from the source cell type (skin to neuron) without the stem like intermediate stage.  It also mentions that oncogenic triggering was eliminated in their testing. Now comparative methods can be used to discover other types...the question is..is Sox2 critical for all types? It may be that skin to neuron relies on Sox2

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform cert