|Software industrialization for Internet|
|Written by Christophe Fondacci|
|Monday, 27 July 2009 11:36|
Today's challenge for IT organizations is defined by these 3 words : "time-to-market". This time defines the delay between the idea and its general availability for users. Organizations need to : 1) have the best ideas 2) be the first to release them 3) provide them with the highest level of quality and performance.
Efforts to reduce the time between the idea and its implementation leads to 2 major principles :
The software industrialization era was born. For now it mostly consists in tools, robots, scripts, schedulers which can assemble and deploy all the software pieces together to build the whole application and then run unit, technical and functionnal tests against it. This is a software factory which can build and test every piece of code each time it changes. We can now deploy an application by clicking one single button...
But, we're missing a big part... Almost every application relies on a database to store / retreive its data. Even though databases generally represents less development efforts than the whole application on top of it, it still defines the structure and the data required by the application in order to work. So if we have a software factory for the application, we need a database factory to assemble the database developments as well. Without, we would test our application against the development database, or we would mock the entire database access layer to only test the application code preventing end-to-end functionnal tests before delivering.
The purpose of industrialization is to automate things and to detect problems early so that they can be fixed quicker... In the previous use case we might face some troubles after delivering the software, that means later. Another problem is that we have a fully automated package & delivery process for the application code, but we still need to create SQL scripts by hand for structural upgrades of the database. Many will tell us that they've made their own custom delivery system and that it works well...
Our point of view is that it might work well...so far. Several issues came to us during our past experience with different organizations :
Because we faced all these issues, we started to build the neXtep designer platform... The idea is to provide an IDE that addresses those needs in a transparent way. The targetted objective is to let all database developers concentrate on their expertise : building efficient and consistent data models.
First, we started to think on how we could handle the packaging and delivering automation. The singularity of database deployment resides in its incremental aspect. You do not install the new release, you transform the existing model into the new one by sending the appropriate SQL commands to the database engine. Because of this incremental aspect, versioning is the cornerstone of the neXtep designer IDE. Thanks to version history, we can compare any version with another, retreiving any differency, thus allowing us to automatically produce corresponding SQL scripts.
This is also the reason why we answer to the package & delivery automation with a development IDE: we need history of changes from the development stage in order to automate the incremental packaging and deployment stages. Once you will get used to it, you will start to consider SQL DDL (Data Definition Language) as a way of delivering changes to your data structures.
We considered building a new database IDE was relevant, because we think we are lacking of good and modern integrated database development environment. But we needed to do more than what database IDE do today. We need to gather all development features that a database developer need into one single environment. That means graphical modelization, database client, offline database development, version control, compiler, content assist for SQL edition, debugger (for vendors which can support it like Oracle) and so on. That's why the Eclipse RCP platform perfectly suits our needs with the modular pluggable architecture of OSGi.
Thanks to the extension mechanisms offered by the Eclipse platform, we progressively add more and more features to the environment. Our roadmap is full of great enhancements, such as :
We need to finance all these features, and we want to keep a pragmatic approach: we only build features for which we have a demand. That's why we set up our Collaborative Open Source strategy which allow anyone to contact us and to drive the development of a feature he needs.
|Last Updated on Saturday, 01 August 2009 19:02|