At the APEX Connect in Berlin, I had the chance to present the vision and best practices for nearshoring development in the context of APEX. Since 2004 we have been doing nearshoring development on different JAVA technologies and ORACLE frameworks, mostly on ORACLE ADF, APEX, MAF, JET and WebCenter stack. What we realized is that we are actually using different tools for solving more or less problems from the same area: CRUD applications. Even if we are using different tools to build them, there are a lot of similarities between the applications. Therefore, we have identified some good practices and guidelines for our customers in order to allow them to be more scalable with their development team. By doing this, we develop our Elastic Team, which means that we provide experts for Oracle Web Development instead of a specific framework, in order to help our customers with delivering their projects faster to the business users.


The presentation shows how to mitigate some additional efforts and costs that could come from the nearshoring approach, such as language and communication, quality, security and additional customer effort. The customers, who think of having a nearshoring development partner, need to consider some challenges that might appear regarding organization, team and technical matters.


The first commercial approach is usually to reduce the backlog for the current development process. The nearshoring team will develop fixed priced user stories. Since 2004 we have seen customers doing almost the same mistakes over and over again. One mistake is that they lock themselves by using their local language during the development process. You should always use the English language for developing projects. For sure meetings and requirements need to be done in the local language because that is the most effective way for communication. For this precise matter, we provide people which speak the German language due to the fact that we are a strong Oracle partner in Germany. Customers must select the partners that can deliver nearshoring development because those teams can have almost the same working hours as the customer and they probably are of the same culture and could join the customer’s office in a short time. Security is another important aspect of the nearshoring development, as a customer you need to trust your partner. In some cases this can be achieved by some accreditations, such as a NATO classified certificate or by ensuring the right security policies for accessing the customer infrastructure. In our experience this could be easily mitigated by having a golden image for the developers, which reflects the customer’s environment and by working with test data. So if you find yourself as a customer in such a situation where you can deliver a golden image and test data, then you are ready for nearshoring development.


We strongly believe that the agile methodologies can also be adapted for the nearshoring development. In the presentation I will provide some ideas on how to do this, which I called Scrum 2.0, the enablement for nearshoring development.


The following image describes more or less the team organization and organization in general. The most important thing is that we can establish a bridge between the customer and the nearshoring team. Here virtual7 can provide an onsite manager that handles the discussion with the customer and intensively communicate with an offsite manager that leads the nearshoring team. The two other factors like having a golden image and continuously delivering demos to the customer are also extremely important. If you have those, then you are enabled for nearshoring and you are enabled to scale your development team and become “elastic” as well.

The last topic, which is tackled in my presentation is regarding technical challenges for the nearshoring development in the context of APEX. You already know that APEX development is very centralized because the development is done directly in the Oracle Database through a Web front end. Even if you have a golden image where different teams could install the APEX application, it would be very difficult to synchronize the work. Sure, you can export the APEX application, which will generate a big SQL file. In this big SQL file you will get lost when multiple teams keep changing that file. The conflict management in this case is extremely difficult. Furthermore, the static files, like CSS and JavaScript, are encoded in the exported file, making impossible to see what was changed.


So we have to find a way to export the APEX application in a much granular form. For sure, APEX provides export for resources, like workspace, application, themes, plugins, static files, pages and so on. We identified the most common resources, which get modified regularly and we have developed the necessary tools to export those resources by simply executing an ANT task.


Once you have this in place, then the conflict management is much easier and you can get out of the centralized nature of APEX to a distributed source management, where you will be using tools like GIT. Furthermore, this will enable you to include code approvals, quality checks and security checks on the exported resources.


At the end of the presentation I show a demo on how to export an APEX application to such a structure that can be synchronized with GIT to the Oracle Developer Cloud, which has a configured build that will watch the ‘master’ branch and trigger a full or incremental deployment to the Oracle Database Cloud, where I have an APEX instance established.

And here is the presentation document.