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.