Tuesday, May 08, 2018

Is APEX Suitable for an Enterprise Setting?

The APEX 18.1 release has significant new capabilities to consume a variety of remote data sources, from ordinary REST data feeds to ORDS-based Remote SQL.  Up until APEX 18.1, database links were the predominant way to access remote data sources, and of course, database links don't exist in the cloud.  Improvement in this area has been a core focus of ours for APEX 18.1.

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.

Sunday, May 06, 2018

The top 3 reasons to attend malagAPEX!

The explosion and adoption of Oracle APEX continues across the globe, and clear evidence of this is the introduction of not one but two new all-APEX conferences.  At the end of May 2018 is the latest APEX conference, malagAPEX.  If you're looking for an opportunity to get connected with the growing APEX community, this is an excellent place to start.

Here are the top 3 reasons why you should consider attending malagAPEX:

  1. The collection of speakers they have assembled for this conference is extraordinary.  They are all highly-respected and well-known luminaries in the Oracle APEX and Oracle application development communities.  Many of them are Oracle ACEs, recognized experts by Oracle and community champions.  Appdev is what they do for a living, and they will share their real-world experience with you.
  2. The agenda and topics covered at this conference are cutting edge - cloud, Docker, machine learning, Oracle JET, REST and more.  And of course, there will be plenty of APEX too!
  3. The location is breathtaking.  For those who may not be familiar with M├ílaga (or if you're American!), it is located in southern Spain, in Costa del Sol (Coast of the Sun) at the northern side of the Mediterranean Sea.  It will be beautiful, sunny and hot.  After the winter many of us recently endured, it sounds idyllic.

As I recently posted on Twitter this past week, one of the best things about APEX is...the APEX community!  Others have told me this, and I believe it too.  A community member Denis Savenko recently blogged about his first time experience in the Oracle APEX community at a new conference, and he said "awesomeness was in the air - everybody was extremely positive and ready to share their thoughts when it came to a discussion of any sort of a problem. I met a lot of interesting people from different countries, improved my professional contacts list dramatically and also had a chance to speak to really important people."  I can't state it any better than that.  This is representative of the awesome Oracle APEX community.  If you're looking for an opportunity to get plugged in, consider malagAPEX.