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 to apply the update, someone needs to make a careful merge of the changes. Most of the time, diffs can patch it automatically, or it's an obvious change 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 these integration costs but when that's not possible, it can in extreme cases be more work to upgrade than to reimplement with a new solution as the base.

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 letting offer more highly customized packages from the start. 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. It's their domain model, database, or some set of integrations that's different which modifies or uses the domain model. Custom fields, custom reports, changing a query, or customizing a form's UI. But when they apply the domain model customizations, they end up writing framework specific code as well. That's because today's enterprise frameworks tend not to completely separate framework code from the application code that's specific to the business. Even the most modern 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 types with dependencies when they should be cleanly separated from the domain logic code. When framework dependencies are added to the domain model code, not only do you increase the risk of having to replicate or change domain model logic in response to changes in the framework, you also have a much harder time with domain model customizations because they become more complicated.

And over time frameworks change and evolve as the IT landscape evolves. New features and platforms are 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. The real question is not how to tune 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. Start by taking your large existing code base and importing it as one layer. Break apart the domain model into a clean set of sub-layers which compile into the same basic application, piece by piece. Incrementally evolve an architecture even from a giant monolithic system, separating the domain model from your frameworks. Start building new framework layers to modernize your applications.

Once you learn the tricks to use layers to separate code based on dependencies, your designs become cleaner and easier to read by separating concerns. You eliminate needless code copies so making it easier to update the domain model. You can break apart large classes into pieces based on the role of the code in the project (e.g. database, UI). This organization typically aligns with developer responsibilities, reducing conflicts among team members.