EIN 6133 Enterprise Engineering Chin-Sheng Chen Florida International University

T8: Enterprise Systems Modeling and Models Systems modeling tools Systems modeling tools Enterprise models Enterprise models

Reference Object-oriented Modeling and Design, by James Rumbaugh, et al., Prentice Hall, 1991, ISBN Object-oriented Modeling and Design, by James Rumbaugh, et al., Prentice Hall, 1991, ISBN Chapters 2 and 3, Handbook of Enterprise Architecture Chapters 2 and 3, Handbook of Enterprise Architecture

The ESE Framework – Re-visit Enterprise element WorkDecisionResourceInformation System facet Strategy Competency (capability) CapacityStructure Engineering activity SpecificationAnalysisDesignimplementation Performance measure QualityTimeCost Benefit (profit)

Traditional modeling tools Physical simulators Physical simulators –Use of physical (or in combination with virtual) devices Math modeling tools Math modeling tools –Math programming (system specifications) –Queuing networks (system performance) (Computer graphic) charting tools (Computer graphic) charting tools –ABC flow-charter –Visio

Computer-based simulation modeling tools Computer languages Computer languages –Java, VB, C# Macro programs Macro programs –GASP, GPSS –Simen, ARINA, SLAM –AutoMod, Quest Network Network –Petri Net, –Neural networks

Information systems modeling tools IDEF IDEF –IDEF0 (activities) –IDEF1x (information) –IDEF2x (dynamics) OMT OMT –Functional model –Object model –Dynamic model

OMT Concepts (1) There are 4 system development stages: analysis, system design, implementation design, and implementation. There are 4 system development stages: analysis, system design, implementation design, and implementation. OMT is to capture the concepts of a system, rather than its implementation OMT is to capture the concepts of a system, rather than its implementation The three models are orthogonal parts of the description of a complete system and are cross- linked. The object model is most fundamental, because it describes what changes (or transforms) before when (dynamic model) or how (functional model) it changes. The three models are orthogonal parts of the description of a complete system and are cross- linked. The object model is most fundamental, because it describes what changes (or transforms) before when (dynamic model) or how (functional model) it changes.

OMT concepts (2) - common themes Abstraction, Abstraction, Encapsulation, Encapsulation, Combining data and behavior, Combining data and behavior, Sharing with emphasis on object structure (not procedure structure), and Sharing with emphasis on object structure (not procedure structure), and Synergy (consistence in terms of ID, classification, polymorphism, and inheritance) Synergy (consistence in terms of ID, classification, polymorphism, and inheritance)

OMT concepts (3) - Functional model It describes the data value transformations within a system. It describes the data value transformations within a system. The functional model contains data flow diagrams. The functional model contains data flow diagrams. –A data flow diagram is a graph whose nodes are processes and whose arcs are data flows.

OMT concepts (4) - object model It describes the static structure of the objects in a system and their relationships. It describes the static structure of the objects in a system and their relationships. The object model contains object diagrams. The object model contains object diagrams. –An object diagram is a graph whose nodes are object classes and whose arcs are relationships among classes.

OMT concepts (5) - Dynamic model It describes the aspects of a system that change over time and is used to specify and implement the control aspects of a system. It describes the aspects of a system that change over time and is used to specify and implement the control aspects of a system. The dynamic model contains state diagrams. The dynamic model contains state diagrams. –A state diagram is a graph whose nodes are states and whose arcs are transitions between states caused by events.

Relationship among the three models IDEF0/functional model IDEF0/functional model –The input to an activity is usually a user interface for data entry –The output to an activity is usually a user interface for a report, though the output may be a write/update to a database. –ICOM Material is an input object. Material is an input object. Product/process data are output objects. Product/process data are output objects. Rules/regulations and SOPs are constraints. Rules/regulations and SOPs are constraints. Resources/tools and methods are mechanisms. Resources/tools and methods are mechanisms. IDEF1/object model IDEF1/object model –The collection of the ICOM of an IDEF activity model constitutes an inclusive foundation for the object model. IDEF2/dynamics model IDEF2/dynamics model –Each object requires a state diagram to define/govern its life-cycle behavior. –A triggering event is associated with each transition from one state to another. One state may transform to multiple states, depending on the triggering event.

