vnunet.com comment: Clive Longbottom on functional development for non-coders

Clive Longbottom, service director at Quocirca

As the age of the application enters its twilight hours, the new clarion call is for the provision of services that facilitate changing business processes.

Existing application vendors, such as Oracle and SAP, are scrambling to provide solutions built around service oriented architectures and web services, and niche vendors are touting their solutions as callable service functions for these environments.

And yet we still see hordes of code developers working away like medieval monks, crafting bespoke code that will give their masters that extra differentiation in the market to guarantee survival.

The problems with bespoke coding are well known and, in more cases than not, end up costing an organisation more than the benefits gained.

For example, code is rarely fully documented and new coders struggle to understand how the original coder put together some of the more clever (or, more often, just overly complex) parts of the code.

Bespoke code also tends to be less flexible; as organisations are increasingly driven by changes in market conditions, code needs to be able to respond to these forces. The trouble is that re-coding takes time, and retro-testing becomes a major problem.

A further problem is that many coders are one step removed (at least) from the business. Yes, they are great at their jobs, but the level of understanding of the actual business needs can be, let us say, loose.

The initial discussion takes place between the line of business representative and the IT department, a user specification document is agreed, and off goes the coder to create a first pass version.

This may take a while, and when it is put in front of the business person, the response is often more along the lines of 'It will do' rather than 'Wow, jus t what we wanted.'

Modern coding tools, such as Eclipse-based solutions and Visual Studio, do try to help with built-in or third-party tools to provide software code management, collaborative tools and so on.

But the fact remains that the speed of result, the quality of the code and the overall resulting functionality tends to be down to the coder, and that person may leave not long after their major work hits the business.

So what other approaches are there? The mythical 'only use an off-the-shelf solution' is always a possibility, but the constraints of such an approach rapidly become apparent as you search for the increasingly niche vendor which can provide you with that core piece of functionality that you would like, and then goes out of business just after you've implemented their completely unsupportable function.

You could fall back on historical frameworks and Case tools, such as Prince and SSADM, but although these improve project management and promote best practices, code is still underlying the whole thing.

How about a Model Driven Architecture? An MDA provide a means of going from business requirement to functional solution with the least number of steps and the least amount of coding, if any.

How does it all work? MDA has been developed by the Object Management Group as a means of abstracting the business needs from the technical areas for development.

Using accepted and adopted standards, such as the Unified Modelling Language, XML Metadata Interchange and a Common Warehouse Model, MDA provides a means of bringing development teams and the business closer together, and in enabling faster response times in coders being able to provide real solutions to business problems.

One company that has taken MDA to heart is Select Business Solutions. Coming from the mainframe environment, the company has expanded into Java via IBM WebSphere and Eclipse, as well as the .Net world via plug-ins to Visual Studio .Net.

Select Business Solutions' approach is to provide three levels of abstraction which, at a simple level, are as follows:

The Computation Independent Model (CIM)
This is the highest level of abstraction, enabling a business person to specify their requirements without any knowledge of the underlying technologies, including the network, servers, operating systems, application servers and applications.

Rather than just creating a user requirements document, this stage enables a full model to be built that becomes a core part of the documentation of the requirements, and provides the basis for the next stage.

The Platform Independent Model (PIM)
Here, a technology model is created that is still platform independent, but is aimed at demonstrating the technical steps that would be required to take the CIM and create a set of functional components that will facilitate the solution.

The Platform Specific Model (PSM)
This is where the models play together. The business model of the CIM, having been turned into the high-level technology service model of the PIM, now needs to be actually created as a set of code.

The PSM is the final precursor to this; a model which is focused on the technical items that will need to be created for a specific infrastructure.

A lot of this final stage can be done manually through taking the models and coding directly in your chosen tools set.

However, via the use of a Model Transformation Language, vendors are now looking at taking the UML and XML output from the MDA stages and automating the actual code creation.

Select Business Solutions does this, and you therefore end up with a complete, self contained system that contains all the designs, models, code and libraries which then enable code reuse as time goes on. It all sounds a bit smoke and mirrors, but it works.

While MDA is probably not the death of the hard-core coder, it will certainly help those organisations which have historically been dependent on bespoke coding to be more flexible and responsive to the market's needs.

As we move to a more functionally-oriented world and to using reusable services, responsiveness will be key. And MDA looks like a good way to keep ahead of the crowd.

www.quocirca.com