Tag Archives MDA

Kees Kranenburg

A Legacy You Don’t Want to Inherit

No Comments »

Today many companies are still dogged by their so-called legacy applications. The past decades hundreds, if not thousands applications were developed with the use of nowadays outdated programming tools. The use of these outdated tools has resulted in poorly supported business processes.

In our rapidly changing world companies need to be able to adapt their business processes quickly. The main incentives for this being the integration of business processes, business process redesign because of mergers, and the selling-off of parts of companies. Most business processes have become accessible to customers and third-party businesses by means of web applications.

In case of legacy applications this has not been easy because the structure of most legacy applications isn’t compatible with today’s (internet and mobile) technology. Moreover, after decades of changes and fixes the internal workings of many legacy applications have become almost undecipherable and the usually outdated system documentation doesn’t alleviate this situation either.

To add to the problem suitably experienced personnel with sufficient knowledge of obsolete programming tools are hard to come by.  The last few years various specialist IT journals reported a shortage of qualified IT personnel. European Commissioner Neelie Kroes fears also a great scarcity of app developers in the European ICT market.

For outdated programming tools this problem is bigger still because the reservoir of suitable employees is not going to increase – which company is going to train its personnel in any other language than for example Java or C#? Moreover, many developers of legacy applications together with the employees who service these applications will retire in the not too distant future. It is a safe prediction that the shortage of employees capable of operating these outdated programming tools will become much bigger than currently is the case.

To solve these problem, we should automate the automation. In my blog ‘Wanted: The Software Industry Architect’, I plea for the appliance of Model Driven Development (MDD) practices to increase software development productivity. Moreover, the same MDD concepts and practices can be used to transform the legacy code to a service-oriented architecture to be deployed in a PaaS / SaaS platform.

To summarize the approach: The legacy application is analyzed and any obsolete code is eliminated. Next the more interesting parts of the application such as data entities and business logic are identified and transformed to a more abstract higher level model. This model is optimized which means that new functionality is added and the model is tailored to make the application suitable for deployment in the Cloud. The models are documented using state-of-the-art tools in a PaaS environment. It is this model that, on the basis of MDD principles, is used to newly generate and transfer the application to a Microsoft Azure platform or Java Cloud platform.

Maybe this all sounds very utopian to you – deduce high level models from legacy software applications and generate from these models new Cloud applications. So, it will be worthwhile to follow the research project ARTIST in which a consortium of ten leading academic and industry organizations are exploring the appliance of MDD for legacy transformation to the Cloud.

Kees Kranenburg

Model Driven Offshore

2 Comments »

Model Driven Architecture (MDA) gave software modeling and software generation a new impetus. Developed by the Object Management Group, MDA succeeded in defining a framework for software engineering. To many of us, MDA is a familiar concept. First, a high-level system model is developed. Next, system requirements are modeled. Finally, with the system requirements acting as a base, the software is generated, rendering a complete and working application.

However, the MDA model is considered to be somewhat academic. This is why software engineers prefer to talk about Model Driven Development. Applying a model-driven approach can drastically enhance the whole software engineering cycle, from analysis through to maintenance. The application generator, for example, is already used during the system specification phase enabling working system versions to serve as prototypes. Designing and programming have been replaced by modeling and generating. Therefore, the software engineer no longer has to deal with cumbersome technical platform details, resulting in an improved productivity and improved quality, and a less complex application maintenance process.

One of the shortcomings of Model Driven Development is generating the business logic. Tools can nowadays generate software based upon data structure models, i.e. using Unified Modeling Language. They generate retrieve, update, delete and query functions, including key constraints, referential integrity, mandatory attributes rules, some validation rules, enforced update and delete constraints, browse synchronization between parent and child relations, and a default user interface. But these tools are deficient in handling the business logic. One of the reasons for this is the lack of an international standard for defining business rules. This implies that the business rules specifications have to be coded manually.

Business logic is usually specified in Word documents, and coding them is done by hand in, for example, C# or Java. As we know, programming in C# or Java is very labor-intensive and expensive when done in Europe. However, when something is labor-intensive, we prefer to source these activities in low-cost offshore delivery centers. This is how the Model Driven Offshore concept was born. It combines the benefits of Model Driven Development with the benefits of off shoring.

Model Driven Offshore – a pun or the near future?

Kees Kranenburg

Model Driven Offshore

No Comments »

