An Oracle APEX Methodology for Success
When I first started as a computer programmer in 1986 (yikes!), I was introduced to a system development methodology. At that time, I was working for CGI and they introduced the company-wide CGI development methodology. It was a set of deliverables and documents that were linked to each phase of a standard waterfall project development.
A development methodology? For what? Why?
It made sense to follow standards and processes since most large projects involved many people working toward a same goal. Without this methodology, it would have been difficult to ensure quality and deliver projects on time and on budget.
But what is methodology exactly? It’s a set of defined procedures, standards, norms, processes, and documents to organize and facilitate software development.
At Insum, when we started to work on bigger Oracle APEX projects requiring different types of resources like project managers, analysts, QA specialists, tech leads, and of course developers, it became more obvious that we had to develop our own APEX-specialized methodology.
One might think that since APEX is a development framework, there is no need for methodology. After all, it is a Rapid Application Development (RAD) tool. We want to develop faster while saving time and money. Surely having to follow procedures and spending time on quality will slow delivery down, right? Wrong!
The reality is there is a need for structure and methods aiming to facilitate and speed up the development cycle. Quality at every level is very important mostly because we build applications for clients who will inherit the maintenance after delivery.
![oracle apex dev ops]()
One of the goals of our development methodology is to catch most issues early on. We quickly learned that it is very costly to catch all the small issues in test, and even more costly in production. The cost of deployment in test, testing, opening issues, tracking them, and going back to dev is very high. For example, having good development standards and a technical lead that checks daily that methodology is being followed is one of the processes that helps achieving quality. As you can see, methodology is also about properly defining roles in a project team.
What does the methodology contain?
![insum development methodology]()
Our methodology is composed of different elements related to all aspects of an APEX development project.
In order to facilitate maintenance of our methodology, it is divided into several sections. This also allows us to customize every project and to pick and choose the appropriate approach and documents. Each project is unique and may need all or parts of the methodology depending on its size, the level of tests required, and whether it is Agile or Waterfall.
Here are the different sections:
0000 – General
In this section, we keep information related to the methodology specifically for the project. It contains document templates, a description of the methodology, some tips and tricks, and a list of the different tools that will be used.
0100 – Opportunity / Feasibility Study
For most projects, we start with an opportunity study. The main goal of this phase is to better understand the customer request at a high level. We have developed a project checklist so that we can ask specific questions to the client before starting the project. There might be some elements, like security or performance, that will have a major impact on project planning.
Over the years, we also developed a method to evaluate projects. This section contains an evaluation guide based on metrics for APEX software development.
0200 – Architecture
This section is about everything related to the different environments and technical architecture design. Among other things, it contains installation guides specific to the versions used on the project, security designs, and database standards.
0300 – Analysis
One of the major phases in a project is of course analysis. Here we define the approach and have template documents to create specifications for developers. It is also where we explain how to use our custom Agile development processes or our custom Waterfall processes. Analysts can use the guidelines in that section to follow predefined standards, and avoid having to do research or redefine proven methods. This is definitely helping with gaining productivity in our projects. Keep in mind that those processes are aligned with the rest of the team.
0400 – Development
For development, methodology is of course mainly related to norms and standards for every technology used i.e. Javascript, APEX and PL/SQL. We also have different checklists that developers can use as reminders, as well as custom advisors that automatically perform checks in the APEX metadata. There are also guidelines on code review.
0500 – Testing
Of course, testing is all about documents on test cases, test reports, and tests plans.
0600 – Implementation / Delivery
Once development is finished, we have to deliver the programs to the client. This section covers everything related to project delivery. From installation scripts to final acceptance documents and checklists.
0700 – Maintenance
Once a project is delivered, it goes into maintenance mode. This section is used to facilitate transfer to the maintenance group. It contains specific information for the maintenance group, as well as the delegation process to the maintenance group.
0800 – Project Management
Project management is related to every phase of any software development projects. This is where we document the project management approach. It contains dashboards that are communicated to clients and end-users, document templates, project schedules, project charts, meeting minutes, and many more documents to help managing projects.
0900 – Quality Assurance & Control
As with project management, Quality Assurance & Control is involved with every phase of a project. This is where we document our approach for tests, quality controls, and test automations. For every project, this is also where we define the metrics and the different testing tools that will be used.
1000 – Change Management & Training
This final section contains training curriculum, schedules, and material. It also documents the change management approach used to facilitate the end-user adoption of the delivered software.
![apex-methology-adoption]()
Methodology Adoption
As you can see, all participants on a project have to follow our methodology. We also encourage all our employees to provide feedback and suggestions. It is an ongoing effort from the whole project teams. This helps ensure that our methodology is adopted by everyone and is up to date with the latest trends.
One of our approaches to get our developers engaged with our methodology is that we answer feedback and keep everyone involved. To do so, some of our methodology documents are “living documents”. Google Docs allows developers to quickly suggest and improve the different defined norms and standards and everyone has visibility into their suggestions. We make sure that every new employee receives training on our methodology during their on-boarding process.
Moreover, we have created a committee that meets on a regular basis to discuss, improve, and assign different resources to maintain or create the documents.
Insum at your service
Implementing a methodology in a company is no easy task. It takes time, “buy-in” from both employees and management, and a tenacious team to help push them. The final result is certainly worth it and will improve your projects.
Based on our experience, we offer coaching for implementing your APEX methodology. We can integrate, adjust and share what took us many years to build. Not only this will allow you to learn best practices. It will also allow you to avoid making the same mistakes we did to get here and unveil the full potential of APEX. At Insum, we have a great team of very talented people and they are ready to help. Just let us know.
![See Our Services]()
The post An Oracle APEX Methodology for Success appeared first on Insum.
Nicht selten besteht in einer Geschäftsanwendung der Bedarf, mit Daten zu "spielen", Änderungen zu simulieren und verschiedene Versionen eines Datenbestandes zu verwalten. Solche Simulationen sind quasi eine "langlaufende Transaktion" - Änderungen (eine Simulation) werden zu einem späteren Zeitpunkt komplett angewendet oder zurückgerollt. Für kurze Transaktionszeiträume ist dieses Problem seit langem gelöst - die Oracle Datenbank beherrscht Transaktionen, die nötige Isolation, sowie COMMIT und ROLLBACK seit den frühen Anfängen. 
In business applications, there is often the requirement to "play" with data, to simulate business scenarios or to maintain multiple versions of data. Such scenarios require "long running transactions"; changes are being made to tables from within multiple database sessions, over a longer period of time even from different users. At the end, all changes of that transactions are being applied or rejected as a whole. 
