[tweetmeme source=”sureshsambandam” only_single=false]Part 1 : Top down vs Bottom Up
There are quite a few visual development tools that have failed in the past. When I say past, I meant the pre-cloud era. The commercially successful ones are Visual Basic, PowerBuilder (just googled and found out that PowerBuilder still exists under Sybase) and Oracle Forms 4.5. Although, popularity and merits of the language need not co-relate. 🙂 !
And, there are quite few that have come up in the current cloud paradigm. Few Examples : Coghead (already in dead pool), VisualForce of Force.com, WaveMaker, Zoho Creator. My POV is on the approach taken to solve the problem (of visual development) rather than any of the companies/products itself.
If you take a closer look at most of the visual products one subtle but startling similarity is: Most of them take a Top-Down approach for developing the application.
In my opinion, the problem lies here! If you want to know why see this Article on Wikipedia and Paul Graham‘s blog post on ‘Programming Bottom Up‘. While Paul’s article goes into a little tangential context of enriching Lisp, leading to a richer dialect – the essence of ‘Bottom Up’ comes out when you read between the lines. Also check out this thread Top Down vs Bottom Up on TheServerSide.com
It is natural for human comprehension to think of a system’s high level design and functional use cases in a ‘Top Down’ style. However, when it comes to implementation, ‘bottom up’ approach has to be followed. The shortcoming with most of the visual development tools is that they have extended the natural human comprehension far too much into the implementation. To the extend that, most of these tools start with a visual canvas where the user starts painting the application by ‘drag and drop’-ing widgets from the palette box. While I understand that this is easy for business users and analysts to start off quickly – there can be no compromise on the abstraction that is required to build good software.
The approach of starting from the page or a canvas can accomplish simpler – situational applications (use and throw). However, it will be close to impossible to build industrial strength SaaS Business Application like an Insurance Underwriting System or an Automobile Dealer Management System. Also, the applications built using these tools will be little more than a ‘data entry’ / ‘book keeping’ system with very little capability to support sophisticated business logic (more on this in Part 2 of this series). In fact, when prospects approach us for simpler situational apps that doesn’t involve heavy duty business logic we have recommended ‘Zoho Creator‘ – another ‘Made In India, Made for the World‘ product. In fact, unlike other products Zoho Creator clearly mentions in their home page ‘Build Your own online Database’.
So, what is the correct approach solution? Just like in OOP, implementation has to be bottom up. You define the object model for small components and start relating them with other components. An object model or data model, we use both these terms inter-changeably at OrangeScape, contains how an object is represented in an optimized / co-related fashion in conjunction with other objects in the system. Again, just like in OOP, the object is an encapsulated atomic unit that represent data + business logic (How do we deal with logic in Part 2). Many such fine grained objects together make up the data model of a logical business component. Putting all these logical business component model together in perspective gives the developer the full picture of the software – I call this macro-model for want of better term.
All of this is not some theoretical rant! One Example. OrangeScape’s SI Partner Wipro – using their development team – with consulting from OrangeScape has implemented a very large ERP for a government organization where the ERP is being rolled out across 743 office locations in India. Each office location is a Tenant in this huge multi-tenant ERP. This project (I can’t name it yet, due to confidentiality clauses) is a prestigious project similar to the Citizen UID Project. We haven’t gone outside of OrangeScape’s Studio to build anything in this huge ERP implementation. The success of this project is a ‘proof point’ for my argument on ‘bottom-up’ approach supported by the OrangeScape PaaS Platform among many other capabilities.
Finally, in my view, starting from ‘Object Model / Data Model’ is closer to OOP and starting from UI Pages takes us back to days of ‘Procedural Coding’! After all these advancements in programming, why go back in time?
I see you asking: ‘How does one or OrangeScape for that matter bring out object modeling in a non-intrusive visual manner?” Will talk about that in an another post.
[tweetmeme source=”sureshsambandam” only_single=false]