Model driven IT systems development with code generation is today used in several, mostly technical, application areas. However, for large IT based Information Systems (ITbIS) it is still quite uncommon. An innovative case of low cost and high quality ITbIS is presented along with the model driven framework applied. This innovation is made possible by a coherent model driven approach with integrated method and tool support for the complete development and maintenance cycles of an ITbIS. For over 20 years and still, the FMV ERP system has been designed, extended and modi ed in pace with changes in the organization as well as disruptive changes in information technology.
Actors
Organization
Authorization Value creation
Value chains 100 €
XML Business phenomena
Reality
Phenomena map Views Business Knowledge Model ITbIS Usage Technology
ITbIS
Engine
User Authentication & Authorization
User Views
Data Interchange
Model Statements
Software Platform Hardware Platform Model (BKM) is from a business perspective, formalized business knowledge. From a technical perspective, the BKM is an object oriented declarative model describing information structure, information processing and information rules, including information access rules. Views are de ned declaratively and connected to model elements, which in runtime operates as windows for accessing information in the ITbIS. There are di erent types of views: graphical user interface; word processor interface; document generation; report generation and data interchange views. Each type of view is described either with a tool or a language.
Building an ITbIS with CoreEAF is done solely by declaring a BKM and it's views, excluding programming in the traditional sense. 2
ITbIS Case { ERP System for Defence Material Acquisition The Swedish Defence Material Administration's (FMV's) Enterprise Resource Planning (ERP) system called FMV-Core, Fig. 2, is the most extensive system out of ve, built and executed with the current version of CoreEAF. Applying the CoreEAF for FMV-Core is by now a proven innovation for providing ITbIS to an organization at low cost, low error rate, short lead time and high requirement ful llment. This innovation is made possible by coherent design support for consistent model driven development and change actions throughout the ITbIS life cycle, along with a coherent runtime environment for ITBIS execution with full consistency between models and target system behavior.
R&D Suppliers
EDI
FMV - Defence Material Administration Planning Projects Purchase Back Office
FMV-Core
Operations Administration
FMV has ongoing material acquisition projects worth about 6 Billion Euros and a turnover of 2 Billion Euros per year. FMV-Core is an ITbIS with 1.200 users and handles information in FMV's core business. This includes project planning, project execution and accounting as well as complex purchasing processes from RFQ, tenders, complex contract drafting to delivery and payments. FMV-Core is integrated with several other IT systems, one of which is the Swedish Armed Forces SAP based ERP system (PRIO), using the integration facility CoreCom of the CoreEAF information engine.
Regarding design metrics, the FMV-Core system is de ned with 33.000 declarative statements, whereof 13.000 statements de ne the BKM and 20.000 dene views. FMV-Core BKM includes 230 business phenomena with 7 levels of generalization and 400 relations. The phenomena altogether carry 3000 value attributes all managed by 5600 rules and calculations.
This level of content complexity implemented in e.g. standard systems would
typically include millions (>1.000.000) of lines of program code. For instance
SAP is built with more than 300.000.000 lines of code [
Modeling the Enterprise { Method, Language and Tools The key concepts applied to implement coherent support for consistent model driven design of ITbIS are described below. 3.1
Business Phenomena { Understanding the Reality of an Organization The rst and most profound aspect is the business phenomena aspect. The model of business phenomena shall directly and only directly correspond to actual business phenomena and be labelled with the business terminology.
Concrete as well as abstract business phenomena such as agreements, projects, services, etc. need to be understood and documented in the model. It is often challenging to understand and document abstract phenomena as they only exist in the minds of people and are constantly undergoing changes and rede nitions. Thus, business phenomena modelling requires fundamental understanding of human perception and of how to capture human knowledge into formal models using a modelling language. 3.2
Value Creation { What is Being Achieved The second aspect is the value creation aspect, documented with value chains, as in Fig. 3.
Start state Process Activities Transition
Desired final state Less desired final states
Some of the business phenomena can be considered more or less static, i.e., they exist in the business and do not undergo any transformation of value. Other phenomena undergo value transformations, such as products being assembled in a factory. Also intangible phenomena undergo value transformations and are most likely the only kind of value transforming phenomena in organizations that produce something other than tangible products.
Examples of value transforming intangible phenomena are business agreements such as sales agreements or purchase agreements. In the public sector we can nd value transforming phenomena such as claims and license applications.
For each value transforming phenomenon, a state diagram is de ned representing the value chain of the phenomenon. The value chain has a start state and typically one or more nal states, where one of the nal states represents the desired nal state of the value transformation. The intermediate states represent steps towards and sometimes away from the desired nal state.
E.g. the value chain of a sales agreement can be composed of the states suggested, quoted, rejected, ordered, delivered, returned, paid and refunded, where suggested is the start state and paid is the desired nal state. Note that a state transition such as quoted to ordered represents a positive value progression and quoted to rejected represent a negative value progression.
Connected to each state is a set of activities to be performed in order to reach one of the next states of the value chain. E.g. the transition ordered to delivered could be connected to several activities such as picking items in warehouse, package items, attach address label, give to post o ce, etc. 3.3
Organizational Structure { Roles, Responsibilities and Actors The third aspect is the organizational structure. Business roles with responsibilities are added and connected to value chains of value transforming phenomena in the model.
Business roles can have two di erent kinds of responsibilities in relation to the value chains. Firstly, a role can have the overall responsibility for a certain phenomenon to progress to certain states. Secondly, for performing activities moving the phenomenon closer to a following state in the value chain. Roles can further be grouped into organizational structures representing e.g. management structure, team structure etc., depending on phenomenon, activity and organizational policies.
Finally, actors can be connected to the roles. Actors are either individuals e.g. sta members of the organization, customers, suppliers, etc. or machines performing some activity. Machines could be mechanical machines or IT systems. 3.4
Core Model Language (CML) { How to Describe BKM Core BKMs are created and maintained in modelling tools allowing graphical editing and navigation of the model. The tools are based on a declarative language, Core Model Language (CML)
CML formalism follows the basic principles of a strongly typed class based object oriented (OO) language. However, CML is declarative and all data processing is described with parameterless functions without side e ects (expressions). I.e. the value of an attribute can only be set by the attribute's value function, not by instructions in several di erent methods in the class. This means that each calculated value of the system is clearly de ned in one place and one place only, usually as a single line of declarative statement. This gives a great advantage in terms of changeability, predictability and fault localisation. A change in one expression will only a ect the values of one attribute or if a value of an attribute is incorrect, the problem will be located in its value expression.
In CML the OO class concept is called phenomenon.
Data container: A phenomenon has attributes which when instantiated can hold values.
Generalization: A phenomenon can be part of a generalization { specialization hierarchy.
Encapsulation: Stronger than in classic OO since attribute values can only be set by the attribute's value function, not by other components of the phenomenon (class).
Polymorphism: An attribute can have di erent de nitions in a generalization { specialization hierarchy.
Additional structural components have been added to the traditional OO concept, such as relation, view and change permissions, value chain, activity, role and organizational entity.
Examples of attribute and value declarations (identi ers in ' ') phenomenon 'person' attribute 'full name' value 'given name' + " " + 'family name' phenomenon 'order' attribute 'order total' value sum 'items' [not 'complimentary'].'price' The language, as shown, de nes data ow graphs not execution order. It is up to the underlying information engine to resolve execution order depending on events in the data ow graphs. 3.5
Tools for Enterprise Modeling There are two tools which can be used for modeling as described in sections 3.1-3.4. They t in to the CoreEAF as shown in Fig. 4.
Browser: WEB based environment for creating and viewing models. Builder: Windows based environment for creating and viewing models. 4
Modeling the ITbIS { Tools and Languages Once the business model is created it is time to design an ITbIS that meet the information management needs of the organization and its people.
Designing the ITbIS essentially means modeling various views of the BKM. For this purpose various tools and languages are used, which assumes and is connected to the BKM. The design tools and languages architecture is shown in Fig. 4.
AppBuilder: Tool for building a component based graphical user interface, connected to a model, i.e. an application.
Reporter: User tool for creating reports with exible search and result criteria. IDoc-L: XML based language to de ne document oriented interactive user interface using MS-Word as platform.
Business Knowledge Documentation and Governance
View Tools and Languages
GNU C++
Doc-L
Scripts
Doc-L: XML based language to de ne paper documents from model data. CoreCom-L: XML based language to de ne import/export of model data in XML or other text formats.
Process-L: XML based scripting language to monitor and modify data in the model based system.
Target Code The tool chain is based on C++ and executable on Linux and MS-Window. The script languages are CoreEAF speci c. 5
ITbIS Runtime Components Information Engine: The Information Engine handles persistence, information consistency, serving multiple users with real-time information while maintaining transactional integrity over a distributed network of resources, information security and a timeline for each phenomenon and its context. The information engine is programmed in C++ and uses an SQL database engine for data storage. Applications: Model, information engine, view engines and views created by AppBuilder are compiled together into user applications. In an ITbIS there can be several di erent applications, where all applications have the same model but di erent views.
Dynamic data input and output: There are four dynamic view engines active in runtime. One view engine which interprets report de nitions and three view engines which run XML de ned scripts one for each type of view tool: IDoc-L, Doc-L, CoreCom-L.
Management (Mgmt): Component for administrating users roles in the organization and for authorization in the ITbIS. 6
Current Status and Future Developments of CoreEAF Ongoing research and publication on Model Driven ITbIS Design (MDID) include a case study and subsequent thematic studies on FMV Core.
A community for collaboration on knowledge development on MDID is being formed with academia, industry and public sector. The community will also provide knowledge resources and a web based platform for tools and experimentation.
Genicore is currently developing a new web based modeling tool with a lightweight information engine and auto generated UI for MDID to enable education and training.