Aaron’s Potlatch

I just read an interesting blog about email and getting rid of it if it is controlling your work life, as well as the article they refer to http://www.theage.com.au/news/essential-gadgets/when-the-inbox-is-on-the-outer/2007/09/19/1190486197735.html is also interesting.  It definitely made me envious, to have an organization that forward thinking in how to communicate.  We push a lot of things out on wiki now, but much of the organization still uses email.   In addition to the focus, I think wiki’s or other online collaboration help with other aspects of communication:

•  Wiki’s are “Permanent”, so people think about what they write more before sending it.
• Wiki’s are “Open” so people don’t write things they probably shouldn’t have to begin with.
• Wiki’s promote people to stick with the facts, and stay away from lengthy political discussion.

However, neither Wiki’s or email address some other bastions of corporate waste, Meetings!

• Decision making:  Andrew McAfee has an interesting article that recognizes decision making as separate from information itself.
• Brainstorming:  Meetings can be (although most aren’t) very effective at brainstorming.

At work, I and my team have been assigned to work on a new project, however, nobody knows what this project is supposed to accomplish. Everyone is talking about providing the “best widget/service in the industry”. Resources, and millions of dollars have been allocated, but nobody can describe why, or what the desired end goal is. Just to have a shinier fancier widget or service?In my experience, this is the wrong way to communicate, collaborate, and motivate. Companies should agree upon goals that are stated in terms of customer experience of what customers really want, and should be described in desired end result that is free of HOW to accomplish this. Couple of examples:

1. GM vs Toyota. GM (or other American auto companies) had been merrily dominating the American auto industry, but Toyota with an obsessive focus on Customer value was addressing quality issues. I can just picture internal goals/metrics at GM at the time about producing “x units” or “y cars/day”. While Toyota focused on producing happy customers. Because GM focused on an internal measurable (x units, or y cars) as opposed to a Customer metric (were they happy?), Toyota eventually won out. That focus on internal deliver-ables which are ASSUMED to be equivalent to what the customer wants are almost never right. All employees must have an understanding of what the goal is, what the customer value, see the toyota usa web site about “Customer First“.

2. Ipod vs “MP3 players”: IPod was not the first MP3 player on the market, but it did come to dominate. Other MP3 players may have had more “features”, but Apple realized that by focusing on what customers really wanted (“Good music listening experience”), they had to expand their definition beyond the “MP3 player’ and encompass some additional portions of the music experience (coolness, and the transfer, management of songs).

In both of the examples, Toyota, and GM made what I call a Proxy Association Error. That is, the Music player was a “proxy” for the music experience, and the automobile was a proxy for the transportation, people didn’t want car’s or players, they wanted music experience and transportation. Once a better proxy was found, the customers abandoned the old way for a better one. Toyota, and Apples competitors didn’t see this, they thought the “Car” and “MP3 player” were the actual thing that people wanted.

So, here are my paradigm for how to distribute work (not tasks) to a company:

1. Get the entire employee population involved in seeking to understand what customer value is (real customer value, not proxy error, the “music experience” not the “mp3 player”).

2. The goal of any work should be stated in how it should help the customer. The Goals should be distributed should be stated in terms that are free of how, and leave the wisdom of the crowds and changing winds of the marketplace open to allow a different solution that still makes the customers happy.

Examples:

“Identify the top causes of dis-satisfaction by customers, and put in place plans to mitigate them” not “Implement improvement of the invoice service”. The first leaves the ability for the employees of the company to contribute their own ideas, the 2nd doesn’t.

I am working on a new Strategic Goal planning tool which helps users create goals, collaborate on them with others, and track accomplishments, with visibility up and down the organization. It is intended to bring the best aspects of the wisdom of the crowds to helping guide a company as exist within the Open Source community.

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.

Over the last few years, our work experience as software engineers has changed pretty drastically, or at least where I work. More and more web services and application integration is taking place. Third party apps offer web service connectors, there are large numbers of technologies for doing integration from ESB/BPM/BPEL to ETL or Change Data Capture. As more and more corporate development and software development goes to Software As a Service (Salesforce.com, Amazon S3, Google Apps), Open Source in my opinion faces a challenge of remaining relevant. WordPress.com doing a combination model of open source software and then a hosted version of it is an example of the struggle ahead.The traditional choices of software look like this (gross approximation but it works).

Diagram 1: Software development stack options of in house development with Open Source libraries, or Open Source framework with customizations.

You seemed to have a choice in doing software development to choose a series of libraries or a framework Libraries: Hibernate, Jboss, Struts in the Java world, Ruby on Rails, Typo etc in the Ruby world, or, Django, Zope, Plone in python Frameworks: Joomla and a large number of PHP apps, or even Sharepoint in the non OSS MS world. However, I think if other people’s experience are like mine, trying to get a “CMS” framework to fit into your needs was difficult. Most Frameworks, Portals, and CMS sytems fall into a trap of trying to be a better mouse trap and asking “if only you use my system, it will be good”. CMS, Portal, or App frameworks talk about “Plug-in” architecture, but still this forces you to a generally cumbersome development paradigm compared to building your app from library components.

At my workplace, our applications were custom software development applications, but it would have been nice to have the built in general navigation/menuing, page management, content management of the CMS frameworks to show messages within the application. However, to build on top of the CMS framework was much more cumbersome for doing software development.

So, DemiSauce is software that is only “half of a software stack” (Hence the name: Demi for half, Sauce for Software As a Service SaaS). It is not meant to be a stand alone web application. It is meant to be able to provide web services to your custom software applications giving them ability to get and display “content” such as “news”. It is meant or assumed to also have a cache system between the application, and DemiSauce servers as well. This allows content and services to be shared across multiple custom software applications.

The Services that are currently being kicked around are:

• Content Management:
  • GetListOfContent for a context (page/area of site)
  • Knowledge base, or help system authoring
• Feedback tools: “Submit feedback here…”
  • “Rate this page or app”

DemiSauce is a Pylons Web Application built with SqlAlchemy and mako templates.

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.