Building Unbreakable: Beyond Love, How Compatibility Matters In Your Business Apps, Too

A Google search for “compatibility” finds this top result from : “Find out if you and your love interest or partner are soul mates, best friends, or a recipe for disaster. But no fear – even opposites can attract. Find out how you fare now…” In our professional day, where many hours are expended daily using business software, enterprise users can find utility relating their personal experiences of compatibility to their business relationships, processes, and the software that powers them. The 2nd most popular result from provides this useful definition of compatibility from computing: “the capability that allows the substitution of one subsystem (storage facility), or of one functional unit (e.g., hardware, software), for the originally designated system or functional unit in a relatively transparent manner, without loss of information and without the introduction of errors.”

From Wiktionary, the phrase, “substitution of one functional unit…in a relatively transparent manner, without loss of information and without the introduction of errors.”, is particularly relevant. In my previous post, I discussed 3 specific examples of compatible database data types in a compatible, re-platformed and equivalent application. Now, consider the illustrations below that compare an Oracle Forms v6 client-server app, and its re-platformed cloud equivalent running on Apple iPad:

summit_oracle summit_paas
Figure 1, above: Pre-Cloud Baseline: Oracle Forms
application illustrating the “Summit Sporting Goods”
application from Oracle Corporation’s classic
“scott/tiger” schema.
Figure 2, above: Re-platformed to Cloud: HTML5 cloud-equivalent application that preserves execution fidelity and behavior. Above “compatible” design target runs without Java applet and without JRE on Apple iOS and Google Android devices. All transient behavior, including pessimistic locks, user and system events, is preserved.

Compared with Figure 1, Figure 2 shows a representative and straightforward target that would be expected of enterprise-scale apps that demand fast data entry in OnLine Transaction Processing (OLTP) workloads. All behavior – transient (with intended side-effects) and final (with pre-validated state-based data) – would be expected to run as-is in OLTP apps.
Characteristically, these new generation cloud apps, unlike Oracle Forms and Oracle Reports, enable customers freedom of choice to run everywhere and run fast, with these new capabilities:
• HTML5 “responsive” UI
• Any application server
• Any web browser and iOS/Android device
• Run without plug-ins (applet, flash)
• Run without Java Runtime Environment (JRE)
• Run on 64-bit systems at runtime and design-time for efficient Dev Ops
• Support continuous integration for rapid change resiliency to market needs
• Aspect Oriented Programming (AOP), AspectJ
• Lower maintenance cost from deployment ubiquity

When the above application characteristics are deployed on cloud offerings such as IBM Bluemix, Oracle PaaS, Amazon Web Services (AWS), and Google Cloud Platform, customers can respond more effectively to high-velocity markets disrupted by transient competitive advantage1.

Strictly-speaking, cloud does not require application multi-tenancy. For end-customers, multi-tenant architecture is not meaningful when each customer’s application, by origin and definition, is wholly different from another customer’s application. In this Information Week article from July 2014,, Gartner talks about this alternative cloud offering that is equally valuable for many businesses: “Where multi-tenant services used to be viewed as “true cloud” and hosting or single-tenant a form of cloud washing, many enterprises are now choosing hosting as their preferred route away from on-premises deployments.” For Independent Software Vendors (ISVs), however, multi-tenant architecture has utility since well-designed apps will separate customer-specific extensions from an ISV’s base application that is served to its end-customers. In these contexts, multi-tenant resource sharing in the ISV’s PaaS cloud is important to better utilize infrastructure for scalable management.

In my next blog post, I will look more closely at the above application in the context of programming language differences between the original pre-cloud and re-platformed cloud apps. There, we will look at the difference in system architecture and languages with respect to the database data types and how compatibility matters – not just for user experience, but also for developer experience and enabling them for business agility while realizing Wiktionary’s definition of computing compatibility – transparent substitution without information loss and without errors.

Tweet us @neoworksinc with your ideas. Share your application compatibility experiences at Northern California Oracle User Group (NoCOUG) in San Ramon, Ca on August 20, 2015, . Visit our Facebook page at: .

Have a great rest of your week!

1”Transient Advantage”, Rita Gunther McGrath, Harvard Business Review, June 2013.


Building Unbreakable: 3 Concepts to Re-Platform Your Oracle Forms and Oracle Reports Custom Apps to the Cloud

Over their 30 year history, Oracle Forms (and Oracle Reports) application development tools, and the applications on which they’re based, have been deployed worldwide by thousands of companies. While extremely powerful and innovative when they were introduced in the 1980s, these apps limit an organization’s options to run on their platform of choice – alternative User eXperience (UX) such as HTML5 and “responsive” UI, alternative application servers, and alternative databases. In this post, I discuss 3 key concepts that must be addressed to deliver compatibility without compromising execution accuracy for customers who want to explore options to re-platform their Oracle custom apps to modern, alternative architectures that exploit low-cost cloud computing, run standards, and run everywhere.

As a former employee of and contributor to Oracle Tools Division in the 1990s, I worked in a team of impassioned developers to change the way customers build database-driven apps. I’ve seen customer usages evolve as they upgraded over successive releases of Oracle Forms, from SQL*Forms v3.0 to Oracle Forms 9i. Today, as a team of developers defining transformative technologies for Oracle custom apps, we’ve identified several salient attributes of these apps through several customer engagements, 3 of which I’ll introduce here: (1) “long running” transactions; (2) distributed session/state across all computing tiers (database, app server, and client); and (3) application-specific logic and its dependency on event architecture.

For long-running transactions, row-Level pessimistic locks that are held by users for prolonged periods – hallmark of Oracle custom apps – can lead to data inconsistency in modern HTML5 apps if not treated across all transaction use-cases. For distributed session and state management, the Oracle Database allows application state to be stored in package variables, which poses a significant challenge in modern architectures that leverage connection pooling for better system resource utilization. For customer application-specific logic, Oracle Forms is dependent on Oracle Database-specific datatypes, such as PL/SQL BOOLEAN, PL/SQL RECORD, and PL/SQL TABLE. These datatypes are not supported in modern programming languages or even other databases. For example, a BOOLEAN datatype represents only 2 states – TRUE or FALSE. In Oracle Database, a BOOLEAN datatype has 3 states – TRUE, FALSE, or NULL. This leads to unexpected behavior in certain conditional processing for custom app logic in any modern app, not just re-platformed Oracle Forms/Reports apps. In the next post, I will review these attributes in greater technical detail with code examples.

Our engagements have shown that customers’ expectations of compatibility mandate that their core information assets – applications and the data on which they operate – must run identically as releases are upgraded within the same architecture, and run identically even when re-platformed to a different architecture. As application complexity increases – in number of screens, intricacy and size of code, distributed state across the database, application server, and client tiers – a transformative change will not be adopted if the re-platformed app is not transparent to end-users. Some of these concepts have been raised before. For example, this article from Oracle Corporation discusses topics of compatibility from the viewpoint of an upgrade within the same architecture stack: In some cases, customers demand improvement through re-platforming, without breaking execution accuracy. For example, they seek incredible ease-of-use benefits to improve usability, non-intrusively, without breaking core business process logic.

Please share your findings so we can help the broader developer community of Oracle database developers building new HTML5 apps, not just Oracle Forms and Oracle Reports customers, solve universal problems for modern enterprise application development. Tweet me @neoworksinc with your views, and come see us at Northern California Oracle User Group (NoCOUG) in San Ramon, Ca on August 20, 2015. Visit our Facebook page at: .

Have a great rest of your week!