Presentation is loading. Please wait.

Presentation is loading. Please wait.

The MacNeal-Schwendler Corporation Systems Architect Page 1 Interoperability: Examples from MSC’s Architectural Directions.

Similar presentations


Presentation on theme: "The MacNeal-Schwendler Corporation Systems Architect Page 1 Interoperability: Examples from MSC’s Architectural Directions."— Presentation transcript:

1 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 1 Interoperability: Examples from MSC’s Architectural Directions

2 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 2 Architecture n Architecture is never fully described by a single drawing or representation n There are always multiple Aspects of an Architecture which needs to be described n Take a house for example: Plat, Layout Drawing, Framing Diagram,... n The same is true with Systems Architecture

3 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 3 Aspects of Systems Architecture n Business Architecture n Application Architecture n Application Integration Architecture n Service (Function) Architecture n Execution Architecture n Administrative Architecture n Physical Architecture

4 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 4 Business Architecture Goal: Assure System Supports Business Functions Efficiently; the Constitution  Structure of the Business Process  Tasks with Information Consumption/Production  Business Task to Application ID/Mapping  Identify Major and “Mini” Apps needed for task  Data Consumption/Production  Data Sharing  Among Business Units, Tasks and External Enterprises (Customers/Partners/Vendors)

5 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 5 Application Architecture n Strategy and structures for crafting point-of-use applications. n Goals: Rapid Development of Production Quality Applications  Re-Use and Sharing of Production Quality Functions  Prepackaged, Reusable, GUI Widgets

6 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 6 Example Architectural Goals of an Enterprise Materials Database n Business  Provide Uniform Material Reference Across the Business Process n Application Integration  Provide Access to Bonafide Material Properties Consistently across all Engineering Applications

7 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 7 Concrete Business/Technical Objects Business Abstraction Information Technology Abstraction Current Apps The Abstraction Gap

8 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 8 Bad Effects of Abstraction Gap n Business Process is Highly Dependent on Particular Applications n Small Changes in the Business Process may Require Vast Changes in the Application that may be Expensive or Impossible n The Cost of Changes in the Infrastructure are not Proportional to the Degree of Change in the Business Process n The Application Holds the Business Process Hostage!

9 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 9 Spanning the Abstraction Gap n Object Technology permits the definition of large granularity objects with complex methods. n Objects can be defined with a one to one correspondence with the business objects. n Application programming can be done in terms of the business objects. n Application programming does not require tedious, detailed, field-level programming. n Reprogramming the infrastructure is proportional in effort to Re-Engineering the Business Process.

10 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 10 Task Applications Business Objects Abstract Objects Object Infrastructure Concrete Business/Technical Objects Business Abstraction Information Technology Abstraction Spanning the Abstraction Gap Business Tasks

11 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 11 Service (Functional) Architecture n Infrastructure Services for use by Applications n Move the work out of the applications to the Services n Applications no longer to contain unshareable business rules and algorithms. n Applications responsible for presenting information in the context of the specific business task.

12 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 12 WF PDM PM Example of Service Architecture WF/PDM/PM Integration n Vehicle for Collaboration with NCMS Project Endeavor (concept funding) n Integration of  Workflow  Product Data Management  Project Management n Integrated Object Views n Task-Oriented Data Acquisition

13 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 13 CORBA Applications Workflow Services PDM Services Project Management Services Example of Service Architecture Integration via Infrastructure

14 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 14 Application Integration Architecture n Techniques for “standardizing” the development of “glue code Appl A Appl B n Goals: Facilitate the rapid assimilation of standalone applications into a cooperative interoperable system.

15 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 15 The Monolithic Legacy using the Example of PDM (Product Data Management) n Artificial Boundaries  What is in a Product Data Management System?  What is not in a PDM?  Does a given function belong in PDM, Workflow, or ERP? Does it really matter? n No Engineer wants to be an expert in PDM n Need to make the PDM services oriented toward the Business, and available to all applications n Need to make PDM happen transparently, as a side-effect of normal business (design, analysis,…)

16 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 16 Monolithic Application Task A Task B Task C Integration via Monolithic Applications

17 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 17 Monolithic Application Task A Task B Task C A B C Business Consequences of Monolithic Applications Small Changes in Business Process can Necessitate need for Unanticipated Functionality

18 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 18 Task A Task B Task C Appl AAppl B2Appl CAppl B1 Shift to Small Task Oriented Applications Legacy Application API

19 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 19 Task A Task B Task C Appl AAppl B2Appl CAppl B1 Shift to Business Oriented Infrastructure Legacy Application API Functional Partitionings

20 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 20 Principles of Functional Partitioning: Methods of Object Models Appl AAppl B2Appl CAppl B1 Task A Task B Task C

