A common language

The ability to solve business problems rapidly while also gaining flexibility and versatility - and the resultant impact on revenue streams - is driving the widespread adoption of agile and model-driven development.

Communication of business rules and processes has long since been identified as one of the main problems inhibiting IT and business unity.

Hardy Jonck heads up DVT's Mendix business unit.

Traditionally, business specialists driven by their industry knowledge as well as their company's bottom line results are focused on thinking in business-specific terms. For example, a retail business expert will describe a feature of a program in terms of accounting, retail or supply chain values and principles.

IT experts programming the system will understand the needs that the business expresses at the time, but will focus their energy on system properties such as efficient code re-use, superior data storage and retrieval and class abstraction. They will translate those business needs into optimised and programmable business rules.

Since each is focused on their own domain language and values, communication between business operations and their IT translation to business rules, combined with infrastructure practices, often leads to overly complex IT solutions and long overdue IT projects.

Domain experts might originally define the system's business rules based on an in-place business process, but when the process does eventually evolve, the business rules programmed into the system (in code) aren't easily communicated back to the domain experts. They are unlikely to understand either code or the often out-of-date and abandoned specifications.

This makes the change in process lengthier and more complex. It's a complexity that increases over time as people who originally created and implemented the process in the system itself move on. The time taken to organise the complexity and return the existing business rules to business then takes longer than expected, creating a tension and polarising departments.

The result is that IT systems hold businesses back (especially where an ad hoc business approach is adopted within an organisation) when they should instead be creating a platform that business can leverage to change and grow exponentially.

Communication of business rules and processes has long since been identified as one of the main problems inhibiting IT and business unity. Organisations like the OMI Group have focused on both the unified modelling language and the business process modelling notation to overcome this communication problem, as they create common and clear languages that both parties can conform to and use to communicate.

This allows business resources to focus on system behaviour needs, better describe their problems, and be contextually creative in coming up with ideas that meet their specific bottom line demands. After that, they can effectively communicate those needs to IT through the created models.

Since the realisation that a modelling approach to systems development creates common ground, innovators have started to combine a model approach with usable functionality. Early adopters created systems that produced 'compilable' programming code from the initially developed models in a variety of programming languages, which served as a project kick-starter - a process called Model Driven Architecture (MDA).

However, these modelling tools were limited, because code that had later been changed by developers could no longer be reliably reverse-engineered back into the modelling tool. From the business perspective, what started off as a great communication tool would ultimately fall prey to the traditional problems of pre-MDA times.

Since then, innovators have combined technology-specific best practices with MDA tools to create a model-driven development approach that allows domain experts to develop and deploy entire functional systems through modelling tools, thus removing the impediments created through code reverse engineering limitations. This allows business to constantly remain on the same communication platform as IT through the use of models.

Additionally, since components that produce the functional code use technology best practices, the quality of the solution modelled often increases - especially over the long-term. When more complex solutions need to be added to the existing model, pluggable components can be programmed by developers, allowing them to focus specifically on complex individual problems instead of the spreading of specialised skills across the entire problem space. The components are displayed and used on the model just as any other activity would be.

Results show more successful project implementations and a greater return on investment for business and IT.

The move hasn't come without its challenges. While early adopters are experiencing successes, much needs to be done to integrate the highly-valued principles of software development with this new model-driven development approach.

Test-driven development, for example, typically implemented through unit testing, has to be redefined in an MDA space. So too do software engineering practices such as Scrum (a form of agile project management) and Extreme Programming. These have worked well to deliver framework-based object-oriented IT systems in the past, but will have to evolve to deal with the rapid pace of development that new MDA tools are introducing.

Because attitude and organisational culture play such key roles in any business, MDA will never be a silver bullet. However, the results will speak for themselves, as this new approach yields a greater level of communication between these historically conflicting departments.