EIN 6133 Enterprise Engineering

1. EIN 6133Enterprise Engineering Chin-Sheng Chen Florida International University

2. T8: Enterprise Systems Modeling and Models • Systems modeling tools • Enterprise models

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

4. The ESE Framework –Re-visit

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

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

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

8. OMT Concepts (1) • 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 • 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.

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

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

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

12. 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. • 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.

13. Relationship among the three models • 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. • Product/process data are output objects. • Rules/regulations and SOPs are constraints. • Resources/tools and methods are mechanisms. • IDEF1/object model • The collection of the ICOM of an IDEF activity model constitutes an inclusive foundation for the object 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.

14. Related enterprise architectures (1) • Purdue Enterprise Reference Architecture (PERA), • by Williams, at Purdue University in 1988. • 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) • by the AMICE Consortium under ESPRIT, 1988 • Zackman’s framework for information systems architecture, • by Zackman at IBM in 1987 • C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance), • by Architecture Working Group (DOD) in 1997. • ARIS (Architecture for Information Systems), • by Scheer in 1999

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

16. GERAM (1)- Background • Enterprise Integration (EI) history • EI has evolved since 19th century, from the need of integrating information and material flow throughout an enterprise. • 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. • 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. • 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. • 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

17. GERAM (2)- Introduction • GERA + Methodology • 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 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 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.

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

19. GERAM (4)- It considers 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

20. GERAM- Enterprise integration (EI) and enterprise engineering (EE) • 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 • 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.

21. 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) GEMC (generic enterprise modeling concepts) used to build -> EM (enterprise models) with EMO (enterprise modules) used to implement -> EOS (enterprise operational systems)

22. GERAM framework components- GERA • 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 support humans during enterprise design, construction, and change. • Process oriented concepts • 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)

23. GERAM framework components- Enterprise engineering methodology (EEM) • 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: • Human factor • Automat-ability, human-izability, and extent of automation • Project management • In three phases: start-up, control, and termination • Economic evaluation in three steps • Calculation of the cost of the solution • Comparison of the solution costs to the budget • Performance measures of the solution

24. 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. • Provide constructs to describe and model human roles, operational processes and their functional contents.

25. GERAM framework components- Generic enterprise modeling concepts (GEMCs) • Define and formalize the most generic concepts of enterprise modeling. • May be defined in various ways: • Natural language • 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. • Ontological theories • defining the meaning (semantics) of enterprise modeling languages • 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

26. GERAM framework components- Partial enterprise models (PEMs) • Are re-usable models • Capture characteristics common to many enterprise in one or more industries • 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.) • 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

27. GERAM framework components- Generic enterprise modeling concepts (GEMC) • Most generically used concepts and definition of enterprise integration and modeling • Three forms of concepts definition: • Glossaries • Meta-models • Ontological theories • 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.

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

29. GERAM framework components- (Particular) enterprise models (EMs) (1) • Represent a particular enterprise entity • Can be expressed using enterprise modeling languages • 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.

30. GERAM framework components- (Particular) enterprise models (EMs) (2) • 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 • 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.

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

32. GERAM framework components- (Particular) enterprise operational system (EOS) • Supports the operation of a particular enterprise • 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.

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

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

35. GERA - Enterprise life-cycle phases (1) • 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 • 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 • 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.

36. GERA - Enterprise life-cycle phases (2) • 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 • 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. • Hiring and training personnel, and developing or changing the human organization. • Component testing and validation, system integration, validation, and testing, and releasing into operation

37. GERA - Enterprise life-cycle phases (3) • 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 • 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.

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

39. GERA - views (1) • 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 • (Customer) service and product views (contents relevant to operation and its results • Management and control views (contents relevant to mgt.) • 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 • Software view (information resources capable of perform a task set) • Hardware view (physical resources capable to perform a set of tasks)

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

41. Row Perspective Constraint Model 1 Planner Financial/external Scope (an executive summary of system scope, cost, and how it would perform) 2 Owner Usage/policy Enterprise (business) model (business entities, processes and how they interact) 3 Designer (analyst) Structure/operation System model (data elements and functions that represent business entities and processes) 4 Builder Technology Technology model (adapting information model to the details of programming languages, tools, I/O devices, and others) 5 Subcontractor Implementation Out of context models (detailed specifications given to programmers who code modules)

42. 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)

43. People (agent, work) Time (time, cycle) Motivation (ends, means) Scope List 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 model Organization chart (org. unit, work product) Master schedule (business event and bus. cycle) Business plan (business objective and bus. strategy) System model Human interface architecture (role, deliverable) Processing structure (system event and processing cycle) Knowledge architecture (criterion, option) Technology model Human/technology interface (user, job) Control structure (execute, component cycle) Knowledge design (condition and action) Components Security architecture (identity, transaction) Timing definition (interrupt and machine cycle) Knowledge definition (sub condition, step)

44. 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.

45. T8: Home work • 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

46. Comments on T8 HW • 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.