The users are what make most business applications work. This is “the secret that keeps itself”. Even if there’s an in-house development and the users get to spend time with the designers and maybe do a little iterative prototyping, they only have a meager say in how the system will actually be delivered. And, to tell the truth, they don’t know how it’s going to work either.

But the nature of software development is that something gets delivered and everyone has to use it, and most of the time the newly delivered system doesn’t exactly fit. If it’s a package it’s really unlikely to fit. And either way, it’s too late to do anything. So the users that are saddled with the system get on and make it work.

Where it doesn’t fit, they’ll have to improvise and, naturally, they will use what they have to do it. What they have is email, spread sheets and word processors and calendars and other “office productivity aids”.

So they gather the data that the new system should have gathered and they process it in conjunction with the new system and they make it work. This happens a great deal, and it is one of the things that could lead to disillusion with SOA.

The Promise of SOA

Efforts to improve the flexibility and fitness for purpose of software applications have been proceeding in the software industry for decades and there have been many false starts. However, recent developments which began with general industry agreement on Web Services standards (XML, SOAP, WSDL, etc.) show a great deal of promise. They have culminated in the much vaunted Service Oriented Architecture (SOA) a software architecture that allows software components to be threaded together in a flexible manner to better serve and better reflect business processes.

The early implementations of SOA have proven that this approach is not only valid but improves the flexibility of business software. However, on its own, it has its limitations.

The problem it resolves is the problem of software reuse. With SOA it is possible to break business applications up into components and to create a framework within which those components can be reused. There can be no doubting the usefulness of this capability. To think of one common situation, I know three companies where the software that calculates customer discounts is duplicated in two separate applications; one that deals with sales rep’s commissions and the other that generates customer invoices. For good technical reasons it just wasn’t possible to use the same software in both situations. With SOA the reuse of software components becomes a reality and problems like this are solved.

Of course, SOA goes much further than this. It makes it possible to present every software capability as a service that anyone or any other software component can use. It gradually eliminates the old siloed applications of the past, replacing them with applications and components that can be integrated end-to-end. It’s complex to reconstitute a whole company using such architecture, but it’s possible given time.

Dealing With The Invisible Components

What SOA doesn’t cater for explicitly is those “secret components” that the users themselves have created with their “office productivity apps”. That’s not just because no-one is particularly aware of these user-generated add-ons. It’s also because PC office apps don’t have Web Services interfaces. But as it happens those apps usually do have .NET interfaces and all of the Microsoft ones definitely do. So it’s possible to get at them as components, as if they were Web Services.

This is what OpenSpan, a company that made it onto my companies to watch in 2008 list – realized. So it built the OpenSpan development environment to expose desktop components as if they were Web Services.

What this means is that if someone, say, is managing a spreadsheet and sending a few emails out to deal with anomalous situations, you can now patch their little “sub-system” directly into the official system. You can also link directly to any capability that they use which is web based. And you can do this for every user.

This doesn’t just allow you to “complete” existing applications, it enfranchises the user to participate more directly in the shaping of a system, contributing to productivity in two ways, by empowering the user and making the user more productive.

OpenSpan

Corporate developers have been fast to adopt OpenSpan; in fact the company has experienced over 400% growth in the past year and the high growth rate is likely to continue. However the use of the product has not been driven by it participating in SOA initiatives or Web Services initiatives. It has gathered users because it solves a big problem – no matter what the environment. It unites the presentation layer of all business systems in a controllable manner.

For some products, a demo is worth a thousand brochures and blog posts – and this is one. If you see an application being developed in OpenSpan by clipping in bits of Excel and services from web sites, you get it immediately. You just know it’s going make a difference to in-house development.