opentaps Quarterly Update

We've been busy! Now that we're past version 1.0, we had a chance to make some fundamental improvements to opentaps for a long-term. We have begun to develop a new domain driven architecture for future versions of opentaps. This object-oriented architecture will make it easier for you to customize and extend opentaps or to combine it with other applications. It will also make it easier for us to develop opentaps and help it continue to grow.

opentaps Analytics is also coming along nicely. You are now able to slice and dice customer, order, and return data by over a dozen different ways, including by country, by brand, by month of the year, and by category. You're also able to look at the lifetime value of your customers from all these different angles. We are completing development of an automated query generator for JasperReports which will allow us to create a lot of reports quickly and easily. (See the screenshots.)

In addition, we've made the following improvements:

• A maintenance release of opentaps 1.0.1
• A new query tool to make querying and reporting easier to develop
• A POJO (Plain Old Java Object) Service Engine for mounting business logic written in standard Java objects (beans) in the service engine.
• Support for order management and invoicing of services
• Support for kerberos single sign-on
• Improvements to data importing, order entry, manufacturing, and warehouse management
• And last but not least, thanks for a community contributors, a translation of opentaps to Bulgarian and new documentation pages for opentaps in Spanish and Chinese.

Coming Soon

These are some of the additional enhancements planned in the next few months:

• Ability to deploy opentaps on JBoss
• Support for LDAP authentication
• Better Ajax look up interfaces
• Improved marketing features, including customer segmentation and Recency, Frequency, Monetary (RFM) analysis

A New opentaps

Development of opentaps will continue towards version 1.4 using the current ofbiz-based framework in the next few months. The coding style will become more domain-driven, object-oriented as our domain driven architecture becomes more established. Later this year, we will begin developing a new framework for opentaps 2.0. This new framework will be fully compatible with existing and future applications built on ofbiz, but it will rest upon a stronger Java J2EE foundation and allow us to incorporate many other open source projects into opentaps. This will allow us to expand opentaps into whole new horizons much more easily than ever before. We can't wait!

Finally, a special thanks to Simon Zhao, Juan Gimenez, Ivan Popov and the Tooleast team, and Skip Dever for their contributions to opentaps in the last few months.

The Value of Software Architecture

Every company, no matter how big or how small, already has software to manage their business. So if they are looking at opentaps Open Source ERP + CRM, it's because their system has failed them. That system may still meet some needs well, but as a whole it can no longer support the users' long-term needs.

Why this is happening? Usually for the following reasons:

1. The users have no access to the source code, so they have no way to make changes they need.
2. The system can't support new functionality. For example, it may have been built solely with direct marketers in mind and cannot be adapted for manufacturing or more complex B2B sales.
3. The source code is no longer maintainable because its original authors have moved on, and there's a lack of documentation and unit tests to help new developers work with it.
4. The system cannot support new technologies. It may have been written with a DOS-based rapid application development tool, which will never support the Internet.
5. The hardware which runs the system is no longer made or supported. For an extreme example of this, see this story about Ecometry and the HP3000.
   

What We Can Do (Better)

These problems show how important software architecture become over a long period of time. The most important thing about well architected software is that it can withstand change. It should allow you to modify, extend, or even replace parts of the software while the rest of it keeps humming along. In this way, a good architecture could extend the lifespan of your software and allow it to adapt to new technologies, new people, or new requirements.

For us, as developers of opentaps, it means that we need to produce a system that is not only feature rich and user friendly, but also a well architected. In this respect, there are somethings we already do well, and there are somethings that we need to do a lot better.

I think we already do the following well:

1. Our source code is openly available to all of our users, and this is a huge advantage, because it allows them to modify opentaps to meet their needs. In theory, this should actually be all they need, but in practice that is not the case. Having access to the source code doesn't actually do you any good unless the source code is also easy to work with and can support changes easily.
2. We have a very robust data model, which can support the core business needs of most industries.
3. Because opentaps is a newer system, it is built with current industry standard technologies such as Java, SQL databases, and XML.
   

However, there are some things that we need to do a much better job of. Much of our code is still too static and closely tied to the underlying data structure and one particular framework. (See this example.) What we really need is to adopt a more object-oriented design, so that it's easier for other developers to understand and extend opentaps, and so that we can be up-to-date with the best open source technical frameworks available.

Therefore, we have begun implementing a Domain Driven Design for opentaps, which is an object oriented design pattern that builds applications from business domains such as customers, orders, invoices, and shipments and separates the infrastructure tier of dealing with servers and databases from the business knowledge. We believe that this Domain Driven Design will give us -- and most importantly you -- the ability to extend opentaps, replace some parts of it with other systems, or upgrade opentaps to newer technical infrastructure, while preserving your investment in the rest of it.

The Plan for opentaps

This Domain Driven Design will be an evolutionary change from the current architecture. We will be moving our business tier code to the new design over the next few months while continuing to piggyback off the existing ofbiz framework. While doing this, we will continue to advance the development of opentaps version 1.4.

At some point, we will begin creating a new framework for opentaps version 2.0. This will be fully compatible with the ofbiz framework, allowing you (and us) to incorporate current and future versions of ofbiz and all the opentaps and custom applications we have already built with it. The drivers of the new opentaps framework, however, will more likely be a yet to be decided combination of open-source projects such as Hibernate, Spring, guice, JBoss Seam, Struts, Wicket, etc. It will allow us to re-factor, at our leisure, legacy ofbiz-based code to this new framework and at the same time incorporate other Java open source projects into opentaps more easily.