Programming for Web 2.0

How should we design and code for Web 2.0?

One of our customers said he liked our Metrici Advisor service, but that it needed to be "more Web 2.0".

I was not sure what Web 2.0 meant, so I looked it up. Different people define Web 2.0 differently. It can mean:

• Bold and simple visual style.
• Richer and more dynamic user interface.
• Merging of content with other sites.
• User control over the web experience - "My web, my way".

It would be easy to get diverted into just one of these - a styling make-over, some JavaScript wizardry, some website feeds, or customisation options for the user. But before we looked at individual requirements, we wanted to know whether the underlying software was in a fit state to support Web 2.0, whatever it is.

Like all good web applications, Metrici Advisor separates the underlying logic from the user interface. It also separates the different parts of the user interface: the controller that manages the interaction with the user, the view that determines the content that the user sees, and the visual style for the content (implemented as cascading style sheets, CSS).

The separation between logic and user interface is very thorough, but there were some problems with the separation between the different parts of the user interface.

The view contained extra markup just to support the styling. The styling mixed the visual style, the overall page layout, and the layout of individual controls. This made the style hard to change. We fixed this by removing all style-related content, and restructuring the CSS so that the visual style, page layout, and individual controls are implemented in separate files.

Controller and view components contained hard-coded references. For example, a typical view component outputs a web page which contains references to the actions the user could take. The controller code that responds to those actions contains hard-coded references back to the views. Although the code was clearly separated, it was heavily coupled.

We fixed this by using a file to configure all the pages, and the references between view and controller components. This allows us to reconfigure the service to present different applications to different users. It also allows us to merge content from other sites, or expose meaningful subsets of our service for consumption by other sites.

We introduced themes, which collect together overrides for the standard user interface. The themes let us include the JQuery JavaScript library to provide more dynamic functionality, without modifying the underlying user interface code.

None of these changes of themselves achieve the Web 2.0 requirements, but they make it much easier to restyle the service, to build a richer and more dynamic user interface, to interact with other sites, and to give the user more control. Since making these changes we have created a number of customised versions of the service which have been well received.

Stepping back from all of this, the changes we have made have just been old-fashioned good practice: clear separation of responsibilities, decoupling, and removing hard-coding. Web 2.0 sounds new, but it requires the same disciplines I learnt programming COBOL 20 years ago.

I am still not sure what Web 2.0 means, but I know how to program it.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Umami

Like the taste umami, there are aspects of IT management which we all vaguely recognise but which we have not defined well enough to manage effectively.

Since the time of Aristotle, we have subdivided our sense of taste into different individual sensations.

Different traditions have divided taste differently. In the West, we have traditionally acknowledged four primary tastes: sweetness, bitterness, sourness and saltiness.

More recently, based on sharing ideas with other traditions and on better scientific understanding, a fifth primary taste has been acknowledged. In English, there is no word for this taste, which could be described as "savoury" or "meaty", so we have adopted the Japanese word umami. Acknowledging umami, and understanding the scientific basis for it, has enriched our understanding, and given us new insights into how to create new flavours in the food we eat.

What has this got to do with IT management?

IT management comes in rich and complex flavours, but we acknowledge only two primary tastes:

• Projects. These are significant lumps of defined change, characterised by objective and scope definition, planning, work assignment and tracking.
• Processes. These are repeatable, ongoing activities, characterised by defined processes, metrics, and continuous improvement.

There is another primary taste which, like umami, languishes unacknowledged.

This unknown taste flavours a lot of what we do. Here are some activities rich in it:

• IT review
• Software selection
• IT governance
• Information security
• Legacy system management
• Application portfolio management

These can be characterised as systematic investigation, analysis, recommendation, prioritisation and justification. In English, I have struggled to find a good word for this. Perhaps it is "evaluative management", but I will stick with "IT umami" for now.

IT umami is separate from projects because it is not a defined change.

Although it may look like an ongoing process, IT umami is not simply process management in the same way that, say, software change control is. IT umami does not deliver value directly itself, but through the information and recommendations that the activity delivers.

Although we recognise it vaguely, we do not have a well-defined sense of IT umami. We attempt to achieve it through projects and processes. Many projects include a lot of investigation, and yet anything that needs a lot of investigation is ill-defined and hard to manage as a project. Our service delivery processes are peppered with all sorts of reviews, but it is hard to find time for these because of the pressures of day-to-day delivery.

Acknowledging IT umami as a distinct primary contributor to IT management would hugely enrich how we manage. It would give us fresh insights and help us to develop new methods and new tools. It would reduce uncertainty in projects. It would give us better insight and justification for the reviews we carry out as part of service delivery.

Most importantly, properly acknowledging IT umami would help us achieve the things that fall outside our current project and process management. It would give us a clearer sense of direction. It would help us to control and secure IT properly. It would help us halt and reverse the decline into legacy.

But to start we need a better name than IT umami. Anybody?

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Business Process Management software

Business Process Management software would be much more useful if it was presented more conservatively.

My clients and contacts frequently suggest using business process management (BPM) software, but often I argue against them.

BPM software is used to build applications that automate business processes. A simple example is employee expenses, where an employee submits an expense claim that has to be authorised and then paid. BPM software goes much further than simple workflow, and can integrate IT systems, and view and control process activity.

BPM tools are used to build applications which involve passing information from person-to-person, and person-to-system. They are also good for some types of integration, such as managing incoming messages from other organisations.

Supporters of BPM software have a very ambitious vision. BPM software can transform your business. Managers can create and change processes by themselves, even in real time. You can use graphical tools to design and enforce business rules. You can integrate legacy systems at the click of a button. BPM is the glue that holds your business together.

I argue against this because it breaks a lot of IT good practice. For example:

• Clear system boundaries and responsibilities are vital for IT. BPM thinking deliberately breaks boundaries down and cuts across responsibilities, presenting processes as corporate glue. But in the long term, this means that nobody has clear ownership, and the BPM solution quickly becomes unloved legacy.
• Any business change needs to be carefully managed. There are very few situations where processes could realistically be changed at the click of a button.
• Business rules are an important asset that need to be verified and maintained through time. Visualisation of process flows is helpful, but extending this to a full graphical programming for business rules complicates long-term management. All non-trivial rules and data are best embodied in conventional code and databases.
• System integration requires a lot of discipline to avoid a management nightmare. Interfaces need to be particularly rigorous to work well with flexible BPM software. BPM software that just accesses databases belonging to other systems is unmanageable in the long term and completely inappropriate.

All applications require a mix of process flows, data storage, rules and interaction. When you design a system, you pick a base technology that meets the main requirements. If you have a management reporting system, you base it on database products. If you have a highly interactive system, you base it on web servers. If you have a lot of information flows, you base it on BPM software.

To me, BPM software is a good tool for building certain sorts of applications. But those applications must follow the same rules as any others - they have to have clear boundaries and responsibilities. Because they touch many areas, they need more, not less, focus on ownership, change control, rigorous development and long-term management.

I think that BPM software suffers because it is presented too ambitiously. I do not suppose many people believe the hype. But BPM lacks a more honest, simple, down-to-earth presentation that would help people like me accept it and design with it. If you promote BPM, perhaps a less ambitious vision would be more successful.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.