A long-time Oracle tools analyst and consultant recently published a backhanded compliment to APEX. In a blog post, he said:
"Among Oracle tools, APEX has been the old-school, monolithic holdout, together with Oracle Forms. Much modern application architecture is based on REST web services, and other Oracle tools like JET, VBCS and ADF have long had the ability to consume and/or produce REST web services."Before I go on, let's correct a few points. Firstly, APEX has long had the ability to produce REST and consume both REST and SOAP Web Services for years. I know, because I authored the first support for SOAP Web Services for APEX in 2002. Also, you can't produce REST with JET. It's a toolkit. There is no back-end data store, no ability to "host" a REST Service. The JET product managers themselves use RESTful Services from apex.oracle.com when doing their demonstrations of JET! Lastly, Oracle JET was released in October 2015 and ABCS (now VBCS) was first announced in June 2015. If that constitutes "long had the ability", then so be it.
So back to the statements - old-school, monolithic holdout. Not modern. In response to Morten Braten (a luminary in the APEX community), this consultant replied that "monoliths are rarely a good choice in an enterprise setting." In response to my request for a definition of "enterprise setting", the consultant kindly authored a blog post stating why monolithic tools are bad for the enterprise.
One of his arguments against an APEX architecture is that "data must be committed to the database before it can be seen by anybody else", which I think is an odd conclusion to reach. Last time I checked, most business applications deal with data. And 30 years from now, the interfaces and access methods to your data will change 10 times, but you will still have...your data. As long-time APEX expert Billy Verreynne ranted in 2005, "What does any business application deal with? DATA! That is the core. That is what drives the business. Applications come and go. Data is forever. Where does the data live? In the database. The database is the core. The database has been that since the 80's. Is still that. Focus on the core. Design for the core. Leverage the core."
I often tell people that the intersection point with APEX and many other technologies is the Oracle database - it's a wonderfully rich, very capable database and application development environment. It's an engine with interfaces, just like the many boxes this consultant showed in his enterprise architecture diagrams. Concurrency, transactional integrity, durability - these problems were solved in the Oracle database many years ago. And as a bonus, you get zero latency data access for free! Committing data to the database before it can be seen by anybody else should be considered a feature and not a deficiency.
Back to the term "enterprise setting", every enterprise, large and small, has a variety of application needs, from tactical to enterprise. You could consider it on a scale like this:
At the bottom of the scale are completely simplistic, tactical applications. These would be very easy to build, low in complexity, developed by one or two people, and often with a finite lifespan. These are often opportunistic applications. At the opposite end are enterprise applications. These have large teams (10, 20 or more developers), a project manager, a dedicated budget, are high in complexity (and cost), and are truly mission-critical to the enterprise.
On this scale, where would APEX be an appropriate fit for a certain class of applications? This is where I believe this consultant and I differ. I believe APEX is ideal for the bottom 90% of this scale. Sure, APEX can be and is used by customers for large ERP, HR and CRM systems serving thousands of end users, but the sweet spot for APEX is in the bottom 90% of this application scale.
Every enterprise has "gaps" in their corporate systems. Oracle, "the information management company ©" has gaps. I see it every day. No corporate system or enterprise system can solve all problems for all business needs. And the question is, how will you solve those problems, or will they remain unsolved? Corporate architects prefer to have a blessed, supportable technology stack, but that stack is often times unapproachable to most developers. Why do you think Excel has proliferated in the enterprise and continues to do so today?
The enterprise architecture that this consultant espouses is most likely perfect for legitimate enterprise applications. But at what point on the scale is that architecture and associated technology stack unnecessarily complex or too costly for more tactical applications? How many truly enterprise applications are there in an enterprise versus non-enterprise? 10 or 20 or 30 enterprise applications, versus hundreds if not thousands of non-enterprise applications? I'll gladly pitch the benefits of APEX to solve the bottom 90% of this scale and the thousands of application needs which every large enterprise has.
At Oracle, I see this bottom 90% being solved with APEX every day, from applications which track hardware allocation & utilization to applications designed to manage the collateral associated with blockchain use cases to applications for submitting questions to the payroll team - the "bottom" 90% is very large, and the question is, how will you solve them? With paper? With a spreadsheet? Or with a proven, scalable, low-code framework on the Oracle database that takes care of all of the important aspects of Web app development and lets you focus on the business problem to be solved? That, my friends, is APEX.
