CodeFutures News & Industry Commentary Blog
Thursday, February 23, 2006
Gartner on Service Data Objects
It's well known that leading industry analysts firms can influence the direction of the industry. The can also directly influence decisions to introduce new products .....
Two of the sharpest industry analysts, Daniel Sholler and David Mitchell Smith, of Gartner, Inc. were the first to write*** about the significance of the Service Component Architecture and Service Data Object specifications announcement in November 2005.
As well as analyzing the significance of SCA, the analysts discuss SDO. It is in the context of SCA that the SDO specification has become very important.
Sholler and Smith state:
SDO's function of facilitating enterprise data integration is the most prevalent goal of many SOA initiatives, and will be a big reason why SDO will achieve official standard status more rapidly than SCA.
In the final recommendations, Sholler and Smith state:
Assume that SDO will become prevalent by late 2007, and seek out products that support SDO abstractions for data.
I take these guys predictions seriously because they have been right in the past. For example, Smith's claim to fame is that he that predicted XML messaging over HTTP would emerge (before SOAP 1.0). He caught my attention years ago by being the first to identify back in 2001 that application servers were bloated and users were buying application server functionality that they would never use (pretty brave to call out a billion dollar market niche that was probably paying millions in analysts fees) .
So when Sholler and Smith say that SDO will be big, you have to take notice. They strongly influenced the decision to go ahead with FireStorm/SDO.
***New SOA Specification Will Fill Niche Among Java Users , by Daniel Sholler, Research Vice President, and David Mitchell Smith, Vice President and Gartner Fellow, Gartner, Inc.
Tuesday, February 21, 2006
Learning from the core of Apple: Design
I just came across an article from Business Week from July, 2000 about design being the core of Apple. What is interesting is that it was written before the introduction of the iPod! Apple is now mainstream and consumer, whereas before it was really only known for its design excellence in the computer industry.
The elements that were identified were: branding, usability, technology, conceptualization, and zeitgeist.
Branding: Distinctive designs are a form of branding. It's also a key element in Apple's profit margins.
Usability: Ever heard of an Apple product that was difficult to use? But it goes beyond that, because Apple products are a pleasure to use.
Technology: There's always new technologies available, so Apple decides on new technologies by focussing on the end users' needs. This is surprisingly rare (but something CodeFutures can claim to have done with its new Service Data Object product).
Conceptualization: Design is used to try out new forms of products incorporating new technologies.
Zeitgest: Apple produces cool products, but also daring products (iMacs, for example).
CodeFutures pays a lot of attention to usability, but not so much to product design. The CodeFutures design philosphy is to keep things as simple as possible (choice of colors, layout, etc). For our new Service Data Object product, it will be interesting to see if we can apply some of the Apple mindset when it comes to design.
Monday, February 20, 2006
Achieving Reuse with Data Services
The vast majority of professional Java application development is for one-off business applications. There is almost no reuse of existing code and only a general effort to achieve some level of consistency through coding standards. There's also some standardization on third party product use, such as application servers and databases (but often just at the departmental or divisional level). Popular development practices in Java like eXtreme Programming assume that every application will be designed and developed independently from first principles, assuming unique requirements. Any reuse in Java tends to be incidental and typically because the same development team has already developed a similar application before. Otherwise, organizations seem to have a kind of dementia regarding what has been done before.
CodeFutures' domain, data persistence, is typical. The data persistence tier is almost always developed for a specific application and tied to that application. In terms of developer productivity, this is not such a huge problem if a code generator like FireStorm/SDO is used. A level of reuse and consistency can always be achieved using a code generator. However, there's an architectural way to ensure reuse of data persistence code.
If you associate the data persistence code with the data source, rather than the specific application, then you only need to produce it once. If that data persistence code is based on Service Data Objects, then the data source is then available as a reusable data service.
- Reuse becomes systematic because there's no other choice.
- There is greater control and visibility over how the data source is used (the Data Access Service can be monitored).
- There's much less code to maintain because the data pesistence code is only written once, rather than for each application.
Effectively, if you raise the level of abstraction from direct, application-level Java data access code to a data service, you decouple the application code from data access code, and you achieve a reusable production asset via the SDO API.
Thursday, February 09, 2006
Three Thousand Downloads Per Month
FireStorm/DAO is downloaded over 3,000 downloads per month, every month. In fact, downloads peaked at over 11,000 in December 2005, before dropping back to its steady state in the near year. So what does that tell you about FireStorm/DAO?
-FireStorm/DAO is a niche product, but it's a fairly decent sized niche. There's a lot of Java developers out that that are looking for a data persistence solution.
-FireStorm/DAO has been used in just about every possible configuration you could imagine. There is a large automated test suite, but that's no substitute for real world applications. And that means end users working on real applications.
CodeFutures also actively eats its own dogfood. A lot of the internal company systems - from the Web site CMS to the Customer Portal to Licensing System are all developed and updated regularly using FireStorm/DAO. It should be compulsary for application development software vendors to use their own products in real applications, because there's no better way ensure a application development product works.
FireStorm/DAO is probably one of the most widely used commercial Java persistence tools on the market.
We're hoping that the success of FireStorm/DAO can be repeated with FireStorm/SDO - with Service Data Objects instead of Data Access Objects. The different is of course a lot more fundamental than just using the SDO API. FireStorm/SDO is about the future - data services in service-oriented architectures.