220 likes | 315 Views
Semantic-based Architectures. Eric Okin Assistant Deputy Director Policy and Architecture; DFAS - DTB. Mike Lubash XML Team Leader DoD Finance and Accounting Namespace Manager. Architecture: Objective. Develop Knowledge Capital Better communication Humans and applications
E N D
Semantic-based Architectures Eric Okin Assistant Deputy Director Policy and Architecture; DFAS - DTB Mike Lubash XML Team Leader DoD Finance and Accounting Namespace Manager
Architecture: Objective • Develop Knowledge Capital • Better communication • Humans and applications • Alignment & consensus • eliminate conflicting initiatives • Common understanding • improve efficiency and cohesion • Optimize current performance • leverage technology • automate business processes and activities • Position the Enterprise for Change • Proper deliverables to capture the enterprise ‘blueprint’ • Understanding the impact of change (analysis/gaps) • Traceability from business requirements to implementation
What Language Do We Use? Perhaps a better question is… Is there a common instrument or language to capture associated metadata to achieve our architectural objectives?
What Language Do We Use? UML? • UML is primarily a… • system design language • graphical language Business Tools Architecture Tools Design Tools Development Tools Test Tools Management Tools But, we are looking for declarative method for describing our enterprise
What Language Do We Use? Requirement: A declarative language that addresses the entire spectrum of our enterprise Declarative Language Business Tools Architecture Tools Design Tools Development Tools Test Tools Management Tools
ADML Architecture Description Markup Language • The Open Group • World-Wide Web Consortium (W3C) • Object Management Group (OMG) • Micro-electronics and Computer technology Consortium (MCC) • Carnegie Mellon University (CMU) Business Tools Architecture Tools Design Tools Development Tools Test Tools Management Tools US Army has publicly stated (at the first Open Group Architecture Tools Symposium, Washington, October 1999) a need for ADML to allow sharing of architecture information between different vendors' tools.
What Language Do We Use? Bad News No single tool exists for both modeling the enterprise and documenting the applications that implement the business solution. Business Tools Architecture Tools Design Tools Development Tools Test Tools Management Tools • Vocabularies - • TOG - provided a forum to standardize ADML • W3C - developed the specifications for XML and XSL • OMG - developed the specifications for XMI and MOF • MCC - developed the specification for ADML reliant on XML • CMU - developed the ACME model • DoD - ????
What Language Do We Use? More Bad News Different Resolutions Business Tools Architecture Tools Design Tools Development Tools Test Tools Management Tools Oracle's Dynamic Services Framework
So Then What? 1 We have many ways to express our architecture Content 2 Vocabularies Changing Vocabularies and Content is guaranteed 3 Lets review what we do know…
The Ever Changing Enterprise Content Some of our artifacts are more stable than others Vocabularies Interfaces Enabling Technologies Services Navigation Systems Ontology – Full Business Semantics
Foundational Layers: Content Need to build upon these stable layers Vocabularies Interfaces Enabling Technologies Services Navigation Systems Ontology – Full Business Semantics
Semantics: Key to Meeting our Architectural Objectives This layer then becomes our driver, our most critical layer, and thus our foundation which to architect – We need to be able to communicate and manage this layer well, if not, above layers become unstable This layer is also our costliest to change! Ontology – Full Business Semantics
What Experience Tells Us… We need to provide the mechanism to provide many views, many sizes depending on context, so… • One-size architectures don’t work • One-size processes don’t work • One-size data model doesn’t work • One-size transaction ‘standards’ don’t work Ontology – Full Business Semantics
Semantic-based Architecture: Properties • Context-driven • All critical business artifacts are defined in an ontology • Allows semantic alignment in an ontology • Layers are tailored to business use, and not ‘fixed’ • Logic from conceptual to physical entities is defined • Differences are documented exposed, and not implied • Ontology resides and managed in registry/repository • Ontology constructs requires classifications & relations • Ontology and metadata artifacts are viewed as a critical enterprise asset and thus well managed Ontology – Full Business Semantics
Logic is Explicitly Declared: To Physical Physical Message Content Logical Declarative Layer Context Conceptual Ontology – Full Business Semantics
Logic is Explicitly Declared: Between Layers With the information collection and building process, layers provide input into others, e.g. Web portals Layer 2 Navigation Systems Logical Declarative Layer Context Layer 1 Ontology – Full Business Semantics
Enterprise Information Services Layer User Interface - Presentation Apps Web Browser Email Client Telephone Wireless Front-End Common Services Oracle9i WSF Web Services Framework 1 Assurance DCR Registry Workflow Access Enterprise Information Services Layer - EISL DCW DCD Exchange Common Exchange SOAP-based Envelope HTTP 2 Collaboration Gateway Business Applications and Functions Back-End Finance Account Project Mgmt HR Procure
Enterprise Information Services Layer User Interface - Presentation Navigation Systems Apps Web Browser Email Client Telephone Wireless Front-End Common Services Oracle9i WSF Web Services Framework Services 1 Assurance DCR Registry Workflow Access Enterprise Information Services Layer - EISL Ontology Semantics DCW DCD Exchange Common Exchange SOAP-based Envelope HTTP Interfaces 2 Collaboration Gateway XML Enabling Technology Business Applications and Functions Back-End Finance Account Project Mgmt HR Procure
Enterprise Information Services Layer SHIFT SHIFT Ad Hoc Hub n’ Spoke Information Services Layer Distributed data processing Simple Pt.-to-Pt. No Metadata Strategy Reuse: Little Opportunity End-to-End Tracking: Low Integration at Point of Use Lookup Info: Kept at Domain Mapping: Only Once Bandwidth Required: Lowest Computing: Distributed Load Impact of Changes: Low Pt.-to-Pt. Real-time: Yes Immediate Solution Centralized data processing only Virtual Pt.-to-Pt. Broker-based Metadata Strategy Reuse: High Central End-to-End Tracking: Yes, Central Integration at Broker Lookup Info: Must publish to Broker Mapping: Two or more Bandwidth Required: Highest Computing: Central; Big Iron Impact of Changes: High Pt.-to-Pt. Real-time: No Technology Solution Central & Distributed data processing Common Pt.-to-Pt. Mechanism Enterprise Metadata Strategy Reuse: Much Opportunity End-to-End Tracking: Services Integration at Point of Use Lookup Info: Kept at Domain Mapping: Once Bandwidth Required: Lowest Computing: Distributed Load Impact of Changes: Low Pt.-to-Pt. Real-time: Yes Business Solution
Enterprise Information Services Layer Mapping using EISL, ‘Help from Above’ to Registry for semantic interpretations • Uses same registry to align concepts;architectures, layers, processes, messages, etc. from: • conceptual to conceptual • conceptual to physical • physical to physical
Summary • Architecture is critical to a successful enterprise • There is not one way, but many ways of capturing, describing, discussing facets of an enterprise architecture • Architecture spans horizontally across an entity's life cycle and vertically through many resolutions • Semantic alignment is crucial for communication, and achieved via a business’ ontology stored in a registry • EISL is an example architecture du jour, tomorrow change will effect some, if not many of the components • To be successful, metadata artifacts need to be seen as a critical business asset • Only context-based mechanisms will develop the required knowledge capitaland position the enterprise for change