Meta Data Driven Architecture

Introduction

Typical Enterprise re-architecture efforts targets moving from Legacy platform to new generation Platform and changing the functionality of how state managed in the system. The goal is to provide extensibility/flexibility/scalability/pluggability in the architecture so that the target system is suitable for customizations/maintenance.

Figure 1 – Layered Architecture based on .Net

Approach:

The approach taken is to use the metadata driven architectural pattern. Using the object repository paradigm of modeling the metadata, code is generated for n-tier architecture. In a n-tier web application, ui layer, service layer, persistence layer, data access layer and storage layer are implemented using the layer wise patterns and practices. Every layer can be generated using the appropriate metadata attributes. Each code artifact is customizable and extensible with partial class approach, event handlers, delegates, templates.
Based on the metadata, code will be generated for each layer based on the best practices. Code documentation will be generated and the help documentation can be generated based on the metadata. Complex user interfaces will be hand coded using controls. Complex business logic will be hand coded. Reverse Engineering will be manual. Features/Revisions/Versions will be maintained.
This approach is future proofed as future technology migration can be done using the metadata captured by rewriting the appropriate technology based code generators.
To prove the above concept, metadata management tool code was generated using the code generator. Tool had around 12 use cases and customizations were done where appropriate. 10% of the code was hand written and 90% of the code was generated using the code generator.

Build vs Buy:

• Metadata driven approach manifests in the industry in various forms
• Code generators with templates for various layered components
• Model driven architecture tools which use cartridges for generating platform specific model from platform independent model
• UML/XMI based tools for generating code.

Architectural requirements of typical enterprise legacy product have unique features at each layer which poses challenges for buy approach.
Some of the challenges are listed below:

• Database layer needs to persist, not only the current state but also the future scheduled changes/temporary changes.
• Persistence layer needs to have capability of storing and retrieving from database and other sources using object adapters.
• Business Logic and rules layer has the complexity of working across group of entities and spreading changes across the entities.
• Service layer need to have capability of handling a group of entities related to a work item and handling what if changes.
• UI layer needs to have the flexibility, extensibility features for customizations, handling extensible attributes and entities.

Partial Buy vs Complete Build:

An approach of realizing some features using an existing vendor products e.g., ADO.Net Entity framework, LINQ to SQL, ASP.Net Dynamic Data etc., defeats the purpose of re-architecting as some of the goals of providing extensibility and handling state management cannot be realized.
Different approaches of circumventing can be identified but as the product gets implemented in more deployments, the re-architected product might end up in the current state.

Complete Build Approach

Every product company has the similar challenges as they need to handle different dimensions of functionality, browsers, databases, operating system etc.
Most of the product companies use metadata driven approach for building their web based products. Metadata is used to drive the application using the run time patterns of dynamically generating the UI layer and making the other layers decoupled by using xml or generic attribute based entity patterns.
Complete code generator approach provides challenges for reverse engineering, collating the customizations, upgrades and maintenance. To tackle this, product companies typically build a user interface for controlling and capturing the customizations instead of manual edits of code. Custom modules are provided in the application for modifying/creating different variants. Product line engineering approach which is on the extreme end of the spectrum proposes domain specific languages for customizations.

Recommendation

To satisfy the various conflicting ends of goal pyramid Functionality/Maintenance/Upgrades/ Customization, a hybrid approach of selective code generation is recommended. Hybrid approach will have the capability of reverse engineering, dynamic generation of code wherever possible using run time metadata and controlling customizations wherever possible using the metadata tool management tool.

About the author