Tip

Rethinking the conventional wisdom of data architecture

The World Wide Web had barely appeared when people were looking to Web-enable the relational database (RDB). The first approach was known as CGI (Common Gateway Interface) - it was basic and low-performance.  Then, the Java app server came in quickly as a means to connect an RDB with a Web front end. Java was so prevalent; it allowed Sun Microsystems to claim it put the "dot" in "dot.com."

Web services came along as well.  Obviously there was value to connecting, for example, a mainframe-based transactional car rental system with an Expedia-style Web front end. But, for people over-imbued with conventional wisdom, the database and the transactional system remained the center of the real game. Much Web services development, in retrospect, was unnecessarily beholden to old familiar RDB-centric architecture.

Enter Google, Amazon and a host of other successful Web startups. These companies found real customers. They also found real limitations with relational databases. They also invented cloud computing. Today, the major distinguishing characteristic of cloud computing is a general drive to

    Requires Free Membership to View

reduce the role of the RDB. The RDB has a future, of course, but it shows signs that it is not the be-all and end-all.

The new Web-based companies had little vested interest in conventional wisdom. To them, the relational data base did not look like the way to do the Web.  Instead they spawned non-SQL software like Cassandra DBMS, as well as the MapReduce and related Hadoop distributed application frameworks. Some new Web businesses (think "Facebook") place messaging middleware at the center of their architecture, shunting the database to something of a side role. Conventional wisdom got a kick in the pants.

With conventional wisdom on the run, we have entered a new era of software architecture. Lightweight Web application frameworks have rocketed past overly cumbersome object component containers. On the portal front, we see enterprise mashup APIs and REST reworking the ground rules of architecture.

Today, there is much talk about the future of Java. Some pundits suggest it is too infrastructure-oriented, and too complicated to meet the needs of the enterprise. We as an industry would do well to be sure to take off the conventional blinders when analyzing the issue. It may be the case that Java will continue to thrive but that programmers' ability to use it in conjunction with other languages (Clojure? Scala? Python?)  will become key.

This was first published in March 2011

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.