Related enterprise architectures (1) Purdue Enterprise Reference Architecture (PERA), Purdue Enterprise Reference Architecture (PERA), –by Williams, at Purdue University in GRAI Integrated Methodology (GIM) GRAI Integrated Methodology (GIM) –– a flattened version of IMPACS (integrated manufacturing planning and control system), by the GRAI Lab at the University of Bordeaux in France, 1984 Computer Integrated Manufacturing Open System Architecture (CIMOSA) Computer Integrated Manufacturing Open System Architecture (CIMOSA) –by the AMICE Consortium under ESPRIT, 1988 Zackman’s framework for information systems architecture, Zackman’s framework for information systems architecture, –by Zackman at IBM in 1987 C 4 ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance), C 4 ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance), –by Architecture Working Group (DOD) in ARIS (Architecture for Information Systems), ARIS (Architecture for Information Systems), –by Scheer in 1999

Related enterprise architectures (2) Generic Enterprise Reference Architecture and Methodology (GERAM) Generic Enterprise Reference Architecture and Methodology (GERAM) –by an IFIP-IFAC joint task force on architecture for enterprise integration, , consisting of: GERA (generic enterprise reference architecture) GERA (generic enterprise reference architecture) GEEM (generic enterprise engineering methodology) GEEM (generic enterprise engineering methodology) GEMT&L (generic enterprise modeling tools and languages) GEMT&L (generic enterprise modeling tools and languages)

GERAM (1) - Background Enterprise Integration (EI) history Enterprise Integration (EI) history –EI has evolved since 19 th century, from the need of integrating information and material flow throughout an enterprise. Automation history Automation history –Since 1960’s, it was worked in two separate areas of manufacturing (design and production) and business support. –In the 80’s, efforts were started to integrate information and material flows with human elements recognized as an integral part of enterprise operation Two approaches emerged to respond to this challenge. Two approaches emerged to respond to this challenge. –Business approach Based on generic models or designs (architectures) that could subsequently be implemented as information systems products, incorporating most or all information processing tasks in the enterprise (especially its management). The resulting systems were called ERP systems. At the same time, the effort in the CIM reference models failed to achieve an industry-wide acceptance. Based on generic models or designs (architectures) that could subsequently be implemented as information systems products, incorporating most or all information processing tasks in the enterprise (especially its management). The resulting systems were called ERP systems. At the same time, the effort in the CIM reference models failed to achieve an industry-wide acceptance. –Engineering approach – enterprise engineering Based on life-cycle approach. To create an integrated enterprise, the creation activities (thus methodologies) must extend to the whole of the life of the enterprise form its inception till its de-commission. Based on life-cycle approach. To create an integrated enterprise, the creation activities (thus methodologies) must extend to the whole of the life of the enterprise form its inception till its de-commission. GERAM history GERAM history –IFIF and IFAC established a joint force in 1992 to review existing approaches to EI. –It was led by Professors Williams and then Bernus and lasted for 10 years

GERAM (2) - Introduction GERA + Methodology GERA + Methodology It defines a tool-kit of concepts for designing and maintaining enterprises for their life history. It defines a tool-kit of concepts for designing and maintaining enterprises for their life history. It is meant to organize existing enterprise integration knowledge. It is meant to organize existing enterprise integration knowledge. It facilitates the unification of methods of several disciplines used in the change (of life cycle) process, including IE, management science, control engineering, communication and information technology, to allow their combined use. It facilitates the unification of methods of several disciplines used in the change (of life cycle) process, including IE, management science, control engineering, communication and information technology, to allow their combined use. It unifies the two distinct approaches to EI: those based on product models and on business process design. It unifies the two distinct approaches to EI: those based on product models and on business process design. It also offers new insights into the project management of EI and the relationship of integration with other enterprise strategic activities. It also offers new insights into the project management of EI and the relationship of integration with other enterprise strategic activities. It recognizes continuous improvement process of the enterprise operation with feedback loops based on mission and performance indicators, to adapt to changes in the market, technology, and society. It recognizes continuous improvement process of the enterprise operation with feedback loops based on mission and performance indicators, to adapt to changes in the market, technology, and society.

GERAM (3) - It considers Life cycle Life cycle Life cycle –The cycle from life (inception) to death (de-commission). Life history Life history –History (instantiation) of a life

GERAM (4) - It considers feedback Feedback Feedback –It recognizes and identifies feedback loops on various levels of enterprise performance as they relate to products, mission, and meaning. –To achieve such feedback, performance indicators and evaluation criteria of the change impact on process and organization are required. –It is the prerequisite for the continuous improvement process of the enterprise operation and its adaptation to the changes in the relevant market, technology, and society. GERAM views enterprise models as an essential component of EE/I GERAM views enterprise models as an essential component of EE/I

