How We Do It  >   KnowledgeFrame  >   Live Meta-Data and Business Rules  

Live Meta-Data and Business Rules

Although many excellent development frameworks exist in the Java and Web space today, we believe that KnowledgeFrame is quite unique in its focus on Live Meta-Data and Live Business Rules. This focus allows KF to address the issues of development of complex enterprise applications very effectively, shortening the development cycles and addressing perhaps the most frequent cause of project failures – miscommunication between the business user community and the development team.

Meta-Data and Business Rules are so important because this is what the business users and system analysts think about, and because that’s how business requirements tend to be expressed. It is very rare for project specifications to translate directly to meaningful algorithms and data patterns, but it is quite common to hear requirements like "this type of invoice must contain the following data" or "shipping date must be always at least 3 days after order date".

Meta-Data

By building the solution architecture around meta-data and business rules, KF allows the analysts and users to inspect the definitions very early in the projects, when the system is still very flexible and changes do not yet require expensive roll-back of sunken effort.

KF also allows the analysts to be continuously involved throughout the lifetime of the project, and be able to review the compliance of the implementation with the system goals and high-level design, helping to avoid the "handover to coding" syndrome and gaps between design and implementation.

Perhaps even more important, the ability to quickly visualize business objects in screens and reports allows the developers to communicate effectively with business users via live prototypes, instead of abstract conceptual diagrams, which many business users find very challenging to validate.

In one situation, KF was used to validate a data model, which had been more than 2 years in development, and which had been formally signed off. It took a one-week interactive workshop for business users to recognize discrepancies between the data model and the business requirements, and invalidate that data model. In the following 2 weeks, quick KF meta-data changes were used to iteratively evolve the model into something that could be used as a basis of the subsequent implementation, with changes sometimes performed live during the workshop.

Live Meta-Data

KF makes one important distinction in its insistence that the meta-data has to be "live". The term "live" refers to the fact that meta-data lives and is accessible in the runtime environment of the application, and any application component can refer to it (and, in certain scenarios, even change it) at any point of time. KF specification contains extensive definitions about how meta-data is represented at runtime, while allowing complete flexibility to how the meta-data is created, updated or referenced.

There is another twist on the term "live", which says that "meta-data lives with individual objects". This means that while common meta-data can be defined for a whole application class – e.g. a Business Object – individual instances of that class can override some meta-data values.

Both definitions of "live" meta-data have several benefits to the application development:

• Meta-Data based Business Objects can be built either statically (by coding meta-data values in Java, and compiling them with the rest of the application), or dynamically, constructed at runtime from values provided by various tools, repositories and protocols. That allows productive code-centric application development, and also dynamic flexible service-oriented applications, where data access must be integrated live with a constantly changing definitions at central or business partner site.
• Development of standard components – screens, reports, Web Services interfaces etc. – becomes significantly more productive. Instead of custom-coding each screen and report, a common user interface “painter” can read the meta-data in Business Object classes, and paint complete functional screens on the fly.
• Declarative business rules (or business rules with declarative "signatures", but complex custom-coded "bodies") are invoked automatically in event handlers predefined by the framework, thus providing a classification system for business rules which can be easily traced (audited, debugged) against the runtime behavior. This approach helps with a major problem that has been plaguing rule-based systems (expert systems, or earlier "artificial intelligence" systems) for years – very difficult testing and debugging.
• Flexible applications can use “smart data” to adapt to local conditions. Imagine an Order Entry application for sales of pharmaceutical products in multiple countries. Not only does each country have a different way of calculating sales tax and import duties, but each country also have a different set of regulatory requirements, for different products – who is allowed to order certain types of medication, what government reporting must be done on each shipment, and many other things. For 5 customer categories, 10 product categories and 20 countries, we may have up to 1,000 alternatives for data entry and processing – way beyond what can be handled through the deeply-nested IF / ELSE statements. And if some of the conditions can change frequently, and the system has to comply quickly, any hard-coded solution to this problem will fail. However, meta-data which lives with the Business Object can be populated at the time when the object is built, and then interpreted by the user interface "painter" and by meta-data-aware business logic.

Copyright © T4Bi. Email: contact@t4bi.com