21 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 21 OMG PDM Enablers n Product Data Management  What is It?  What’s it Contain? n Enablers  Part Structure  Document Management  Effectivity  Change Management  Etc...

22 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 22 Joint PDM Submission Team n MacNeal-Schwendler  Independent Chair  Representing RRM n PDM Vendors  Metaphase  IBM  Sherpa  Adra  Fujitsu  DEC  NIIIP n Goal:  Provide Standard Service Interface to PDM Enablers  Implementable by all Participating Vendors n Approach:  Define Object Model of Enablers and their Interdependencies  Derive IDL Interfaces from Object Model.

23 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 23 Appl AAppl B2Appl CAppl B1 Task A Task B Task C Part Structure The Case of PDM Change Management EffectivityDocument Management

24 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 24 Appl AAppl B2Appl CAppl B1 Task A Task B Task C Part Structure The Case of Material Services Change Management EffectivityMaterials Blend & Build

25 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 25 Task A Task B Task C Part Structure Distributed Objects Change Management EffectivityMaterials Corba Appl AAppl B2Appl CAppl B1

26 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 26 Execution Architecture Application Message Broker Object Service Application is responsible primarily for user Interface. No work done here, or it’s unusable in other applications Application does not worry about who, what, or where of service provision Production Quality service does not worry about who is using it or why. Object Request & Response Object Request & Response

27 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 27 Execution Architecture Application Message Broker Object Service Application Object Service Three-Tier, Two-Tier, or One-Tier Binding? No religion. Selected based on requirements.

28 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 28 Application Framework SDAI MSC Data Management Architecture ODB C Goal: Enable access to MSC databases using a common framework. Benefit: Allow development of interfaces (CORBA, ODBC, Data Browsing Tools, Value-Added Applications) which provide consistent access to data. MSC Data Management Services (CORBA Server) Oracle CAD / CAM / CAE / PDM Client Application Netscape Java Server Java Applet Other Databases Engineering Data Browser (Java / Netscape) Database Server PDB Databank STEP AP209 DB Materials DB COTS RDMBS API Other DB API’s CORBA Distributed Computing Layer Desktop Tools (Excel, Word) EXPRESS Database Schema Intelligent Database Component PDB API

29 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 29 Enterprise Evolution n Revolution is often advocated, but seldom practical in a large company. n Legacy systems need to be accommodated while transitions to the future takes place. n Technology and Business Processes evolve continuously… n We need to prepare more for the journey than the destination. We won’t be at any destination long, but will be on the journey forever. n Blend & Build

30 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 30 Blend & Build n We need to implement in small digestible chunks. n Task oriented applications n Integration through the infrastructure n Incremental development of the infrastructure n Reusability of existing infrastructure n Evolution, not Revolution

31 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 31 A Specific Application Object Request Broker Service AService B Functionality Required by the Specific Application The Whole Service Incremental Infrastructure - 1

32 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 32 Incremental Infrastructure - 2 Another Specific Application Object Request Broker Service AService B Functionality Required by Another Specific Application Functionality Already in Place

33 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 33 Blend & Build Another Specific Application Object Request Broker Service AService B A Specific Application

34 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 34 PDM File Document Management Opaque Semantics Part Has Geometry In CAD CheckIn/Out Request File Transfer Transparent Semantics Traditional PDM “Integration”

35 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 35 PDM Part IS A MVision Material & Material Properties Material with Part Semantics Material with Property Semantics Material Object Reference Semantic PDM Integration

36 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 36 Legacy PDM View PDM Part IS A MVision Material PDM Material View

37 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 37 MVision Material Properties GMD Material View Material PDM Has Properties Legacy MVision View

38 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 38 PDM Part IS A MVision Material & Material Properties Material Object Request Broker Application using PDM & Material Services Has Properties Integrated GMD View

39 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 39 CORBA MS-Windows COM/DCOM Applications (e.g. Excel,or 3 rd Party Apps) GMD WEB Browser WEB Server PDM Services GMD Material Services HTTP Protocol IIOP Protocol CGI IIOP Protocol COM/CORBA IIOP Bridge New, Legacy and MS-Windows Applications IIOP Protocol CORBA Adapter Application Architecture

40 The MacNeal-Schwendler Corporation Larry.Johnson@macsch.com Systems Architect Page 40 Legacy Application “A” Application “A” Specific Glue-Code CORBA GMD Material Services Legacy Application “B” Application “B” Specific Glue-Code Local File Legacy Integration Architecture


Download ppt "The MacNeal-Schwendler Corporation Systems Architect Page 1 Interoperability: Examples from MSC’s Architectural Directions."

Similar presentations


Ads by Google