James McGovern posts on alfresco which is an open source content management system. The fact that's it open source or content management doesn't make it interesting to me, but rather who's behind it. It's a former Documentum heavy hitter and a former Business Objects COO.
This is not the only attempt at using open source to create a dislocation play in the mature software market by former high flying .com types. What distinguishes these open source efforts from other developer-driven efforts is the attention to detail and overall polished finish to their efforts. Their websites, documentation, general razz-a-dazz is of a high quality. Additionally there's the fact these guys have money and industry contacts. They can afford to employ developers, graphic designers, HCI types, etc which bottom-up open source efforts can not. Here's a list of some that I've come across.
First one that appeared on my radar was chandler which Mitch Kapor (of Lotus fame) is helping run/setup and perhaps funding. It's an attempt to build a better email/collaboration client. It's been going on for a few years and you have to wonder if it's going to deliver anything.
In the same market is zimbra which is a web2.0 attempt at the same problem. The management team at zimbra is full of ex-openwave folks, and Scott Dietzen from CTO of BEA. Looks very slick.
In the world of databases, there's an attempt called enterpriseDB which is trying to wrap commercial-level aspects to postgress. Interestingly it's management team is made up of a few webmethods people and other notable industry experience.
Pentaho'steam is made up of former Lawson, Cognos and Hyperion staff. They're trying for a comprehensive BI platform. It looks very interesting. Just noticed that they've sucked the mondrian OLAP project into their platform. Mondrian was one of those open source projects that almost could, but looked like it was withering. I'm eagerly awaiting this as it'll give us some serious BI power at low cost.
SugarCRM is playing the dislocation card in the CRM space. The founders were former e.piphany staff and have put together a management team with a great cv.
But where is the eai dislocation play? There's open-adapter which doesn't look like it's really doing anything, and there are a host of ESB attempts. All of these seem to be developer driven or commercial "chuck it to open-source because we can't sell this junk". Phil Merrick, ex-webmethods is busy with the EnterpriseDB. Where are the rich .com guys who want to shake up eai.
Portals suffer the same fate. Viable open source portals are thin on the ground. The best being Liferay, but even that's a bit hokey and complicated and fancy-technology driven. There's no ex-plumtree or epicentric zillionaire willing to speculate on open source.
This article How to Version Schemas is a good overview of a complicated topic. I've seen and worked with most of the more respectable methods mentioned here. My favourite method is probably the namespace method. However, it still doesn't loosen the coupling in any way whatsoever.
The article is a bit of a strawman to set up a sale for this guys tool, but it does bring nice clarity to the problem. I'm not sure I agree with his proprietary repository storage mechanism, as I inherently prefer plain text files.
I like the idea of versioning each type seperately though can see a serious management overhead in this.
All this versioning though, doesn't really let you deal with the various versions running around in the system at runtime. No SOAP stacks I've worked with are intelligent enough to deal with various versions of schemas, let alone types. This is the kind of capability I'm expecting to come out of the apline stack, who'se goals are described here.
If you're into Business Process Management and want to understand how it's being realised into technology, do take a look at this report by the Business Process Trends people. It's a 250 page report that takes a detailed look at many of the BPM players. The first section is a summary of all aspects of BPM as seen by these analysts. It's a comprehensive look at the current state of play in BPM. These analysts have been looking at BPM for a few years now and have a thorough understanding of the space. The second part of the report is a detailed looked at each vendor through the framework they defined in the first section.
It's an excellent piece of work. And it's free. It's far better and more comprehensive than any Gartner report I've ever read - and it's free, did I mention that?
Notable absenses from the vendors discusses are SAP, SUN(Seebeyond), WebMethods and BEA.
For general, all round monitoring of the BPM space I cannot go past these guys. They're much more than just marchetecture analysis and deal with lots of process specific issues. Sign up to their newsletter too.
Time tracking of software projects is woeful and hated. Here is an attempt to address this problem. As you may know, I'm involved in improving the estimation of our organisation. The other side of estimation is time-tracking, firstly, some context;
I hate doing weekly timesheets. I hate them because they do not help me improve project delivery. I hate them because the PMI-droids think (sic) that this is what they need. I have worked in numerous organisations where we must keep a timesheet. Usually this meant logging into the unwieldy timesheet application which someone developed in their spare time and adding my time data for the entire week just passed.
The granularity of these entries was always at the project code. So for example, if I worked every day on Project1, I would log all my time as one block against Project1. What it never captured is the fact that one particular issue took four times as long as it should have. Because time is logged only against the project we can never look at where we spent our time as opposed to where we expected to spend our time. All we get is that project1 took more time than it should have.
Part of the problem is that the PMI-droids use a very blunt instrument, the gannt chart, to try and manage the project. MS Project is a uni-directional tool. As you and I know, what happens in a software project is quite removed from the gannt chart. New tasks are needed all the time, which quickly invalidate the project plan and making it a useless artifact. Basically, there is no feedback loop.
What is needed to solve this problem is a bi-directional, bottom-up, project management tool where time is track at individual task level. Tasks need to be created at whim by individuals as needed. Time spent needs to be assigned to each task, which can then by categorized in any manner required by whoever wants to categorize. Typically, in software projects, this will be things such as phase of project, component, technology, etc.
The place I currently work at uses an issue-tracker as its central work-organizing system. It's a great tool, extremely flexible and fits our issue-tracking needs quite well. We use it for all types of work, development, support, general-day stuff. In fact, it's almost the perfect bottom-up time-tracking project management tool I'm looking for. Additionally, the corporate culture encourages people to use the tool.
However, time tracking is spotty and variable. Bottom-up issue creation is spotty. If people can get away with not creating an issue, they will. Like me, we're all lazy. The tool is a little unwieldy when it comes to entering time data. It's a couple of clicks and a bit of waiting, once you've found your issue. Like other form-based apps, it's a bit cumbersome to create a new issue too.
We initiated a daily status report about a year ago, which is itself a bit spotty and of variable use. The basic idea is that you write about what you did/achieved in a day, so that team-leads, project-managers, etc know what you're up to. It doesn't replace a daily scrum or things of that ilk.
So, now you have the context to see my diagram. This is my first attempt at a cause-and-effect diagram. I'm not sure I've really gotten it right. Sometimes my arrows seem like relationships rather than causes. Nevertheless, this diagram crystallizes my view on how this whole "estimation" process needs to work. This system is not in effect yet. It's close, most parts have been proto-typed quite deeply. Some parts have been released to production in a "use at your own risk" state. I'm interested in other people's experiences with putting together a time-tracking system.
I've labeled all the arcs for ease of explanation. Unfortunately, I can't really show any screenshots of things as I feel that would get into trouble from my managers.
Firstly, we've implemented the lowest possible transaction-cost time-keeping system that's possible. It's a command-line tool that allows you to log time in less than 10 seconds, create an issue in less than 30, or even edit some attributes of existing issues. Because we're all software developers we can get away with this. It has other useful features such as listing, etc. By taking away as much friction from the process as we can we allow the possibility of more accuracy.
arc a and b: Usage of the time-keeping system reinforces the use of the daily review process because the daily time spent is viewed during the review process. The review process confirms that the time logged into the system is valid and that nothing has been missed. The use of the daily review process reinforces the use of the time-keeping system because you know you have to validate the days work. What we have here is a reinforcing loop.
arc c and d: There is such a concept as a project dashboard in our organisation. This dashboard is a collection of current metrics of the project. Things such as number of issues in various states, time logged, etc. It also serves as a review of who has used the daily confirmation process. Because you know that your project lead will come after you if you don't confirm your day, you tend to do your daily review process.
arcs h and q Developers do not know how good they are at estimating. We've developed a report that identifies different roles in each estimate and we present this data back to the developer to help them improve their estimation. My goal with this is to have a troupe of developers who can quantify their skill and thus take measures to improve it. I would love it if in their next job interview a developer could say "my estimates are +/- 10% and here I have the data to prove it". Because of this, I feel there is direct value which can be sold to developers to motivate them to keep accurate time data. Time keeping stops being a task that needs to be done to satisfy the masters, but has an element of self-interest. It's this value I'm going to be selling to the group when this gets its release.
arcs e, f, i and g Because of the three reinforcing loops above, you end up with more accurate time-keeping. For the astute reader, you may notice that I've tried to create a value-proposition at each level of our organisation. The individual is incented and cajoled (carrot and stick) to keep accurate data. At the project level we have the dashboard that uses this data to measure the current state of play and obviously, at corporate level this information is just gold. Do you agree?
arc k Now, once we have excellent time-keeping data it turns out we have also have a corporate estimation history. This is because we estimate and keep accurate data at the issue level. Corporate is really just an aggregation of each individual. If we tag issues in various ways it is possible to slice and dice the estimates in all sorts of ways. There is definitely room here to improve, but as a release 1 of this system it'll do.
arc n and i. These two forces represent those that drive us towards standardized estimation methods. The estimation report highlights people's poor estimation skills causing them to look for better ways of estimating than their current method (usually finger in the air). The corporate estimate repository also highlights the same issues as it is just an aggregation of all individuals estimate history. This means, they might look for something like this. The trap is set!
arcs o, j, m, n, p All add up to firstly, knowledge of the quality of our estimates and then hopefully an increase in the quality of our estimates.
With the latest round of cuts to the Novell workforce, I wonder if Novell's excellent integration technology will in some way be released from it's shakles. The Extend Composer tool is a first-class integration technology that Novell aquired by purchasing SilverStream. It's had a lot of difficulty telling anyone about it - because unless you worked there, you would never know it existed. As you saw, it's not even listed on the front page anymore. If you have the time, theres a 90 day evaluation available. Works on tomcat, websphere, weblogic. Ideally, it'd be contributed to some worthy open source project or made to fit into the budding open source integration ecosystem.
