Over a million developers have joined DZone.

The Middle Path Approach

· Java Zone

Learn more about how the Java language, tools and frameworks have been the foundation of countless enterprise systems, brought to you in partnership with Salesforce.

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.

Discover how the Force.com Web Services Connector (WSC) is a code-generation tool and runtime library for use with Force.com Web services, brought to you in partnership with Salesforce.

Topics:

Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}