Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 228 posts at DZone. You can read more from them at their website. View Full User Profile

The Middle Path Approach

04.14.2013
| 2353 views |
  • submit to reddit

I’ve been doing software development for most of my career, so that I think myself as a software developer (or software architect), even though I’ve dabbled in solutions engineering more than once. This surely has an effect on how I see the architecture landscape, but I’ll try to be as objective as possible.

Historically, there have been two approaches in providing software solutions to business requirements:

  • Either create custom software to address the requirements
  • Or purchase an out-of-the-box solution to do the same

My software developer side was formerly more in favor of the first option. I thought that this way provided more flexibility than an editor package. During my professional life, I’ve come to realize that management sits on the opposite side, viewing out-of-the-box packages as less risky and less expensive. Even if I agree to the risk point, there are numerous cons to purchase such a solution:

  1. All projects I encoutered only planned for license costs. However, users generally ask for numerous adaptations that require a long configuration
  2. Some, if not most, of those adaptations require more than configuration, but hacking the product itself, which costs even more
  3. Changing the product has a great influence on the maintenance costs, especially toward upgrading: you’ll have to patch the code in the newer version, provided it is compatible
  4. Cutting on the adaptation side will also have an effect on the business side and will require a stronger change management planning
  5. Most products used are provided by (really) big companies: you’ll need to also purchase the associated infrastructure in order to benefit from full editor support (believe, I’ve tried going the other way to my chagrin)

Preaching that out-of-the-box solutions are thus cost-effective is the biggest lie of all!

So basically, it’s either take the risky development road or the costly/coupled product one. Shouldn’t there be an alternative path, that could address these issues?

Since the beginning of the year, I’m working for a company that I think provide such an alternative. It comes in the form of a product whose features include:

  • a basic platform developed with Java & Spring and providing a plugin architecture
  • an extensible business model
  • a service layer, designed around an interface and an out-of-the-box implementation. Implementations can be replaced through a developed plugin
  • a templated web layer, based on Spring MVC that can be modified as needed

IMHO, this is the best alternative I’ve ever seen. This way, you can get the whole shebang in production very quickly, adapt the system to your specific needs (either before production or by incremental steps) and still be able to upgrade easily with each version. Software companies should probably invest in migrating their products to this kind of architecture.

The company is hybris, and I’m very happy to have joined their ranks since the start of this year.

Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)