A Survey of New Generation of Enterprise Information System
(Summary)
YU Tong-Ying
EE-Forum.org, 2005-9
Characteristics of Function or Performance of NEIS
Follows are some important functional or performance characteristics which we think the NEIS should have. Today, we have many reasons to believe that will be able to have. Influenced by the "technology-oriented" tendency, some important functional or performance characteristics has not got enough attention even has been despised in the past development of enterprise application. Some OLD conceiving or requirements, have not been inherited or solved in the new concepts.
- Container or Propeller of Management Ideas or Methods
- Scalable or Flexible
- Supporting Enterprise Engineering
- Data, Information, Knowledge and Intelligence
- Well-manageability
- Ease-to-use
System Construction
Though the modular or logic division of actual software may differ widely, but the parts listed here quite possibly be shown as a relatively independent software (or solutions, products) of NEIS. They even may be developed by difference developer. They are
- Enterprise Platform
- Enterprise Database
- Enterprise Engineering Tools
- Enterprise Applied Model
- Enterprise Reference Model
- Additional Modules
- Technical Tools
Three Levels of Requirements Analysis
Level 1. Objective Description and Record - to collect and record the customer requirements or relevant business data faithfully, exactly and roundly.
Level 2. Patterns Induction and Discovery - to carry out inducing and modelling according to some certain modelling methodologies and framework or architecture, and discover as far as possible the patterns or rules that may not obvious and involved in the objective records like as snapshot.
Level 3. Patterns Analysis and Innovation - to summarize the rules which hidden in various existing patterns. to research the dissimilation which is from application to requirements, mine deep principles, forecast change of requirements, find new work (business) mode, create new valuable pattern.
Essential Requirements Analysis and Research (ERAR)
In the field of new technology application, requirements are a kind of dynamic evolutional objective thing. It has own evolutional rules, life cycle and survival environment. It is a part of the undetermined things in the future, and will change because of our intervention (implementation of application). Uncertainty, infantilism is its basic character... The "satisfy user requirements" is not only a find-solving process, even is a study-creation process.
We must carry out comprehensive research around the various factors or changing rules which has influence on the produce and change of requirements. Its objective is to discover and summarize various hidden, possible or future requirements and its evolution rules, and to produce or create new solutions or patterns.
This idea is propounded based on requirements analysis (RA) of the software engineering. It is a natural deepening and sublimation, so we adopted the expression that corresponding to the traditional call, i.e. Essential Requirements Analysis and Research ( ERAR, or may call it Requirements Research for short). We regarded it as "a guide line and methodology framework" at present. It is not restricted in the software field. It also will be suitable for the design or development of any product or service, especially for innovation. We believe that through further develop and enrich, it may be composed a strong multi-layered methodology system with RA or requirements engineering.
ERAR' s Significance for NEIS
For NEIS, it is the key to change “technology-oriented, concept-driven” to “requirements-oriented, technology-driven”. It is the background that we regard MDM/MDS as the key both requirement and realization. ERAR will always be the important base of the NEIS development and research.
Model-Driven Mechanism (MDM)
Model-Driven Mechanism (MDM) is a mode or approach to realize and control
system (or its function and behaviour), i.e. based on model to run, realize
or control expected thing modelled – system, or function and behaviour. The
model will have independency, it is independent of the representing,
storing, transmitting, achieving or realizing process or methods. In brief,
MDM makes all or part of functions and behaviours (or the structure and form
) of the
system to be controlled or mastered by model. Understand from the view of
system theory, the position of MDM is similar to feedback mechanism.
Model-Driven System (MDS)
We call a system is full model-driven system (MDS) if all the functions and behaviours can be defined, controlled and changed through MDM in run-time. In brief, MDS is a system that main functions are controlled or realized with MDM.
Through introduce MDM, we can understand and differentiate MDA and the MDS propounded by me in a more unified and general level.
The Basic Needs of Enough Effective Enterprise Modelling Means
Expression ability: be able to represent whole enterprise fully – not only include information or business process, but also business rules, organization, equipment or resource, cost and so on the all kinds of elements;
Applicability: the representation should be able to be understood to the maximum extent for enterprise management or functionaries (or/and enterprise engineer), and no needs to grasp a lot of extra knowledge or skills (for example, about software development);
Exactness: As the foundation of an engineering system, it must have enough exactness, and can be recorded, modified, transmitted precisely and correctly;
Integration with application system: the result of EE modelling should be able to reflect in enterprise application system directly, but does not pass through again a software development or modify process that is usually complicated, time-uncertain and in the second or third party.
Enterprise Engineering (EE), Enterprise Modelling and NEIS
EE’s development should and can be linked to enterprise modelling and its supporting platform closely, and combined with the business platform of enterprise. So, even determined the accrete relation between EE and NEIS that interdependent and promoted each other. Without enterprise modelling, there is no real EE. And even possessed of enterprise modelling and planning tools, there must also be a whole set of enterprises design, planning, transforming principles and methodologies to really work its magic. The latter's source is just the EE discipline or knowledge, methodology system that we hoping to establish.
In brief, we do not regard EE as the accessory of enterprises IT application, also do not only regard enterprise modelling as a kind of means to establish EIS. Enterprise modelling is the bridge which joins EE and EIS. To support EE and EIS together to the maximum extent is ideal but rational goal for enterprise modelling. It will also bring the enormous benefit to user in using.
From: YU Tong-Ying. A Survey of New Generation of Enterprise Information System. http://www.ee-forum.org, 2005
(Download full text in Chinese or in English. The English text is poor. Perhaps it is the time you would consider to learn Chinese :)