Unified task list: A requirement mirage?

When developing a system that people use in their day to day work, I often meet the following requirement: “A user should be able to see all tasks from each functional area on a single screen.” This requirement requires integration with all parts of the system, making it architecturally costly. Luckily, the requirement might often not be needed at all!

Everyone will tell you: The most powerful technique for dealing with a large problem is breaking it up in smaller problems. But we often end up breaking the problem in such a way that the parts will have to talk with each other. And in software development, integration is expensive and bug ridden. So I want to avoid it.

There are some areas that tempt me to integrate the parts more tightly:

  • I might want to share information about customers. This is usually a fairly benign integration point, as it’s read only.
  • I might want to reuse a service that looks similar to what I need. In a larger ecosystem, this often creates more noise, as other users of the service may be affected by any changes I need to make.
  • And there might be places where a user may want to see information from several systems. The most common one is the “unified task list”. This often result in each system having to let go of the life-cycle of it’s own processes, which may increase complexity a lot.

Of these, “unified task list” is the one that’s at the same time most costly and most related to real requirements. While rejecting list can potentially make the project a bit more expensive, rejecting a unified task list means you’re not delivering what the user asked for.

Or did the user really ask for a unified task list? On my last project, we ended up having separate task lists for separate types of tasks. The users were indifferent about unifying these. As a matter of fact, we got the following responses from our user panel:

  • In one user’s organization, they only process forestry subsidies every few months, because there are so few and we want to see the total subsidy expenditure
  • In another user’s organization, the process the same tasks every month, because there’s a lot more activity.
  • In almost all the organizations, the person dealing with forestry subsidies is another person than the person dealing with road subsidies. They have their expertize in different areas, know the external parties for their separate fields and want their separate tasks lists for their jobs

Do you have a requirement for a “unified task list” in your project? Are you really sure the users really need it?

Comments:

[eirikma] - Aug 18, 2010

I’ve seen this a few times as well. It turns out that users “need” this in order to get an overview: a read-only application, since the only appropriate place to interact with the data is in their respective source applications. If a little lag is tolerable, the unified-list-service can be built as a stand-alone (mini) data warehouse application. It’s sole service is a reasonably up-to-date list of tasks with just enough details to link to the actual task in it’s home system. This solution keeps the integration issues (and most data access issues) away from business logic issues.

Johannes Brodwall - Aug 18, 2010

Nice comment: If all you need is statistics across applications, you can extract statistics, instead of integrating the application logic.