Eén van de tekortkomingen van Model Driven Architecture/Development is de business logica.
Het modelleren van structuur gaat goed in MDA. En op basis van deze structuurmodellen zijn ontwikkelomgevingen in staat om werkende applicaties te genereren voorzien van de ‘triviale’ functionaliteit: retrieve, update, delete en query functies, aangevuld met de bewaking van o.a. key constraints, waardebeperkingen, referentiele integriteit en de ‘update & delete’ regels.
Maar waar het vaak aan schort is het genereren van de business logica (de ‘business rules’). Dat is ook lastig voor de tool leveranciers bij gebrek aan een duidelijke standaard voor het specificeren van business logica. In het verleden zijn hiervoor wel methoden ontwikkeld, o.a. INFOMOD op basis van predicaten logica. Maar het is nooit echt doorgebroken. Hoeveel van onze software engineers in Nederland zijn bekend met OCL?
En als u zich nu afvraagt: ‘Wat is OCL?’ dan is mijn statement bewezen: er is geen eenduidige standaard.

Dus wat doen we bij gebrek aan beter: we specificeren de business logica in Word dcoumenten en programmeren deze handmatig in C# of Java. En dat gaat natuurlijk ten koste van de productiviteit en is arbeidsintensief. Ah, maar als iets arbeidsintensief is, dan doen we dat bij voorkeur in India.

Model Driven Offshore: een woordspeling of nabije toekomst?

Kees Kranenburg

Echte mannen maken geen modellen

No Comments »

Het zal je wel eens zijn opgevallen dat onze ICT-industrie enigszins hype-gevoelig is. Tal van nieuwe concepten en technologieën worden ons dagelijks voorgeschoteld. Congressen en seminars spelen er op in en wordt je wekelijks bestookt met aanprijzingen van leveranciers over nieuwe concepten, technologie en tools.

Toch is ICT-personeel zelf een conservatief volkje – zeker wanneer het gaat om het veranderen van de eigen werkwijze. We evangeliseren graag dat business en gebruikers aan de gang moeten gaan met de nieuwste concepten en hun oude, ingesleten manier van werken overboord moeten gooien, maar zelf zijn we niet zo veranderingsgezind.

Die weerstand tegen veranderen kom ik regelmatig tegen bij Model Driven Architecture. Het nieuwe van MDA is er nu wel vanaf. Dus de vrees voor het onbekende mag er niet meer zijn.
En een ieder die de ontwikkelingen in zijn vakliteratuur bijhoudt kan onderhand toch weten dat MDA volwassen is. Er zijn goede en beschreven referenties die een aantoonbare productiviteitswinst laten zien.
Of is het dan de graad van automatisering waardoor men bang is dat het werk wordt weg geautomatiseerd? Neen, zover zijn we nog niet met MDA.

Waar komt dat dan toch vandaan, die weestand tegen Model Driven Architecture?

Kees Kranenburg

Model Driven Architecture (1)

No Comments »

In de beginjaren ’90 verschijnen er geautomatiseerde gereedschappen op de markt die delen van het ontwikkeltraject automatiseren: generatoren die aan de hand van modellen werkende applicaties genereren. Een model dat de dingen uit de werkelijkheid, hun kenmerken en gedrag beschrijft, diende hiervoor als uitgangspunt. Met het verschijnen van dit soort gereedschappen werden ook iteratieve ontwikkelmethoden als Rapid Application Development in de praktijk toepasbaar. Door het modelleren van de bedrijfswerkelijkheid en het genereren van applicaties uit specificatiemodellen werd het mogelijk om specificaties met werkende systemen terug te koppelen aan gebruikers en werd systeemontwikkeling inderdaad versneld.

Vanuit het oogpunt van systeemontwikkeling was het teleurstellend om te zien dat de opkomst van het Internet en de daaraan gerelateerde HTML en Java een forse stap terug betekende. De productiviteit van systeemontwikkeling op het Java/J2EE platform was bij haar introductie enkele factoren lager ten opzichte van de gangbare 4GL-applicatiegeneratoren. Daar tegenover staat dat Java wel voordelen bood ten opzichte van de 4GL-talen: schaalbaarheid en portabiliteit.

Maar gelukkig, de geschiedenis herhaalt zich. Leveranciers van geautomatiseerde gereedschappen brengen nu ontwikkelomgevingen op de markt die de technologische complexiteit van het software platform voor de ontwikkelaars afschermen en die aan de hand van modellen code genereren voor het .NET en het J2EE platform. Een model dat de dingen uit de werkelijkheid, hun kenmerken en gedrag beschrijft, dient hiervoor als uitgangspunt.

Nu noemen we dat een architectuur …