Customizable Enterprise Systems

Typically enterprise software companies need to heavily customize the applications they buy. When a new version of the application is released, it can be a challenge to upgrade. It's likely that some files they copied and modified have been changed so they need to merge. Sometimes a simple 'diff' can be used to patch it automatically but when it gets involved, it might be tricky even if you had the two developers in the room who made the conflicting changes. A successful enterprise software company can afford to put those two programmers in the same room but when that's not possible, it can be more work to upgrade than to have reimplemented the feature in the first place.

With layers, you do much less copying to implement your customizations in the first place. Secondly, enterprise vendors have more flexibility for adding new features in new layers. That lets' them offer more highly customized packages from the start and require that fewer customers make changes which are specific to their copy. It's easier for the enterprise vendor to test more customized layers, so they can offer better service by testing customer specific layers, and taking that knowledge into account when building new features.

Separating Application Code From Framework Code

Most of the time, enterprises need to customize the business logic of their application, but they have to write a lot of framework specific code along the way. That's becuase enterprise frameworks tend not to completely separate framework code from the application code that's specific to the business. Even today, the best application frameworks do not do a good job of separating application code from framework code. Frameworks like JPA, Spring and hibernate tie your domain model code to their framework code. Or your models are glued to some XML format that ties you to framework code at runtime. Features like configuration, transactions, caching, leak into application objects with dependencies and are not cleanly separated from the domain logic itself. When framework dependencies are added to the code, that code can only be used with that framework. The developer working on that code must know that framework or know they can ignore the framework annotations.

Over time frameworks change and evolve as our IT landscape evolves. New features are always in demand: real time, mobile, better transparency, better performance, etc. Separating framework from domain logic will let you reuse that logic with current and future platforms. Logic running on the server today, may need to run on a mobile device tomorrow. Spring and Hibernate may never be suitable technologies for the mobile platform because they took too many shortcuts and rely on lots of runtime introspective code. The real question is not how to fix spring and hibernate but how you properly tease apart the dependencies on such systems from the code you really care about - the part that defines how your business runs.

StrataCode's design provides the basic structure to separate dependencies in your code naturally, without complex code refactoring. Once you learn the tricks to separate layers cleanly, your designs become cleaner and easier to read by separating concerns. You eliminate needless code copies so models can't drift out of sync.