GERAM - Enterprise integration (EI) and enterprise engineering (EE) EI definition, by GERAM EI definition, by GERAM –About breaking down organizational barriers and improving interoperability to create synergy within the enterprise to operate more efficiently and adaptively. EE Definition, by GERAM EE Definition, by GERAM –A discipline that organizes all knowledge that is needed to identify the need for change in enterprises and to carry out that change expediently and professionally. –A collection of tools and methods which one can use to design and continually maintain an integrated state of an enterprise.

GERAM Framework GERA (generalized enterprise reference architecture) employs -> EEM (enterprise engineering methodology) utilizes -> EML (enterprise modeling languages) implemented in -> EET (enterprise engineering tools) along with support of PEM (partial enterprise models) PEM (partial enterprise models) GEMC (generic enterprise modeling concepts) GEMC (generic enterprise modeling concepts) used to build -> EM (enterprise models) with EMO (enterprise modules) with EMO (enterprise modules) used to implement -> EOS (enterprise operational systems)

GERAM framework components - GERA A set of enterprise related concepts for use in EE/I A set of enterprise related concepts for use in EE/I –Human oriented concepts To describe the role of humans an integral part of an enterprise org. and operation To describe the role of humans an integral part of an enterprise org. and operation To support humans during enterprise design, construction, and change. To support humans during enterprise design, construction, and change. –Process oriented concepts Describe the business process of the enterprise Describe the business process of the enterprise –Technology oriented concepts Describe the business-process-supporting technology in the EE or enterprise operation efforts (i.e., modeling and model-use support) Describe the business-process-supporting technology in the EE or enterprise operation efforts (i.e., modeling and model-use support)

GERAM framework components - Enterprise engineering methodology (EEM) Describes the process of EE/I Describes the process of EE/I –May be expressed in the form of a process model or structured procedure with detailed instructions for each EE/A activity An EEM emphasis: An EEM emphasis: 1.Human factor Automat-ability, human-izability, and extent of automation Automat-ability, human-izability, and extent of automation 2.Project management In three phases: start-up, control, and termination In three phases: start-up, control, and termination 3.Economic evaluation in three steps Calculation of the cost of the solution Calculation of the cost of the solution Comparison of the solution costs to the budget Comparison of the solution costs to the budget Performance measures of the solution Performance measures of the solution

GERAM framework components - Enterprise modeling languages (EMLs) Define the generic modeling constructs for enterprise modeling adapted to the needs of people creating and using enterprise models. Define the generic modeling constructs for enterprise modeling adapted to the needs of people creating and using enterprise models. Provide constructs to describe and model human roles, operational processes and their functional contents. Provide constructs to describe and model human roles, operational processes and their functional contents.

GERAM framework components - Generic enterprise modeling concepts (GEMCs) Define and formalize the most generic concepts of enterprise modeling. Define and formalize the most generic concepts of enterprise modeling. May be defined in various ways: May be defined in various ways: –Natural language explaining the meaning of modeling concepts (glossaries) explaining the meaning of modeling concepts (glossaries) –Some form of meta model (E/R meta schema) describing the relationship among modeling concepts available in enterprise modeling languages. describing the relationship among modeling concepts available in enterprise modeling languages. –Ontological theories defining the meaning (semantics) of enterprise modeling languages defining the meaning (semantics) of enterprise modeling languages To improve the analytic capability of engineering tools, and through them the usefulness of enterprise models. To improve the analytic capability of engineering tools, and through them the usefulness of enterprise models. These theories are usually built inside the engineering tools These theories are usually built inside the engineering tools

