Many companies are jumping on board with Enterprise Social Networking.  Salesforce.com has announced their effort which is called Chatter.  However, this requires paying for every user in your enterprise to use the system AND it creates yet another system for your users to access.  Some have suggested setting up a Company group in Facebook to make that an Enterprise Social Network, but I doubt any corporate or government entity would take this route given Facebook's propensity to change the privacy rules to share your information with the world.  So what's the best option?  The easy answer is to use a platform that allows for custom application development, and has built in features for Enterprise Social Networking, document management and collaboration, a calendar that supports individual and group events, etc, to create a truly Rich Web Application.

Enterprise Social Networks are about bringing together many different system features into one area for complete unified access to information.  Many organizations have a system for an employee intranet, another system for document storage (i.e. Sharepoint), and yet another system for calendar sharing (i.e Microsoft Exchange Calendar).  Now it is easy to have one system provide it all.  With the latest version of TURBO Enterprise v5.0, it combines the original Rich Web App development capabilities (providing Ajax, JavaScript, Flash features), with Enterprise Social Networking, Group and Personal Calendars, and File Systems with document management and version control features built-in.

Read on for a few descriptions with screen shots of how these features can be brought together in one, easy to build and easy to manage system.

Thick Database, Database-Centric…different words, same concept:  leverage the power and performance of your database.

Over the past 20 years, I have seen a disturbing trend of organizations marginalizing the role of the database. It is quite surprising to see organizations spend 6 figures (or more depending on their size) on Oracle database licenses and then reduce it to a mere data repository.  I’ve seen implementations that utilize only 5-10 percent of the capabilities provided by arguably the world’s best database. Why is this happening? 

