Home grown applications rarely leave anyone satisfied. Prone to busting budgets and deadlines, internal developments often leave IT feeling rushed and compromised, and business users frustrated that their requirements have not been met.

The notoriously wide ‘semantic gap' that divides IT and business is normally at the root of this problem. Developers, for very good reasons, are rarely fluent in the jargon of their business counterparts. For the same good reasons, business people are equally unlikely to express themselves in the formal, precise terms that developers use to define IT requirements.

The deceptively simple solution to this is to bridge the gap, and give business people the tools to develop their own applications. "Users can innovate because they're working at the coal face and trying to create a real solution to problems they know better than anyone," says one banking industry CIO.

This is a view that makes sense on an intuitive level, and one which is gaining ground as new technologies emerge that appear to make it a practical proposition.

At a strategic level, for instance, there are the trends towards business process management (BPM), service-oriented architecture (SOA) and web services.

Together, says Pierre Haren, chief executive officer of business rules technology vendor Ilog, these trends promise to separate business logic from the complex software infrastructure that currently makes it so inaccessible to users.

They will, says Haren, allow IT professionals to carry on managing the nuts and bolts that support business processes, whilst business people get on with the job of defining what they do.

The impact this will have on the flexibility and responsiveness of business is potentially profound. "Incremental change will be almost totally put into the hands of the business users," he says, "so you will have a lot of corporations whose IT will change every day – whereas today corporate IT changes every six months."

This is an extremely appealing vision, but it can only be realised when the IT department has had time to build the solid foundations – the nuts and bolts – that are needed to prevent user-driven systems integration turning into user-driven disintegration.

But this cannot happen overnight and, in the meantime, even technically naïve users are losing patience and striking out on do-it-yourself projects of their own.

For many years, they have had to make use of the tools available on their desktops, such as spreadsheets or local databases, to satisfy their needs. In the 1980s, programs like Lotus 1-2-3 and Multiplan gave users the ability to build relatively complex applications. Today, Microsoft Office tools like Excel and Access are common outlets for technical creativity.

Simpler and more sophisticated ways are emerging for individuals to pull together their own programs. Of these, hosted applications have the highest profile. Because they do not ‘touch' internal IT systems, access to web-based applications can be purchased for a relatively small up-front cost, then tailored to teams' needs – all completely unnoticed by IT.

"Our strategy a few years ago was to sneak in under the radar screen – find some rogue department head or sales guy that had a real pain point," says Jim Steele, president of application service provider (ASP) Salesforce.com. "They wanted to get up-and-running fast and didn't want to go through the corporate bureaucracy or raise a red flag with the IT department. The next thing you know, the company is looking around and saying ‘holy moley, we have the adoption of this tool that nobody from IT ever had any involvement with'."

These days, says Steele, Salesforce.com's potential users are more likely to consult with IT before signing up for his company's service. But this is not necessarily true of all Salesforce.com customers or, indeed, of customers of other, smaller ASPs whose hunger for market share may give them fewer qualms when selling services behind the back of corporate IT managers.

This may not matter in the short term, but in time, says Quocirca analyst Clive Longbottom, it may become an obstacle to more strategic integration goals, such as the creation of an SOA foundation.

Potentially even greater long-term problems can be created by users who, frustrated by the often narrowly-defined services offered by ASPs, go a step further down the DIY road, and opt to write their own applications.

With new vendors such as JotSpot and RealFlair (see box) claiming to enable the development of applications from scratch, without the need for any coding knowledge, this idea no longer seems far-fetched. Such tools will expand the already widespread DIY phenomenon.

Estimates suggest there are between two and 25 times as many individuals writing their own software as professional programmers. "If someone is looking at using a big financial package on a mainframe that takes two minutes to come back with a response, or the alternative is making their own spreadsheet with pivot tables from all their information on a desktop, they will do the latter," says Longbottom.

Nonetheless, DIY applications make IT directors nervous. Unsupervised developments can raise problems in security, support, regulatory compliance and integration – all which can have significant cost implications.

Indeed, according to Dave Martin, a principal security consultant with LogicaCMG, DIY programming is "the biggest security bugbear of all time".

Microsoft Access, for example, was "never designed for multi-user security", he says, but one of his customers – a bank – had over 40 of its 200 applications written in the PC database application.

The healthcare sector is particularly plagued by this problem. Consultants start to build their own patient databases, which are then taken up by others until "eventually the department relies upon an application that has been knocked together by an IT amateur who has taken absolutely no consideration of security, back-ups or data validation," says Martin.

DIY solutions can put a finely tuned IT strategy at risk for only short-term, limited gains. One person's productivity tool can inadvertently impair the performance of others. "Sometimes you get them fit for a purpose and they meet the business need," says Guy Lidbetter of systems integrators Atos Origin. "But there is also the risk that you start creating a lot of cottage industries that are non-core to the business. You end up with applications with lives of their own but nobody really owns them."

This can create complications with auditors, who are likely to frown upon information maintained outside the heavily regulated IT framework. But complete bans on DIY applications are tricky to enforce and not universally recommended. "Little blinding flashes of inspiration can put you ahead of the competition," says Quocirca's Longbottom. Some companies are adopting a ‘licensed tinkering' policy that allows users to do it themselves as long as they also remember to document their development and store important data in an easily accessible, standardised database.

If an organisation finds itself infested by a particularly large number of DIY applications, that should tell it something about the success (or otherwise) of its authorised IT projects. People only turn to DIY as a last resort, says Atos Origin's Lidbetter: "In general the industry needs to find a better way to connect the business requirements and the business user – and that doesn't necessarily mean letting them develop [software] themselves."