Thursday, September 21, 2006

Coghead

Anne2.0 posted a link to an article about coghead.
In their own words:

[Coghead is] A simple, powerful new way to create web-based business applications that can be used by anyone, anytime, anywhere!
[...]
Coghead developers don’t need to know how to code! With just a browser and an internet connection, they can create, modify, and deploy hosted business applications, and collaborate directly with their end-users all via the Coghead service.
Sounds like they're empowering the user - the person who wants to use the application. Sounds like a great plan.
With one major drawback. At the moment, there doesn't seem to any talk of sharing information with exisitng applications.
This is best illustrated with a story (sorry if you've heard this one before) about an organisation that allowed unrestrained use of Microsoft Access. Microsoft Access allows development of simple database applications without (too much) code. (This isn't a crack at Access, I'm sure you can do many marvellous things with it). Across this organisation, many people created applications (some quite complex) that many more people used to run the organisation.
This organisation had a a number of branches (about 300). Each branch had a number of staff, as well as a number of customers. There were about 120,000 customers in total. The organisation was required to keep track of all of this.
Now, if you can imagine, 300 Access Databases, some duplicates (because, after all, Access Databases are just files that can be copied as easily as a Word document), all with their own list of, at least these 300 clients, and all with a different (sometimes duplicate) bits information about the 120,000 customers.
The problem, of course, comes when details change (which they did on a very regular basis), or when somebody to use bits of information from across different databases. It was a nightmare.
Of course, maintianing these applications/databases was a constant struggle, because they'd usually been developed by a member of staff who was on holiday, or who had left, and almost invariable had no idea about normalisation, settling on a naming standard, or programming in general, after all, they'd just knocked this application up in their lunch break(s).
So, how does Coghead solve these problems? As far as I can tell, it doesn't. If you want to run your entire business on it, it's probably ideal, and I'm sure it'll work great, but there seems to be no emphasis on collabaration.
Now, I'm aware that there are businesses using Excel for their central database (bless), and I'm sure this is a giant leap away from that (I mean, it's got workflow tools and security). However, without addressing the collaboration issue, I think the probability of replacing a poor solution with a more powerful poor solution is too high.

1 comment:

Paul McNamara said...

Anne, I agree with your comments about MS Access. The biggest problem (in my opinion) with the desktop databases was that they proliferated individual databases and created islands of deployment where each needed to be managed individually. Integrating data across instances (or integrating external data) was extremely difficult (read: just about near impossible).

At Coghead we’re taking a very different approach. Since ours is a 100% web based model, all of the data and application definitions are managed centrally in a central enterprise-grade database. And, for each application that you create, our system auto generates a web services interface. We also allow integration of external web services.