Archives for posts with tag: productivity

Last week Zest Application Professionals, partner of OutSystems, participated in myNextStep Benelux 2013, a user conference that took place in Chassé Theater in Breda. Read on to find out what I took away from the event.

Innovation

1Ktlo_-_problem_sources2

You may already know that the biggest value of productivity platforms like OutSystems lies rather in reduction of TCO than in savings on the initial application development (although depending on the application, the platform shines there as well). Mike Jones, Chief Evangelist at OutSystems, opened the event with a presentation covering this value, but from a fresh perspective – innovation. This perspective matters because innovation is often associated with a company’s capability to adapt to business demand for change.

The presenter argued that innovating and differentiating applications (in other words applications that are specific to the business and experimental in nature) are in fact the right applications for the productivity platform. More importantly, Mike continued that should packages for these applications be traditionally built, customised or bought, their high TCO over years would eventually deplete budgets allocated for development and maintenance of the application portfolio, thus leaving no room for further innovation.

The core cause for inflated TCO is on one hand – rigidity of commodity applications and on the other – inherently high change frequency of innovation and differentiating processes. The presenter pointed that OutSystems platform enables building for change and thus drives TCO down.

Mike concluded that OutSystems allows businesses to fund innovation though reduced development and maintenance costs.

Usability

43

Usability is the new critical non-functional requirement that is in focus of OutSystems’ R&D. Paulo Rosado, the company’s CEO explained why:

  • Clients no longer compare applications to SAP
  • Tech companies such as Facebook, Zynga, Square are acquiring design studios
  • Business satisfaction is top when delivering a high usability application.

An interesting side effect is that building high usability applications would require more frequent application reviews by end users. In effect, the (less agile) projects may need to adapt to the higher frequency of interaction with business and the need to develop for change would be even more emphasized.

How this awareness will shape the platform is still unclear at this time. Perhaps more information will be revealed at the upcoming OutSystems conference in Lissabon on May 7 & 8, 2013.

Nevertheless, usability of applications can be improved already now with the today’s platform. In a followup track OutSystems shared some design principles and showed how to apply them on the current platform. The resulting screens looked promising – certainly more clean and modern than what I am used to see typically built.

Enterprise Architecture

Built for change is an essential capability of “agile” applications. Naturally, such capability does not come automatically, even if the development platform itself is helping developers. At the event OutSystems shared their best practices with respect to modularity and composition of applications.

4

Given that productivity platforms enable even people without IT background to develope applications, I am glad that this subject receives attention from OutSystem. I hope that they would not stop there. Personally I would love to see the Data DSL become more expressive and Data modelling evolve to Domain modelling (but this is a subject of another post).


If you attended the event too, what topics did you take away? What do you think of the platform? And how should the platform further evolve? 

Images are taken from the event’s presentations.

Due to increasing use of domain specific languages (DSLs), declarative style of modeling is quetly spreading among users of MDE tools. Indeed, it is easy to find examples of declarative DSLs, e.g. at DSM Forums or this blog. There is however a group of users, among which the delarative style of modeling has not managed to spread – transformation developers. I am not sure if it has something todo with the group itself or with the fact that the majority of today’s transformation definition languages (TDL) are still more imperative in style (I am aware of QVT Relations and ATL, but these are rather exceptions than the norm).

There are quite a few good reasons why one would consider using a declarative language for transformation definition: reduction of information content in transformation definitions (and hence higher productivity of transformation developers), more agile DSL evolution, transformation definitions as models, higher compatibility with parallel computing, etc..

Today I would like to share some practical results that illustrate reduction of information content due to use of a declarative language.

CHART vs. Java

The following examples are kindly provided by Maarten de Mol and Arend Rensink from University of Twente. In CHARTER project, they are working on certifiable transformation technology for development of safety-critical embedded systems.

Before proceeding to the examples, here are a few relevant highlights of their technology:

  • Partially declarative transformation definition language (CHART): based on graph transformation and intended to be useable by Java programmers.
  • Transformation compiler (RDT): given a transformation definition written in CHART, generates its executable implementation in Java. The produced code runs against and transforms user provided data.

Figures 1 and 2 present transformation rules findRich and addPicture respectively. Each figure shows its rule written both in CHART and Java. The important Java methods are match() and update(), which are the translations of the similarly named blocks in CHARTER rules. 

Figure_1a_-_findrich_chartFigure_1b_-_findrich_java

Figure 1: Rule findRich written in CHART (a) and Java (b)

In Figure 1a, a match block counts 10 LOC against 41 LOC in Java (Figure 1b), which constitutes a reduction of information content by 75%.

Figure_2a_-_addpicture_chartFigure_2b_-_addpicture_java

Figure 2: Rule addPicture written in CHART (a) and Java (b)

In Figure 2a, an update block counts 12 LOC against 65 LOC in Java, an 80% reduction.

Both examples show significant reduction of information content in CHART rules. The reduction is even stronger if one takes into account that Java implementations also have to address technical concerns, which do not exist in CHART rules. In this case reduction is 92% (13 LOC vs. 160 LOC for rule findRich).

In experence of another CHARTER partner, who evaluates CHART/RDT in practice, a CHART transformation definition counted 1024 lines of code against 8000 in Java, an 87% reduction of information content [1]. Author’s own industrial experiences elsewhere with AToM3 GG rules (declarative) and QVT Operational (imperative) agree with the above results as well.

While exact reduction numbers are certainly arguable, the overal trend in the above experiences is that use of a declarative TDL can result in dramatic reduction of information content and manyfold increase of development productivity.

Conclusion

Despite industrial successes of MDE (which are often hidden), it is my experience that model-driven methods have hard times keeping up as organizations evolve. One factor behing this lag is slow speed of transformation development. Practical industrial experiences such as above, show that declarative languages have potential to significantly improve agility of transformation development.

What are your experiences with declarative TDLs and agile language development? Can you share concrete examples or provide references to declarative TDLs?

References

[1] de Mol, M.J. and Rensink, A. and Hunt, J.J. (2012) Graph Transforming Java Data. In: Proceedings of the 15th International Conference on Fundamental Approaches to Software Engineering (FASE 2012), 26-29 Mar 2012, Talinn, Estonia. Lecture Notes in Computer Science. Springer Verlag.