There is, and deservedly, a lot to do about the next version of Oracle Application Express. APEX 4.0 is very much the way to take RAD development on the Oracle Database platform into the new decade and rightfully APEX is getting more and more popular. The thing I personally really start to like, while playing with the early adopters release of APEX 4.0, is the brand new ‘Team Development’ part of the APEX developers front-end.
It is now a while back that APEX development was merely for the small and not so critical applications, to be used by only a few people in an organization and developed by a hand full of developers who tended to know what they where doing. Nowadays APEX development has taken a leap. Very large, business critical web applications are being developed in this great Oracle tool. Smart guy’s who know the business work together with large teams of web developers and the development team consists of database specialists, user experience designers, PL/SQL code jammers, JavaScript editors and more and more and more.
These large teams need to be addressed when developing in Oracle Application Express, or any other tooling for that matter. The new version of APEX, 4.0, seems to do a better job at it. With the possibility for project managers, team leads and developers to edit and assign features, milestones, to dos, bugs and feedback into releases of any APEX application, this is done. Especially the potential benefits with the tools for release management, and therefore a great SCRUM approach to APEX projects, are to be considered.
It seems that APEX will become a great all in one project tool for delivering web applications.
{ 2 trackbacks }
{ 3 comments… read them below or add one }
Actually, I’ve been working with a large client for the last 18 months developing in Apex in a Scrum environment, and even in these pre-4.0 days it’s the perfect tool for Agile. I just think the team development aspects of 4.0 will just make it smoother.
Hi Paul,
Can you eleborate a bit on this? What are you developing? Is it an internal project for you own organization? What is the team size? How did you organize this projects? Do you have any lessons learned you can share?
Hi Frank,
I’m happy to oblige.
I’m a freelance IT consultant in the UK (specialising in Oracle DB and Apex development), and have been working with a multinational media/financial data provider for the last 18 months on a Scrum project to deliver a web based commodiity and energy market data application.
The team was made up of 3 on the backend (delivering database design/development, Apex apps, and web services), which includes the Scrum Master, and a further 3 to deliver the web front end (unfortunately not developed using Apex but an internal enterprise wide framework). I say ‘was’, as the team is now being replaced with a larger internal team of around 20 based in China and Thailand.
The project has been an ideal candidate for Scrum, as focus has been on delivering a number of data sets for different commodity or energy types each quarter to fit in with the enterprise release cycle.
The project initially started out as a traditional ‘waterfall’ project which after 12 months of design/development work had not delivered anything and that work was effectively scrapped. Within 3 months of a restart under Scrum with a new team the project had started to deliver and at 12 months had already delivered much more than was scoped for the original project. Of course, the business are extremely happy with the new approach!
Apex has been used primarily for data entry and ETL of a large number of disparate data sets, plus administration, etc. There is a large team based in Bangalore who use these applications.
Lessons learnt and random observations:
1. The business and team is spread across many locations (I myself tend to work remotely for the majority of the time), and in Scrum this tends to be frowned upon. Until recently we could get the core of the team together in London for all Sprint review and planning meetings, but with the core development team now in China/Thailand this is now impossible. So meetings take longer as communication is more difficult due to issues such as quality of comms, English as second language, etc. On the plus side everyone uses VOIP, IM, Webex sessions, etc, so the tools are there for collaboration.
2. Team size. 20 people is probably a lot for Scrum and from what I am seeing in the early days, there is a tendency to steer towards ‘waterfall’ approach, with more formal documentation and procedures being discussed. This is probably also a by-product of a new team who don’t come from a Scrum background being left to there own devices – ie the natural desire to veer towards the safety net of the familiar and away from the apparent ’safety net’ less Scrum!
2. As for Apex, where possible it has been sensible to work with as much ‘out of the box’ functionality as possible, but this is difficult for many of the complex data entry forms that are needed. As you are no doubt aware, tabular forms are not the best to work with and to do anything remotely useful involves much bespoking. This usually involves a lot of Javascript development, but some awareness of the issues up front would mean that generic Javascript can be written for reuse across many pages. Version 4.0 looks to address some of the issues such as validations and dynamic actions on tabular form items.
I must get back to work, but I am happy to expand on this if you want, maybe post an email address?
Paul.