Early Product Strategy of FireStorm/DAO
Directly before starting work on FireStorm/DAO, I was Product Strategy Manager at Cape Clear Software, so I approached the design and architectural phrase of FireStorm/DAO with a very strategic mindset. Strangely enough, planning a new product is as much about avoiding mistakes and getting the basics right as it is about innovating. This means marketing/competitive analysis.
FireStorm/DAO can be readily classified into a variety of different categories: general Java development tools, code generators, Java persistence tools, database tools, productivity tools, and several more.
Getting the product basics right
Standards Support: For Java, the specifications produced by the JCP are essentially the industry standards. The most important specifications for FireStorm/DAO at the moment are J2EE (especially EJB/CMP), JDO, and JDBC. The Java persistence sections of EJB 3.0 will become important once the specification is finalized.
Development practice support: This means supporting the popular if unofficial products, such as Ant, log4Jj, and Struts.
Third party product support: For FireStorm/DAO, the top priority is of course databases, closely followed by the main application servers.
Code Generation Strategy
Looking at the Java code generators listed on the Code Generation Network reveals a number areas where many vendors have made strategic mistakes.
Templates: The first and most obvious problem with many code generators is that they use proprietary code generation templates. This increases the product learning curve for no good reason and is the reason why the templates in FireStorm/DAO are written in standard Java code.
Configurability: Some code generation vendors offer a take it or leave it approach to the generated output. A very early architectural decision for FireStorm/DAO was to make all aspects of the code generation configurable. This fitted in very well with the decision to write the code generation templates in Java.
Existing development practices: Some code generators are invasive in the development process. For example, code generators based on MDA/UML require that a model is maintained and synchronized with the generated code. This means that Java coders become modelers and that the design phase, particularly, of the project has to change.
Java Persistence Product Strategy
Most discussions about Java persistence are dominated by the competing technologies that are available. The highest profile debate has been between the group of JDO product vendors and Hibernate advocates. However, there’s several problems with focusing on a specific technology, not least because no technology has a guaranteed long term future.
So FireStorm/DAO concentrates, uniquely at the time of its launch, on the Data Access Object architecture, which is a J2EE design pattern. This allows FireStorm/DAO users to be flexible with the Java persistence technology choice while using a sustainable long term architecture.
Licensing and Pricing Strategy
The product packaging strategy of FireStorm/DAO was at the same time the easiest and the most important for the commercial success of the product. The licensing is developer centric, because they are the users of the product. Some examples of this are:
-no runtime or deployment fees (developers would find it much harder to obtain permission to use the tool)
-per named developer licenses (developers often have more than one development machine, so it makes sense to allow the tool follow the developer rather than the development machine)
-unrestricted customization for Architect Edition users. There’s no restrictions on how FireStorm/DAO is customized or how many custom templates are produced.
-upgrades included in support pricing, so developers don’t have to go back to their managers each time the want a new version of FireStorm/DAO
Team Development with Architect Edition
The realities of software development are that team profiles have changed a lot over the past 10 or 15 years. It used to be that a development teams consistent of mostly senior and experienced developers, with a few less experienced developers there to assist. Now it seems like the opposite is true. The Java persistence architect using FireStorm/DAO Architect Edition produces a custom DAO template that is used by the rest of the development team. This allows the architect directly control the code generated by all other developers.
Comments
Wow. Great article. I once considered taking my code generator (Jostraca) commercial, but you would have beaten me hands down and rightly so.
I also agree that the templates should be in Java - developers don't want another language to learn. I never focused on the persistence side of things though - that's were a lot of the business value is.
I had the (dis)pleasure of working with Versata once - a good example of how not to do it, although the business rules integration was a good idea - you should look at what they did with that.
Posted by: Richard Rodger | July 15, 2005 06:07 PM
All that early strategic planning really shows in the end product. You've done a great job. Keep up the good work.
Are you going to write about the current product strategy?
Posted by: Sean | July 27, 2005 09:46 PM
Very interesting. Most products are not that well thought out.
I used Toplink in its early days - it too was good in its early days - but not since they became focussed on Oracle and started to charge runtime fees.
I really like the idea that I can choose between JDBC and EJBs with Firestorm
Posted by: Joe Stein | September 7, 2005 01:46 PM