GERAM framework components - Partial enterprise models (PEMs) Are re-usable models Are re-usable models Capture characteristics common to many enterprise in one or more industries Capture characteristics common to many enterprise in one or more industries Common ones are Common ones are –Partial human role models (skills and competencies in enterprise operation and management) –Partial (operational) process models (functionality and behavior –Partial technology models (e.g., process plan for manufacturing) Partial IT/infrastructure models (e.g., IT, energy, services, etc.) Partial IT/infrastructure models (e.g., IT, energy, services, etc.) Also known as reference models, or type I reference architectures Also known as reference models, or type I reference architectures –Note: Life-cycle architectures such as GERA is referred to as type II reference architecture

GERAM framework components - Generic enterprise modeling concepts (GEMC) Most generically used concepts and definition of enterprise integration and modeling Most generically used concepts and definition of enterprise integration and modeling Three forms of concepts definition: Three forms of concepts definition: –Glossaries –Meta-models –Ontological theories Guidelines Guidelines –Concepts defined in more than one form of the above must be defined in a mutually consistent way –Those concepts that are used in an enterprise modeling languages must also have at least a definition in the metal model form, but preferably the definition should appear in an ontological theory.

GERAM framework components - Enterprise engineering tools (EETs) Support the processes of EE/I by Support the processes of EE/I by –Implementing an EE methodology –Supporting modeling languages Should provide for analysis, design and use of enterprise models Should provide for analysis, design and use of enterprise models

GERAM framework components - (Particular) enterprise models (EMs) (1) Represent a particular enterprise entity Represent a particular enterprise entity Can be expressed using enterprise modeling languages Can be expressed using enterprise modeling languages Include various designs, models for analysis, and executable models to support the enterprise operation Include various designs, models for analysis, and executable models to support the enterprise operation May include several models describing various aspects (or views) of the enterprise. May include several models describing various aspects (or views) of the enterprise.

GERAM framework components - (Particular) enterprise models (EMs) (2) Notes on EMs Notes on EMs –The goal of enterprise modeling is to create and continuously maintain a model of a particular enterprise entity. –An enterprise model should represent the reality of the enterprise operation according to the requirements of the user and his application –It includes all description, design, and formal models of the enterprise that are prepared in the course of the enterprise’s life history Some uses of enterprise models Some uses of enterprise models –Decision support for evaluating operational alternatives in the EE process, enabling operation analysis and synthesis –Communication tool that enables the mutual understanding of issues. –Model-driven operation control and monitoring for efficient business process execution –Training of new personnel.

GERAM framework components - Enterprise modules (EMOs) Are implementation of partial models Are implementation of partial models Are building blocks that are utilized as common resources in EE/A. Are building blocks that are utilized as common resources in EE/A. Are reusable and could be available in the market place Are reusable and could be available in the market place Common ones are resource modules for humans, machines, equipment, and IT infrastructure Common ones are resource modules for humans, machines, equipment, and IT infrastructure

GERAM framework components - (Particular) enterprise operational system (EOS) Supports the operation of a particular enterprise Supports the operation of a particular enterprise Its implementation is guided by the particular enterprise model which Its implementation is guided by the particular enterprise model which –provides the system specifications and –identifies the enterprise modules used in the implementation of the particular enterprise system.

Three major enterprise information reference architectures Generalized enterprise reference architecture (GERA) Generalized enterprise reference architecture (GERA) Purdue enterprise reference architecture (PERA) Purdue enterprise reference architecture (PERA) Enterprise architecture framework Enterprise architecture framework –By John Zackman

GERA - Three scoping/modeling dimensions Life-cycle dimension Life-cycle dimension –Provides for the controlled modeling process of enterprise entities according to its life cycle Generic-ity dimension Generic-ity dimension –Provides for the controlled particularization (instantiation) process from generic and partial to particular. View dimension View dimension –Provides for the controlled visualization of specific views of the enterprise entity

GERA - Enterprise life-cycle phases (1) Identification Identification –A set of activities that identifies the contents of the enterprise in terms of the nature of its existence, its need and the need for changes. Concept Concept –A set of activities for developing the concepts of the underlying enterprise, including the definition of its mission, vision, values, strategies, objectives, operational concepts, policies, and business plans. Requirements Requirements –A set of activities for developing descriptions of operational requirements of the enterprise, its relevant processes, and the collection of all their functional, behaviroural, information and capacity needs for both production and mgt, whether by humans or machinery.

GERA - Enterprise life-cycle phases (2) Design Design –A set of activities that support the specification of the enterprise with all of its components that satisfy the enterprise requirements. They include the design of all human tasks, all machine tasks, and operational processes (including identification of necessary information and resources for mfg. information, communication, control and other processing technology) –Sub-phases: preliminary (architectural) design and detailed design Implementation Implementation –A set of activities that define all tasks that must be carried out to build or re-build (manifest) the enterprise. This comprises implementation in the broadest sense, covering Commissioning, purchasing, re-configuring, or developing all software and hardware resources for services, mfg. and control. Commissioning, purchasing, re-configuring, or developing all software and hardware resources for services, mfg. and control. Hiring and training personnel, and developing or changing the human organization. Hiring and training personnel, and developing or changing the human organization. Component testing and validation, system integration, validation, and testing, and releasing into operation Component testing and validation, system integration, validation, and testing, and releasing into operation

GERA - Enterprise life-cycle phases (3) Operation Operation –The activities of the enterprise that are needed during its operation for producing the customers products and service which is its special mission, along with all those tasks needed for monitoring, controlling, and evaluating the operation. –Thus the resources of the enterprise are managed and controlled so as to carry out the processes necessary for the entity to fulfill its mission –Deviations from goals and objectives or any feedback from the environment may lead to requests for change, which includes enterprise re-engineering, continuous improvements of its human and technology resources, its business process, and its organization. Decommission Decommission –The activities needed for disbanding, re-missioning, re-training, redesign, recycling, preservation, transfer, disassembly, or disposal of all or part of the entity at the end of its useful life in operation.

GERA - Enterprise’s entity types (4) Type A – strategic management entity Type A – strategic management entity – such as an (enterprise) engineering project –Very short life cycle Type B – engineering implementation entity Type B – engineering implementation entity –Entity that creates other enterprise entities Type C – enterprise entity Type C – enterprise entity –Entity that produces customers goods and services Type D – product entity Type D – product entity –All products and customers services of enterprise type C Type E – methodology entity Type E – methodology entity –Entity that establishes tasks to support other entities.

GERA - views (1) Entity model contents views Entity model contents views –Function (model of functions and behaviors of business processes) –Information (model) –Organization (of responsibilities and authorizations on entities) –Resource (model) Entity purpose views Entity purpose views –(Customer) service and product views (contents relevant to operation and its results –Management and control views (contents relevant to mgt.) Entity implementation views Entity implementation views –Human activities view (of information related to human tasks) –Automated activities view (of information related to machine tasks) Entity physical manifestation views Entity physical manifestation views –Software view (information resources capable of perform a task set) –Hardware view (physical resources capable to perform a set of tasks)

PERA Layers (life cycle phases) Identification Identification –of the CIM business entity Concept layer Concept layer –mission, vision, and values Definition layer Definition layer –functional requirement Specification layers Specification layers –architectural design Detailed design layer Detailed design layer Manifestation layer Manifestation layer –Implementation Operations layer Operations layer

RowPerspective Constraint Model 1PlannerFinancial/externalScope (an executive summary of system scope, cost, and how it would perform) 2OwnerUsage/policyEnterprise (business) model (business entities, processes and how they interact) 3Designer (analyst)Structure/operationSystem model (data elements and functions that represent business entities and processes) 4BuilderTechnologyTechnology model (adapting information model to the details of programming languages, tools, I/O devices, and others) 5SubcontractorImplementationOut of context models (detailed specifications given to programmers who code modules)

Data (with entity and relation) Function (with function and parameter) Network (with node and link) Scope (planner)List of things important to the business (entity: class of business thing) List of processes the business performs (function: class of business processes) List of location in which the business operates (node: major business location) Enterprise model (owner)ENT/REL diagram (business entity, business constraint) Process flow diagram (business process and resources) Logistics network (business location, business linkage) System model (designer)Data model (data entity and data relationship) Data flow diagram (application function and user view) Distributed system architecture (I/S function, and line characteristics) Technology model (builder)Data design (segment/row; pointers/key) Structure chart (computer function and screen/device format) System architecture (hardware/system software, line specifications) Components (subcontractor) Data definition description (field and address) Program (language statement and control block) Network architecture (address, protocol)

People (agent, work)Time (time, cycle)Motivation (ends, means) ScopeList of organizations/agents important to the business (major org. unit) List of events significant to the business (major business event) List of business goal/strategy (major bus. goal and critical success factor) Enterprise modelOrganization chart (org. unit, work product) Master schedule (business event and bus. cycle) Business plan (business objective and bus. strategy) System modelHuman interface architecture (role, deliverable) Processing structure (system event and processing cycle) Knowledge architecture (criterion, option) Technology modelHuman/technology interface (user, job) Control structure (execute, component cycle) Knowledge design (condition and action) ComponentsSecurity architecture (identity, transaction) Timing definition (interrupt and machine cycle) Knowledge definition (sub condition, step)

Notes:  Of an information system, the 3 columns represent data (entities involved), functions (to be performed) and network (locations and interconnections)  The rows of the framework represent different abstractions from or different ways to describe the real world.  For physical processes in engineering, the 3 columns represent the material, the functions, and the geometry.

T8: Home work Develop a state diagram for a typical machine tool (class) for its life cycle. It should have: Develop a state diagram for a typical machine tool (class) for its life cycle. It should have: –A graphic presentation of the diagram –Definition for each state –Definition for each event that triggers the transition from one state to another. Due date: next week Due date: next week

Comments on T8 HW It is for a class of machine equipment, NOT for a particular machine such as a vending machine. It is for a class of machine equipment, NOT for a particular machine such as a vending machine. Don’t forget it’s for its life cycle from birth to death. Don’t forget it’s for its life cycle from birth to death.