GeneXus USA performed a challenging critical development
project for PayPlus company that "even with GeneXus, but without Patterns would
have been difficult to implement", said Verónica Buitrón, GeneXus USA Vice
President.
PayPlus entered the PEO industry (Professional Employer
Organization), that is to say, the outsourcing of human resources management,
and dominated the market. PayPlus had part of the PEO industry on one
application and took over its main competitor, thus dominating the market almost
exclusively with its two applications. But, after some time, these two
applications, which were based on obsolete technology, became difficult to
maintain.
PayPlus, concerned with providing customers with not only
applications with good features but also with cutting-edge technology, was aware
of the fact that it needed to change before its market share changed. On the
other hand, having limited human and financial resources, they knew that they
had to find the way to leverage their resources by providing them with the tools
required to produce more with less. Thus, PayPlus adopted GeneXus as the tool
for the development of its new product suite.
In this context, PayPlus entrusted GeneXus USA with the
development of a Human Resources application that would account for people,
organizations and their interaction covering the areas of human resources,
payroll, benefits, etc. But it also included requirements which involved the
implementation of a temporary data base, among other challenges. GeneXus USA
Vice President, Verónica Buitrón, explains these challenges and how they were
faced using Patterns.
What were the challenges that determined the use
of Patterns?
The situation was not easy.
We had to build a very large and complex Human Resources web application for a
new customer and the entire application was required to look and behave in a
simple and consistent way for the users.
The customer requested that the application represented
the relationships between people and organizations in the past, present and
future, with a complete view of the database. The idea was not just to have
history tables, but rather that the entire database, tables and relationships
would move in time, which basically implied the implementation of a temporary
database. But since a relational database does not provide a good solution to
this problem, all the burden of complexity was transferred to programming.
Besides, since we were dealing with an outsourcing
business, the application was multi-company by definition, but in order to
minimize code maintenance, the idea was not to duplicate ordinary information,
but rather replace the common multi-company implementation with an indirect
relation between companies and codes, and implement a code group concept used by
the companies.
When we set up the plan for this project we found out that
three quarters of the project were repetitive tasks and that the implementation
of the temporary database was highly complex. I was concerned with not being
able to achieve the usual productivity we obtain with GeneXus in other types of
developments.
Luckily, just around that time, Nicolás Jodal visited us
in Chicago and talked to me about his new secret formula: the Pattern generator.
When I saw the Pattern generator demo, I knew I could find the key for this
project.
What concrete measurement could you offer of the
development productivity with Patterns in this project?
We created a mission critical application, where the Patterns
solved the whole complexity of the temporary database automatically and
maintained everything synchronized. And we did it in the same amount of time and
with the same budget set forth for the development of the application 1.0
version, but implementing many of the features thought and needed for version
2.0.
The application was generated using Java generator,
because it was required to support Unix and Windows, SQL/Server and Postgress
SQL. Almost 5000 objects were generated via Patterns and, for only six
transactions out of 300 nothing was generated with Patterns. Additionally, for
each transaction designed by the customer, Patterns generates an average of 30
related objects.
In other words, we will have a mission critical
application over 95% automatically generated by Patterns.
In what cases do you recommend using Patterns for
development?
In the case of large
business applications where we have repetitive behaviors; that is to say, in any
application that has a Business Pattern and enough size to make customizing your
own Pattern sensible. I think that the key factor is the size of the application
and the relation to the repetitive behavior. If there is plenty of repetition
and the application is large, then I use Patterns. This in the case of a
customized pattern that needs to be programmed, tested and adopted. An "as-is"
Pattern, like the ones provided by ARTech, I would use any time I can, why
reinvent the wheel?