In 2001, the Chicago Police Department took a chance on APEX. And with all thanks to them for the opportunity they provided us, Oracle APEX is what it is today. We owe them a big debt of gratitude. Let me explain.
As many people know, the genesis of Oracle APEX was an internal development project that began in 1999, to build a Web-based HTML calendar for use by Oracle employees. My manager,
Mike Hichwa, was the inventor of
Oracle Web DB. And when faced with the assignment of creating a new HTML calendar application for the company, the choices were a) WebDB, b) a lovingly hand-crafted PL/SQL application from scratch, or c) a yet-to-be-created application metadata framework (using Mike's lessons learned from WebDB). We went with the latter, and Mike began the creation of the APEX framework while I developed a calendar application which was "programmed" to use this new framework. Mocked and doubted by many at Oracle, we went live with the first production application in 3 months, rolled out to thousands of employees. Having
Tom Kyte to help us was instrumental in our success.
Over the next 18 months, we evolved this framework and created a number of other internal applications. We thought we were ready to offer this framework for customers to use. But one of the best things happened for APEX at that time. When Larry Ellison was visiting New York City, Mike traveled to meet with him and brief him on the state of the framework, as well as Mike's aspirations to offer this framework as another tool from Oracle. The advice offered by Larry to Mike - prove the framework with 30 real-world customers before you consider taking this live. Invaluable guidance.
In 2001, Mike and I had an internal meeting in Chicago with
Oracle Consulting. The back-end information system for the
Chicago Police Department (CPD), the Criminal History Record Information System (CHRIS), was written in Oracle Forms. It had been developed over many years, and was a joint effort between Oracle Consulting and the Chicago Police Department. The purpose of this meeting, at the time, was to discuss possible alternatives to the next state of CHRIS. This meeting was ultimately precipitated by the estimated hardware requirements to run the next version of Oracle Forms. They had estimated that the backend database server requirements alone would require 4 very large and very expensive new Sun Enterprise 10000 servers. This was a lot of money to be spent on hardware with effectively no net gain in functionality for their end users. We proposed APEX ("Flows", at the time), and they went with it.
Over a period of more than a year, a number of today's APEX product development team members worked directly, onsite, with Oracle Consulting and Chicago Police Department to move the functionality of their Oracle Forms applications to APEX. It wasn't a 1-to-1 mapping, and it required a level of application and UI redesign. But we were able to capitalize on the existing data structures and business logic, already present in the database. The Oracle Forms applications and APEX apps were able to easily co-exist, because they were built on the same foundation. There were also new systems developed as part of this effort, named CLEAR. You can still read about CLEAR from
this article from 2004.
This entire exercise was hugely beneficial to us. We thought we were ready to go to market. But once we dug into the requirements of a large-scale enterprise system like CHRIS, it uncovered many significant gaps in the functionality of the APEX framework. Fortunately, we owned the framework and were able to simultaneously fill those functional gaps in APEX. As a simple example, at the time there was no way to manage vectors of information in APEX session state. This real-world requirement resulted in today's APEX collections. When you own the framework and you are concurrently building the app, you can do anything!
Scalability was another concern. While the original calendar application we wrote for Oracle had more than 25,000 users, let's face it - the use of a calendar is occasional throughout the day. Contrast this with CHRIS, which had more than 10,000 total users, the vast majority who would interact with CHRIS frequently throughout the day. The heavy concurrent usage of these applications provided us numerous opportunities to tune and optimize the APEX execution engine. And talk about mission-critical applications - "business" slows to a crawl if you can't look up information about a person or log evidence. And when business slows to a crawl, public safety is jeopardized.
Fast forward to 2019, and here we are with a
large global community of hundreds of thousands of developers. There are dedicated
conferences,
stickers,
bloggers,
videos,
meetup groups,
awards,
books,
podcasts,
webinars,
hosting providers,
cloud services,
partners & consulting companies, and thousands upon thousands of
real-world successes from around the globe. Much of our success can be traced to this proving ground, which was afforded us by the Chicago Police Department.
The purpose of this blog post is simple - I wish to offer my personal, sincere thanks to the Chicago Police Department for the gamble they took on us. There was no true guarantee that APEX was going to exist beyond a "skunkworks" project, but they still forged ahead, given some assurances from Oracle and the alternatives. They banked on us and they won. Their real-world use cases stretched us and the technology in ways we had never imagined. We learned so many valuable lessons during this project, and all of it resulted in a much more scalable, hardened, proven system by the time APEX was first offered as an Oracle Database feature in 2004. We will forever be grateful to them.
For the record, these internal systems still run on Oracle APEX today, and are used by thousands of Chicago Police Department employees every day. Now
that is longevity, and a great investment. Amidst today's rapid
technology churn, this remains an extraordinary success story.
Patch by City of Chicago - http://www.publicsafetypatches.org/IL/Police/, Public Domain, Link
