If only I could share these documents with xxxx

Why can't we just put together a simple database

How long did IT say it would be before they can even look at our requirements?

How often do we hear frustrated business people saying things like this. Worse, when business users try to buck the system and go it alone, they often get bogged down with a poorly maintained application that fails whenever it's needed most due to platform limitations or lack of planning. The fact of the matter is that designing a secure, reliable business application that is well documented and easily maintained is pretty difficult. Why else are IT departments so busy all the time.

Some solutions are already becoming commonplace to such problems. The proliferation of office application organisers that group standard office documents into folders and apply simple workflow rules to them is evidence of this. Such applications usually provide some additional facilities such as task lists and calendars which is fine for very simple, office based projects, but which fall way short of the wishes of today's business population lacking even basic cross referencing and indexing facilities without the use of expensive document management infrastructures.

Most people recognise that today's word processors and other office applications, whilst offering a superb range of facilities, offer far too much functionality for the majority of tasks. Frustrated users looking for a simple feature amongst the multilevel menu's and action button hierarchies will often simply give up. Often all that is really needed is the ability to perform basic text formatting or similar tasks, to a standard defined by the department or organisation.

IT departments are not avoiding the problem either. There are many applications portal solutions being deployed across corporate networks which provide excellent access to applications, but usually result in silos of information, stored in mutually incompatible formats, in disparate data stores. Why don't these applications talk to each other ?

Our modular web application architecture is an attempt to address this situation. We looked at a population of business users and asked them what frustrated them the most about the applications they use every day. With few exceptions they said that applications contain too much unneeded functionality, whilst being inflexible and not supporting the things they really wanted to do. Customising the applications could be done, but required higher skill levels and so needed the involvement of IT specialists, even to make the simplest of changes.

We cannot solve this problem all at once. Instead we are proposing a convergence of technologies. We are gradually moving away from a world of monolithic, local applications which do not communicate with each other or use and conform to organisational standards. We are instead moving towards a world of smart clients supporting a centralised application architecture. Such clients will offer just the feature set needed to perform the task at hand, automatically storing data into central repositories of information whilst remaining flexible enough to support the ever changing needs of the business. The problem is, what will those centralised applications of tomorrow look like. Furthermore how do we get from the monolithic applications we have today to this vision of the future.

In carrying out a number of needs analyses over recent years we have noticed that often the business requirement can be met with the simplest of functionality, for example a plain text based form fill results in data clean of unnecessary formatting codes, whilst still being presented in a range of aesthetically pleasing manners to suit the variety of outputs for which it is required. Such techniques are used in most content management tools used for publishing and maintaining corporate web and intranet sites.

Taking this a stage further one can determine any number of very simple functions ranging from the ability to send a text message to a colleagues mobile phone to the ability to generate a graph or other visual output to a common standard, from a changing data set on a periodic basis. Making these simple functions available is easily done with today's technologies. Web services, SOAP and .NET address this need at different levels, but these technologies are still very much in the developers realm, and do not lend themselves to simple deployment by business users. Worse they do not provide tools to record the relationships between the applications thus deployed, requiring developers to code data recording functionality at the application level.

Our system offers a range of simple functional blocks, linked together using a common interface, which provides for rapid end user deployment in response to need. Such a framework is not new, what is new is how it is implemented using diverse technologies from different parts of the industry, and the advantages the application framework offers in automated data gathering and relationship management.

A system is deployed in two stages. Initially a business analyst or other skilled person, carries out a needs analysis and defines the needed document types, processes and workflows. They define a number of application elemental templates, each of which stores predetermined data types according to context. Once the elements of the system are prepared they are linked together using portal technologies and assembled into a flexible framework reflecting the organisation of the task at hand. Note that none of this process requires programming or other IT intervention.

The second stage takes place dynamically during the life of the application. End users navigate around the application reading and creating documents, performing processes and tasks, and obtaining the results they require, whilst all the while under the hood the system is creating instances of the application elements in response to the users actions, recording key data and meta-data at every stage. This data collection process populates a cross reference data store which reflects the key dynamic data contained within the whole application.

This data gathering process offers two benefits, firstly in that key data need only be entered once, being selected from pre-populated lists wherever else it is used within the system, secondly the key data allows one to quickly locate all parts of the application which may be relevant to a particular context. This allows, for example, automated key term highlighting in documents and document summaries, which can provide automated cross linking to related documents and work areas.

Meanwhile end users are able to perform the task at hand, without distraction or having to search for a particular feature, since all the tools that are required have been organised into task oriented work areas during the templating process.

As and when the processes and tasks need to be changed, usually in response to changing business needs, the templates are easily amended or added to. Parts of the application which are no longer required are automatically archived and retired over a period of time avoiding a build up of redundant data whilst still keeping a record of the key data recorded in the cross reference in case it is ever needed in future.