Aaron’s Potlatch

I attended Web2.0 Expo last week in San Francisoco, and the thing that really struck me was the Yahoo Y!OS strategy. A bit of a blend of the Opensocial strategy combined with Google App engine, combined with widget development in general. I walked away convinced more than ever that we are seeing a startling shift in software development. Four or five years ago, we talked about developing on top of other “Platforms” and meant JBoss, BEA app server, MS .NET, Sharepoint, Plumtree server, Oracle Portal etc. Now, when we talk about developing on platforms we talk about Facebook platform, OpenSocial, Google App Engine, and Y!OS.

Changes:

• Creation of Community: Previously to get your software/application out you either created the community, or sold it as a “Plug-in”. Now you can leverage other’s communities.
• Scalability: Google App Engine, and now Y!OS help you scale up and out.
• Pages vs features: No longer are you creating a full application, but maybe a portion of a page, a feature instead of an app.

In creating software, we often are faced with build vs buy vs combination (integrate). While creating a software application, I find that we have a series of patterns that repeat itself related to needing features that are “non core”. Some examples:

• One of our teams an application needs a “Tiny url type functionality” only internal, secure, private to have less brittle url’s. We have ~30 different web based applications that make up our environment, and invariably we break others when we update one and the “link api” changes. We want a means of indirection, so if the end “link api” changes, we can change it on the central “link server” instead of updating the other 29 software applications. See info on PURL’s and a recent project to update the actual PURL sever.
• We also need content (news) to show beside our custom software on the right side context. We need to notify the users of changes to the software, impending outages/upgrades, etc. Since these don’t happen that much we update them statically since we are so focused on “Core” functionality.
• We send out email, and find ourselves creating email templates stored in our own db, or email template management admin tools also.
• We also find ourselves creating a Help system to author little tips/help built into our application. None of these do i consider “Core” to why our application exists. The business

Diagram showing the Core vs. Non core aspects of our applications.

In Addition, we have received numerous requests for other features that have just been to low on the priority queue to ever find time to add to our systems also shown in above under non core aspects of applications.

So, Demisauce’s charter is to provide very, very easy to use through library integration with a server that has admin tools to edit content, but that content and services are utilized by applications via web services.

My work environment is a very large distributed set of web applications. There is a large number of applications, and it seems that we continue to face the issue of rebuilding the wheel for common services.  Many OSS web applications (CMS systems etc) may be suitable, but they all seem to fall victim to the “I am the center of the Universe” design philosophy. This is, “if you use me to build all your stuff, all will be fine”. However, this never happens. We have 3rd party wiki tools, 3rd party CRM. We have custom home grown legacy apps, Microsoft sharepoint. One group took Radiant CMS and installed it, then get a data feed from it to display “news” about their application.

Also, we are building a Menuing application at work that has hierarchical capability. Since many different apps (Some java, some .NET, some 3rd party) are all trying to appear to the end user as a single experience it would be nice to be able to update the shared menu items in one place and have the changes propagate.

The solutions today seems to be “use our app”: Sharepoint has menuing and in theory could offer a web service but that seems like overkill. Plone, the Portals, etc all seem to be focused on getting the applications built on top of their infrastructure.

So, I think the reverse, a set of services which are not intended to be “built on top of” but rather accessed through libraries. Think Amazon S3 services.

• CMS System: Admin to log in and edit, add articles and content (About us, policies, etc). Then the display would be shown within your web application by calling a library (over WS). This assumes you would have caching on your end.
• KB system. Knowledge base/help, again templated for your own system. It looks like your site, and is your site. But, having an admin to go login to and change the content, articles can be shared across sites. I know some of the commercial KB systems have web service API’s, so this would be similar.
• Menuing system. Ability to update navigation and it will update on multiple seperate applications.