It all started in the mid-90s with a concept called ‘database independence’.  There were a few reasons for this strange paradigm shift, but my favorite is that a database vendor wanted to get into an organization that was already using a competing database: “Don’t become dependent on that database, so I can sell you a license for our database”.  Additional reasons included the high cost of database licenses (at that time) and COTS vendors wanting to write generic apps that could work with any database (to serve the COTS vendors' needs, not your needs). 

To this day, I have never seen an organization decide to just switch out an Oracle database to some other vendor database.  So why is this “database independence” still being perpetuated today? It's simple. Middle-tier developers have gotten used to not leveraging the database.  The middle-tier SQL statements have been written generically (i.e. not efficiently) so that they can be sent to any database (but we’ve already established that they don’t really just pick up the system and switch to another database).  So now this is just a bad habit (though some may call it technical laziness).

Today, we are seeing a reversal of the "database independence" trend.  More commercially available database-centric products are on the market.  Developers are now embracing the database.  The database is not just for storing data, but also for processing business rules,and even better for rendering incredible user interfaces.  Yes, I’m talking about serving up User Interfaces (UI) from the database. And I’m not talking about basic, simple HTML forms.  I’m talking about advanced Web 2.0 applications(interactive, dynamic web applications utilizing JavaScript, AJAX, etc).

As noted by Dr Paul Dorsey, in his “database independence” article from July 2007:

 

There are two key features involved in "thick database thinking":

• Nothing in the UI ever directly interacts with a database table. All interaction is accomplished through database views or APIs.
• Nearly all application behavior (including screen navigation) is handled in the database.  The UI notifies the database that some event has occurred and the database responds with a list of actions for the UI to execute.

 

He goes on to state that “thick database” does not mean just dumping all the code in the database.   Dr Dorsey provides the following example:

“For example, using a tool like Oracle’s Application Express that is itself stored in the database and generates HTML pages from the database is NOT an example of the thick database approach. The idea is that creating a thick database makes your application UI technology-independent.  If most of your logic is implemented in database objects, changing from one UI architecture to another becomes much easier.”

He has several reasons that explain the advantages of the thick database approach, but what is key here is how you build out your full application rendering in the database. It requires a very well planned out architecture inside the database using specific packages for handling the UI, and other packages for handling the DML.  A clearly defined structure allows for the UI code to easily be updated every time an exciting, new browser scripting language becomes available.  And when done properly, it just requires dropping in the new UI code without changing any of the application logic or data processing code.

This lets you focus on the most stable piece of technology in the enterprise, the Oracle database, while providing flexibility to adopt and adapt to new UI technologies.   Now go employ a “Thick Database” approach to marginalize the UI rather than the more important database.

Occam’s razor, attributed to the 14th-century English logician and Franciscan friar,William of Ockham (ca. 1285-1349), is the principle that "entities should not be multiplied unnecessarily". 

The principle is often expressed in Latin as: entia non sunt multiplicanda praeter necessitatem and translates to: entities should not be multiplied beyond necessity.

Frequently used in science, it has inspired a variety of expressions including "parsimony of postulates", the"principle of simplicity", and my favorite, the "KISS principle" (Keep It Simple, Stupid).

 

In an increasingly complex world, we all have the tendency to over-analyze things, especially when trying to understand particular events, activities, or happenings. Unfortunately, as you might expect, excessive analysis can lead to less-than-perfect results. Occam’s Razor is always at the back of my mind because it reminds me that often we need to simplify our thinking. The simpler the explanation, the better.

A good example of Occam’s Razor at work is the design of Rich Web Apps. Just yesterday, I interviewed a software engineer candidate to help develop a Rich Web App.  When interviewing candidates, I want to understand their own unique background and how they think about solutions, so I always ask the candidate to describe the system he/she is currently building/maintaining.  Here is the system as this particular candidate described it:

·     Unix server #1 running iPlanet for web server

·     Unix server #2 running WebLogic for app tier and WebLogic integration tier

·     Unix server #3 running Oracle database

Including the web browser, this makes it a 5-tier system!  Web browser -> iPlanet -> WebLogic app -> WebLogic integration module-> Oracle database 

I mentioned that the system seemed a bit "over-architected"and asked if it was designed this way to overcome some sort of performance issue and he just smiled and said some queries can take up to 20 seconds. 20 SECONDS!  That is unacceptable.  I asked how he would go about tuning the system to get it down to sub-1 second response.  He said that wasn't possible because they have over 10 million records in the database. 

I found that odd because we've implemented a TURBO Enterprise solution installed in an Oracle database that contained over 260 million records and was the backbone of our customer segmentation and marketing intelligence application.  Our system featured far fewer tiers resulting in amazingly fast response times: Web browser -> Oracle HTTP Server -> Oracle database running TURBO Enterprise.  Our client would have kicked us out if we delivered a solution that took20 seconds to return results.

So getting back to the point of Occam's Razor.  Choose the simpler implementation.  Embrace "Technology Efficiency" to deliver streamlined architectures with amazingly fast response times, rather than over-architected systems that seem geared more toward feeding an engineer's curiosity for trying a bunch of technologies instead of meeting the user's needs.

Needless to say, this candidate did not get the job…

Oracle Forms Conversion became a hot topic in 2009 when Oracle announced that it will no longer support Forms 6i.  To many IT developers, it may not mean much.  After all, it was just an old client/server application...and now it's all web apps these days.  However, to the end users who have counted on the stability and reliability of apps built on this "old school" platform, and to the PL/SQL developers supporting the Forms apps, this is big news.  "Big" because the Forms apps that have been reliable for so many years, now has become a Risk to the organization.

"Why is this stable app platform a risk?"

Without support from Oracle, this means no software updates, bug fixes, security patches, or support for trouble tickets. Thousands of systems now have a liability.  Many organizations have been forced to move these systems from "low" to "high" risk status.  This means they now have to start working to mitigate this risk.

"Why not just convert?"

Why fix something that isn't broken?  The apps aren't broken.  Just the support behind the software.  There is a surprisingly large number of organizations still running apps on Forms 6i.  The apps work just fine.  Why change it?  Up to this point, the only migration paths lead to Java-based web solutions. This presents three new problems: 1) The Forms applications would lose some functionality during the conversion to Java.  2) the IT teams would need to completely retool to support this new environment.  (PL/SQL developers don't just turn into Java developers overnight.)  3) All the end-users would need to be retrained to use the "same system" because of the new interface (and probably new workflow).

A simple solution is to convert from one PL/SQL environment (Forms 6i) to another PL/SQL environment (TURBO Enterprise).  TURBO Enterprise is a very robust Rich Internet Framework for PL/SQL Developers.  It contains the advanced features of Web 2.0 (e.g. AJAX, Javascript, etc) that allows web applications to look, feel and behave like client/server applications. 

A disruptive technology or disruptive innovation is an innovation that improves a product or service in ways that the market does not expect, typically by being lower priced or designed for a different set of consumers.  Many people often confuse disruptive technology as meaning to learn/buy/support all new technology.  In reality, it can be just using all of your existing skills, hardware, database and software in a new way.

"Bringing in" new technology (which involves at least the following steps: evaluate, purchase, learn/train, implement, support, etc) also involves the worry of wondering whether it will scale, crash, or even be around once you implement your system.  It would be a better use of time and money to use your current staff skills, hardware infrastructure and not spend a lot of money all while making even better use of your extremely stable Oracle database.  

The "latest and greatest" technology and language for the middle tier seems to change constantly...not to mention ongoing battle between Java and .Net.  TURBOEnterprise has baked in all the "Rich Web" features you'll need to impress your customers but which can be built using your PL/SQL skills.  Skip all that middle-tier hassle, simplify your architecture and just start building Rich Web Apps in the Oracle database.

With shrinking and overworked IT staff, businesses can't expect to have experts in every technology. Learn to do more with less.  Check out TURBO Enterprise at www.TURBO-Enterprise.com to learn how you can provide the Rich Web Apps your customers want using the skills and resources your team already has.

Rich Web Apps are everywhere online...your favorite shopping Web site, your favorite social networking Web site, your favorite news and reference Web site are probably all taking advantage of the latest Web technologies in order to provide you with a better user experience. Rich Web Apps are everywhere, except at your office. We (end-users, IT managers, and developers) have become very accustomed to seeing, using and benefiting from the features of Rich Web Apps. We go home and use sites like Amazon, Yahoo, Wikipedia, Facebook, etc. But back at the office our browser-based enterprise applications make us feel like we just went from playing Xbox 360 to playing an old Atari game of Pong. The rich user interfaces, dynamic onscreen features, and real-time interactivity we find online are missing from enterprise applications that consist of stodgy corporate interfaces, static forms, and interactivity defined as a submit button that initiates loading a new page. Our goal is to create enterprise applications that run in a browser but look, feel and behave like desktop applications. We want all the benefits and features of a desktop application without the hassle of deploying software to thousands of different computers.

Read the Spring 2009 issue of IOUG SELECT magazine or visit www.TURBO-Enterprise.com to learn how to build Rich Web Apps from your Oracle database.