ADF skills are increasingly precious these days. With so many companies adopting this technology for their database applications, managers starting such projects find themselves suddenly busy hunting for the brightest ADF developers they can find. Next on the challenges list: dealing with complex architectures while, as usual, being pressed by the business to deliver the new software by the following day, if possible. Looking back at my past ADF projects, here are some of the main challenges and corresponding solutions:
Can existing development teams successfully transition to ADF and carry on such projects?
It is challenging, but doable, of course! We start by adding some experienced ADF&PL/SQL developers and optimizing the initial project processes. This is because most development teams I get to work with are composed of EITHER experienced database OR Java developers. Hybrid experts in both PL/SQL and Java are rare. Yet, when developing ADF applications for an Oracle database, having an overview of both parts of the application – the ADF and the database – is important. That does not mean that all the team members have to become superhumans – the Java ones to excel at PL/SQL and the database guys to become Java gurus overnight. We have learnt that instead of hiring huge teams and lots of experts for the duration of the project, we can accomplish more with small motivated teams, and streamlined project processes.
How do we streamline these processes at PITSS? We eliminate all the unnecessary steps so that we can focus on the rest. We use, for instance, for migration projects, a PITSS.CON routine that identifies dead application areas, named Dead Code Analysis, so we can simply avoid losing time on such dead code and start working on the really important stuff. Moreover, when modernizing old Forms applications and re-writing them in ADF, we always find a lot of intelligence in the old Forms that we can extract and reuse. The automated migration routines can be customized and used regardless of the complexity of the Forms application, as there are always areas that can be reused, such as code artefacts or even screen layouts. This not only saves time and allows fewer developers to accomplish more, but it also ensures that the routine work is done by the routines, and the more human (=interesting) work is done by the humans.
Where to start when designing the optimal ADF architecture? Of course, with the analysis! But wait – what to analyse first?
The architectural options for ADF may seem puzzling, at the beginning. The fact that ADF offers so much freedom in combining technologies can also keep architects and teams busy debating for as much time as allocated. Such debates are important, but too often they end up consuming too much of the precious project time and can demotivate the team. Not to mention what happens when the wrong architecture is chosen. The solution? First, undertake a thorough application analysis, such as how much code and artefacts are in the DB, which database structure is in place, and how many and what type of concurrent applications are and will be accessing the same tables or stored code. In particular, when building ADF applications on top of older database applications, such an application analysis can pinpoint the most important aspects to consider for narrowing down the architectural choices, saving unnecessary debating time and, ultimately, helping the team make the right decision.
Again, how do we tackle this challenge? We use PITSS.CON to give a deep analysis of all the layers of an application, including Forms, Reports, database, external scripts, etc. The reports identify the eventual areas of suboptimal performance or issues. In most situations, the information we take from these reports helps the team easily design the optimal architecture.
Finally the classical challenge: How to stay on track and within the time budget?
Finding some clear, easy-to-apply metrics for the ADF work is crucial. However, the following may be the biggest danger – as ADF is probably new land for a part of the team, estimating and measuring work are difficult. We’ve heard of ADF projects exceeding the initial planning by 2 or 3 times. This can be avoided by always basing time estimations on clear data, such as developing a prototype and then extrapolating the development speed.
Our example: For Forms to ADF projects, we have designed a detailed assessment report estimating the migration effort. It can be calibrated for a particular team depending on its experience in ADF and its specific development processes, allowing us and our customers to know exactly what is required for a new application. It not only saves our clients from unpleasant surprises, but is used for various other purposes, such as detailed planning of project milestones, gradual increase of development speed for new team members, project statistics or management reports etc.
There are, for sure, various other challenges in a software project, but these seem to have the biggest impact in our ADF projects. Each time our team uses a type of report or metric for a project, that know-how is also included as a feature in PITSS.CON, so that it is available for our customers and our own future projects, too, in a way that is as easy, quick and intuitive as possible. We have been developing such features and then applying and perfecting them since ADF was in its childhood. They have helped entire development teams make a successful transition to ADF, increasing the quality and speed of the ADF development and allowing the project work to be a rewarding experience, free of unnecessary drama.
