Project Management Mistakes
Project Garbanzo is run by business people, who are smart in their areas, but they are not engineers. They would have been engineers at one point in their careers, but not any more. You don't find "star" engineers or architects in charge. It is always the VPs or directors. Application developers are second class citizen in the company when compared to developers in the technology division.
CEO Lonnie Earles would often say he runs engineering. But he is running it from another planet as far as applications are concerned.
No applications background in key team
There were 2 divisions focussed on Project Garbanzo: one focussed on developing application technologies; the other focussed on developing applications. The former team did not have applications background and totally clueless about requirements. They were experts in building IDEs (similar to Eclipse) and frameworks (like, JSF and JPA implementations). Their demos were simplistic applications like stock quotes, weather reports, or a simplistic movie rental web store.
Lets take one example of application requirement, an area in which I would have worked if I was in that company: extensibility.
No matter how smart the application is, customers need to extend them to suite their business needs. Extensibility mean addition of new tables, new columns in tables, and automatically propagating such additions into the business logic and right into the user interface.
The application technology team had no clue of such requirements. In fact later it was an applications team that started to work on this later in the cycle.
Should have started small
No need to elaborate on this. Instead of 100s of applications, should have started with 5 or 10, and focussed more on the platform.
Architecture mistakes
One of the great visions of CEO Lonnie Earles was to reduce the number of databases to avoid data fragmentation. But to reduce it to single database for such a large project introduces other problems. For example, applications cannot be upgraded independently. You would always have to upgrade all applications together and that would cause long downtimes.
There is no doubt that customer data should be in a single master database. But there is no reason why products data has to be in the same database. One can employ the principles of vertical partitioning and separate the two.
This issue was fixed later, and concept of "pillars" was introduced to identify a group of applications that will run in separate databases. But proper diligence was sorely missing in the design.
No real backend-frontend separation; no focus on APIs
Even though business logic was implemented in well defined business objects, they were too closely linked to the UI. It was almost impossible to expose them as remote services. One could theoretically, but it was not practical.
So, for example, if you would want to write native apps on iPhone or Android, you could not realistically use those business services.
A better approach would have been to build independent, caller agnostic APIs, which are easy to be exposed as web services.
This is my top rant: missing backend-frontend separation. Very simple, yet absent.
No comments:
Post a Comment