For Enterprise Agility
Upcoming SlideShare
Loading in...5
×
 

For Enterprise Agility

on

  • 798 views

 

Statistics

Views

Total Views
798
Slideshare-icon Views on SlideShare
798
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Organization’s efforts in linking its vision to implementation Architecture frameworks Reference models Documentation and knowledge capture efforts Interface specifications Modeling and modeling language preference functional, process, data, etc. Technical approach - e.g. object-oriented, Rapid Applications Development (RAD) Controls and metrics Technology - methodology is technology agnostic ...

For Enterprise Agility For Enterprise Agility Presentation Transcript

  • For Enterprise Agility & Interoperability Mike Lubash DFAS XML Team Lead DOD Finance and Accounting XML Community Manger Emerging Technologies [email_address]
  • Agenda Part I: Vision Agenda 1 2 3 Part II: Implementation 4 Layers Detailed Paradigm Shift Moving Enterprise Forward Environment
  • Agenda Past Future Understanding the Challenge Today’s Approach Part I: Vision Agenda 1 Momentum Doctrine for Agility and Interoperability Environment
  • Environment: Understanding the Challenge Symptoms Ineffective communication of requirements Non-reliable information - Integrity/Quality Extending individual efforts to common is painful Convoluted processes Inability to upgrade system Don’t have the information Customer dissatisfaction due to not meeting needs Unable to measure effectiveness of the Enterprise Unable to go from vision to implementation Scope-creep Delay in system implementation Cost overruns for a project
  • Environment: Understanding the Challenge 1-3. Semantics 4. Frameworks are complex 5. Take back the steering wheel 6. One Size doesn’t fit all 7. Information is Power 8. Brain Drain paralysis Symptoms Ineffective communication of requirements Non-reliable information - Integrity/Quality Extending individual efforts to common is painful Convoluted processes Inability to upgrade system Don’t have the information Customer dissatisfaction due to not meeting needs Unable to measure effectiveness of the Enterprise Unable to go from vision to implementation Scope-creep Delay in system implementation Cost overruns for a project Root Causes
  • Environment: Understanding the Challenge Root Causes Defined 1. Semantics 2. Semantics 3. Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture
  • Environment: Today’s Approach Leading Methodologies Standards with modularity EDI - recent added 'slotting' concept with XML http://www.disa.org ANSI Electronic Data Interchange X12 Language, patterns, ERP perspective, ebXML support Content for business software interoperability via BODS http://www.OpenApplications.org Open Applications Interoperability Specification OAGIS Addresses linguistics for designing and implementing integration bridges between currently incompatible systems. http://www.ecimf.org/ E-Commerce Integration Meta-Framework ECIMF graphical representations of various systems sixteen methods, from IDEF0 to IDEF14 (and including IDEF1X), are each designed to capture a particular type of information through modeling processes. IDEF methods are used to analyze the model, create a model of a desired version of the system, and to aid in the transition from one to the other. http://www.idef.com/ Integrated Definition IDEF Proven in many developments, graphical ..engineering processes that provide you with guidance to streamline your team's development activities http://www.rational.com/products/rup Rational Unified Process™ RUP Seperates business from technology, graphical built on the solid foundation of well-established OMG standards, including: Unified Modeling Language™ (UML™) http://www.omg.org/mda/ Model Driven Architecture MDA Continues with modeling, development of language for communication, Registry based on configuring the Unified Process methodology developed by the Rational Corporation (UML) to meet UN/CEFACT needs for modelling business processes in addition to objects. http://www.gefeg.com/tmwg/n090r10.htm UN/CEFACT Modeling Methodology * ebXML adopted UMM Provides for architecture alignment via products, Includes narratives, demonstrated success in DoD agencies, aligns closely with previous Federal approach · Establish common architecture terms and definitions · Implement a common approach for architectures · Strengthen architecture policy and guidance · Define and use levels of interoperability · Build architecture relationships with other DoD processes · Manage DoD architectures http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/ Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance C4ISR - DoD Strong Points Initiative Brief Initiative
  • Environment: Today’s Approach Existing Mechanisms           STANDARDS AUTHORATATIVE SOURCE PRIORITY PRINCIPLES & RULES OBJECTIVES MODELS ONTOLOGY REQUIREMENTS RISK MANAGEMENT RATIONALE Business Why is the engagement being undertaken? What are your organization's primary motivations and business drivers? Functional What will your system do? What information will it provide? Technical How will your system be realized with IT components? Implementation With what specific products and other components will your system be implemented? In what organization? According to what plan? Reference Views AS IS MIGRATION TO BE For each reference view Technology Architecture Applications Architecture Information & Data Architecture Business Architecture Technology Architecture Applications Architecture Information & Data Architecture Business Architecture
  • Environment: Today’s Approach Traditional View of Interoperability Physical Data Link Network Transport Session Presentation Application Source: Open System Interconnection OSI Model Provides different services to the applications Converts the information Handles problems which are not communication issues Provides end to end communication control Routes the information in the network Provides error control between adjacent nodes Connects the entity to the transmission media Interconnection
  • Environment: Momentum Source: DONCIO NetCentric
  • Getting to the Future - Obtaining our Objectives Business Lines Transformation Federal Enterprise Architecture DoD Architecture Framework NASCIO Adaptive Enterprise Architecture Agile Enterprise Implementation Netcentricity Architecture Doctrine for Agility & Interoperability Roadmap for going forward and provide traceability from vision to implementation
  • Doctrine for Agility and Interoperability          
    • Business First
      • Shifting power to the users; customer and business experts, e.g. self-service
      • Provide traceability from business vision to implementation (and status)
      • Managing information assets to ensure: visibility, accessibility, interoperability, and understandability through metadata
      • Semantic-driven; technology neutral context supported by classifications, ontology and patterns for semantic alignment
      • Moving the semantics from applications to the infrastructure layer
      • Objective: not standard language - but instead standard reusable mechanisms to better negotiate differences
      • Capture rationale for pragmatic interoperability; Templates and models to define ‘what’ not ‘how’;
      • Its not just technology; people are key asset
    • Multi-Faceted Architecture
      • Function-centric; not system or entity
      • Choice: Web (human), data, process, services
      • Modular and layered to address complexity; leverage open initiatives such as XML
      • Service-oriented; loosely coupled interfaces
      • Wrap legacy systems with services
      • Provide structure for business patterns
      • Defer physicalization as long as possible
    • Strong Business Case
      • Clear defined goals with success metrics
      • Supported by proof of principles
      • 1, 2, 5 and 10 year migration strategy
      • Can’t wait for a perfect solution
      • Continuous integration process
  • Agenda Agility Model Information Architecture Part I: Vision Agenda 1 2 Operational View Opportunities BCM Paradigm Shift Environment
  • Paradigm Shift Handle an Ever Changing Enterprise Information Architecture* Navigation Products / Services Enabling Technologies Interfaces Vocabularies Content High Low Stability Agility Model Source: Adapted from Semantic Studios High Low * includes a Thesaurus to align vocabularies with business concepts Physical Data Link Network Transport Session Presentation Application OSI Model Interconnection Volatility Need to build on solid base, manage and communicate well, if not, above layers become unstable; our critical foundation which to architect - and our costliest to change ! Some of our artifacts are more stable than others... … a layered model helps in costing, understanding, and leveraging unique qualities of various information architecture components
  • Supporting Information Architecture Information Architecture Navigation Products / Services Enabling Technologies Interfaces Vocabularies Content High Low Stability Agility Model Source: Lubash Pyramid Information Architecture Enables the management of critical Enterprise information artifacts
  • BCM Model Applying Constraints in Layers Where Appropriate Source: BusinessCentricMethodology.com Methodology Strategic Tactical Information Architecture Enables the management of critical Enterprise information artifacts
  • BCM Templates Business Drivers: Model / Process / Constraints Contract – Collaboration Partner Specific Constraints
    • Business Goals
    • Frameworks & Standards
    • Legacy
    • Authoritative Sources
    Templates
      • Templates provide context for declaration of constraints and choices
    Methodology In form ation form The difference between data and information is context. Therefore, data must be put in form for context to be learned. System of linked ‘ forms ’ & simple graphics ie. wizards
  • Operational View - Interoperability Artifacts in Motion Implementation Templates Template-driven
  • BCM Templates – for Effective Communication Business Operational View Domain aspects of business transactions Technology Service View IT aspects of business transactions 1. Improving communication between business domain experts (‘what’) and technologist (‘how’) to maximize new exciting opportunities. 2. Using the same template mechanism to communicate with our collaboration partners
  • BCM Templates – Workflow Viewpoint Where / Who Where / Who The Templates are going to prompt for the same 6 questions, at different layers, from different points of view (with each view being from a dominate question) Where / Who Action Event Information Rule What Why How When Action Event Information Rule What Why How When Action Event Information Rule What Why How When
  • Opportunities: Afforded to an Agile Enterprise Few Examples… 1. Pragmatic as well as Semantic Interoperability via Templates 2. Collaborative Business - via Templates and aligned ontologies 3. New and simpler mapping methods for interoperability 4. New ways of doing business; i.e. Web Services 5. Supporting Communities of Interest (CoI)
  • Opportunities: Afforded to an Agile Enterprise 1. Pragmatic & Semantic Interoperability Abstraction Meta- Metadata Metadata Data In addition to rationale, the Templates house the concepts, context, and constraints
    • Classification
    • Ontology
    • Patterns
    Wisdom Knowledge Information Data Add Structure Add Experience Synthesize Knowledge Templates Concept Context Instance Constraint Human Intelligence Semantic Interoperability Pragmatic Interoperability
  • Opportunities: Afforded to an Agile Enterprise 2. Metrics for Interoperability             Poor Integration Traditional Contract Good Integration Aligned Ontology Semantics, Semantics, Semantics Collaboration Partner #1 Collaboration Partner #2 Source: Lubash Pyramid Separate Ontologies Contract driving Templates
  • Opportunities: Afforded to an Agile Enterprise 3. Providing Options for Interoperability Mapping (Option 1) Trans Std Trans App App Instance IC Map Map Across Domain Domain Specific Trans App Instance App Template (Option 2) Registry Target IC Baseline Specification Populated Templates What is harder? Sending or Receiving?
  • Opportunities: Afforded to an Agile Enterprise 4. Trend Toward Service-Oriented Architectures SHIFT SHIFT Hub n’ Spoke S ervice O riented (SOA) Centralized data processing only Virtual Pt.-to-Pt. Physical Artifacts 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 Logical & Physical Artifacts 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 Ad Hoc Distributed data processing Simple Pt.-to-Pt. Physical Artifacts 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 Business-Centric Methodology becomes ever more critical
  • Opportunities: Afforded to an Agile Enterprise 5. Supporting Communities of Interest - CoI System Service Ontology Composite
    • Institutional communicates and navigates Enterprise via ontology
    • Expedient through discovery and use via CM Search
    Message CoI Expedient Viewports / Capabilities CM Service Search Create Domains Navigation Source: http://www.CollaborativeMemory.com Search Results Registry Persistence Using History-of-Use Filtering to leverage relationships between users and Enterprise artifacts User CoI Institutional Architecture
  • Summary          
    • Present an methodology for agility & interoperability that …
      • addresses the root cause rather than just symptoms of our integration problems by providing semantic and pragmatic interoperability
      • is business-centric; shifting power to the business experts; managing Enterprise artifacts and governance through Communities of Interests (CoI)
      • provides visibility, accessibility, understandability, using open declarative mechanisms that allow for mass customization of diverse vocabularies and models within heterogeneous environments
      • insulates business from the high rate of change of technology by dividing the problem into multiple levels and applying constraints properly to reduce complexity and promote reuse
      • provides for Enterprise agility and prepares the Enterprise for new opportunities in doing business
    A tactical-only solution is a waste of money – we need to adopt an Enterprise solution that addresses business context and people.
  • Agenda Part I: Vision Agenda 1 2 Strategy Infrastructure 3 Part II: Implementation Plans Paradigm Shift Tactics Moving Enterprise Forward CoI Environment
  • Strategy to Moving the Enterprise Forward Brown Fields: Piggyback on “Hot Button” Initiatives ‘ Portal Effect’ Opportunity! Information Architecture* Navigation Products / Services Enabling Technologies Interfaces Vocabularies Content High Low Stability Agility Model * includes a Thesaurus to align vocabularies with business concepts
  • Strategy to Moving the Enterprise Forward Green Fields: Natural Development Process
    • Preliminary Stage
    • Define business context
    • Determine ROI
    • Use Case – scenarios
    • Sequence diagrams to flush out number of transactions and rough cut business objects
    • Research prior work, identify business concepts and sources *
    • Develop rationale for solution approach *
    • Preliminary Design Review (PDR)
    • Design Stage
    • Concepts defined and authoritative sourced *
    • Requirements and rationale detailed
    • Target constructs identified *
    • Classify Concepts and Targets *
    • If not using Target constructs for physical exchange, provide Implementation Guide(s) *
    • Physical XML Schemas, XML Instance examples, XSL implemented *
    • Design Review (DR)
    • Final Stage
    • Modifications incorporated from test *
    • Final Review (FR)
    • Comments incorporated from Final Review *
    • Registered*
    Project Start Design Develop & Test Metadata management plays a role * Deploy
  • Strategy to Moving the Enterprise Forward Information Architecture with XML technology             Motivation Time People Specifications Schema Workflow Contract Directory Services Collaboration Partner Profiles - CPP 2 1 3 4 5 Presentation Collaboration Partner Agreements- CPA Artifact relationships Content Assembly Mechanism - CAM BP Specification Data/Codes Services/Functions Network XForms MSH/SOAP Source: Lubash Pyramid Verbs Messages Rules Events Process Roles Transport Routing, Packaging Nouns Core Components WSDL
  • Strategy to Moving the Enterprise Forward Legacy Transactions Business Layer Concepts Conceptual Layer Communities of Interest Business Drivers: Model / Process / Patterns / Constraints Alias Business Goals Reuse - Compound Constructs Context Target Constructs Baseline Specification Mappings Implementation Layer Physical Legacy Model / Stores Extension Layer Contract Technology Model / Constraints Alias Frameworks & Standards Publish
    • Middle Out
      • Transitioning
    Architecture Products Design Products Business rules / Patterns / etc. Ontology - Classification - Taxonomy - Thesaurus
  • Strategy to Moving the Enterprise Forward Delivering Business Value Collect Connect Communicate Correlate Contract / Choose Catalog 1 2 3 4 5 6 Phase 1 Phase 2 Best Value Register Alignment Registered Entity Relationships
  • Infrastructure to Move the Enterprise Forward Major Supporting Services / Components Rules/Mapping Engine Workflow Ontology
    • Taxonomy
    • Semantic Network
    Template Processor
    • Thesaurus
    • Classifications
    Federated Visualization Tools Index / Clustering
  • Infrastructure to Move the Enterprise Forward Collaboration Mechanisms Major Infrastructure Services / Components
    • Shared URLs (Favorites / Bookmarks)
    • Intelligent Filters – Dynamic Channeling
    • Issues and Risk Mitigation
    • Coexistence
      • Conference / Thread Tracking
      • Presentations / Whiteboards
    • Shared Services / Applications
    • Contacts
    • Events
    • Project
    • Customer / Help, etc.
    Information Enabling Function Sharing Group Leveraging Information Sharing (Portal, etc.)
    • Shared Directories / Documents
    • Forums
    • Chat, IRC, etc.
    • Email
    • Collaboration Partner Alignment – Map
    • Registry of concepts & reusables
    • Rationale Templates & Thesaurus
    • Classification – Taxonomy – Ontology
  • Moving the Enterprise Forward - Tactics Build with existing infrastructure and have 1, 2, 5, 10 year plan
    • Apply Methodology
    • Leverage ‘hot button’ initiatives; portal efforts to derive organization’s ontology
    • Harvest or federate current Enterprise information
    • Complete initial best practice Templates for identified high payback area
    • Collaboration with ongoing Enterprise Architecture initiatives
    • Apply methodology to proof-of-principles and new developments
    • Planning
      • Develop: - Project workplan
      • - Metadata management plan
      • - Knowledge management plan
      • - Transition plan
      • Set in place policy for Enterprise
    • Develop Information Architecture
      • Put in place collaboration mechanisms
      • Document/automate metadata management procedures
      • Develop first cut taxonomies
    • Communication
      • Develop Communities of Interest - CoI
      • Set-up ‘help line’ for internal contacts
      • Education and facilitation
  • Agenda Part I: Vision Agenda 1 2 3 Part II: Implementation 4 Artifacts Conceptual Business Extension Implementation Layers Detailed Deliverables Products Paradigm Shift Moving Enterprise Forward Environment
  • BCM Review: Key Characteristics
    • I. Layered Approach
      • Manage artifacts and constraints strategically
      • Semantic Interoperability
        • Lexical alignment at Conceptual Layer
        • Identify Authoritative Sources
        • Use/Map of business Target Constructs
    • II. Pragmatic Interoperability
      • Through the use of Templates
      • Assist in communication
    • III. Unique Identifier ( UID )
      • Online visibility
      • Allows methodology to be adopted after development (& legacy systems) through UIDs
    • IV. New approach to building information infrastructure
  • BCM - Layers Detailed Business Layer Concepts Conceptual Layer
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    Communities of Interest Business Drivers: Model / Process / Patterns / Constraints Strategic Tactical Alias Business Goals Reuse - Compound Constructs Context - concept - linking - construct Target Constructs Baseline Specification Mappings Implementation Layer Physical
    • Outreach
    • Role-Process Identification
    • Standards & Framework Adoption
    • Qualifier to Object Breakout
    • Thesaurus Assignment
    • Interchange Mapping
    • Transaction / Presentation
    • Collaboration Partner Specifics
    • Mandatory vs Optional
    • Elements vs Attributes
    • Length, Datatyping and Masking
    • Routing & Packaging
    • Service Parameters
    Legacy Extension Layer Contract Technology Model / Constraints Alias Frameworks & Standards Publish
  • Conceptual Layer – Drivers Business Goals Vision Statement Policies Architectures Balanced Scorecard Strategic Plans Performance Agreements Goal Patterns Targets, Measures & Assessments - concept - linking - construct Align ambiguous, competing, and conflicting drivers to Enterprise goals Concepts Conceptual Layer Business Goals Frameworks & Standards A
  • Conceptual Layer – Drivers Horizontal Standards (all industries) Vertical Standards (specific industries) Frameworks and Standards
    • Some initiatives are:
      • complete frameworks
      • small focused areas
    Many standards overlap and are duplicative
    • ‘ Standards’ are:
      • sanctioned bodies
      • consortiums
      • few companies
    Align frameworks & standards selection to Enterprise goals Conceptual Business Extension Implementation
  • Conceptual Layer Tasks Define Business Context
    • Business Case Analysis (BCA)
      • Align with Balanced Scorecard - are we addressing the Enterprise’s needs?
      • Identify overall issues - prepare problem statement(s)
      • Feasibility, Risk, Cost Benefit
      • Understand organizational drivers (pain, opportunity) from each stakeholders’ perspective
      • Determine success and performance metrics
    • Define what is in and out of scope – prepare scope statement
    • Research pattern base for leveraging prior efforts
    • Coordinate with other project planning tasks
    • Timeline Decision?: ‘Link Now’ vs ‘Link Later’
      • Link Now = Use BCM Templates as best practice guidance throughout development
      • Link Later = “Fast Track” where time overrides costs, expedite & align UIDs after the fact
    • Expose for collaboration
    • Begin iterative process…
    You Are Here “ From Business Goals to concepts, constructs, and communication”
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    From: Cost Issues To: Business Advantage Results: Customer Best Value Conceptual Business Extension Implementation
  • Conceptual Layer Tasks Use Case
    • Describe scenarios
    • Diagram and/or paragraph form
    Sequence Diagrams
    • Players and objects in time sequence
    • Happy and Sad Paths
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    Conceptual Business Extension Implementation Maintain Account Accounting System Act Manager
  • Conceptual Layer Tasks Identify Authoritative Sources
    • Who is the subject matter experts?
    • e.g. Address… USPS
    • Business Concepts Template:
      • Agree on definitions
      • Alias with sources / derived
      • Search Registry
    Depending on life-cycle of initiative
    • Established - Accept
    • Early - Collaborate
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    Business Concept Definition Order of Authority Preference per your Community Provides for lexical alignment to help understand our business semantics Conceptual Business Extension Implementation
  • Conceptual Layer Tasks Concepts Registration
    • Register/Link to Authoritative Source Concepts
    Repository Register Store Register
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    • Register/Store Internal Concept
    UID UID Make artifacts visible and accessible with a degree of trust Conceptual Business Extension Implementation Trust
  • Conceptual Layer Tasks Classification Assignment
    • e.g. DUNS
    • Multiple Facets or combination of characteristics
    Arlington Indy Denver Cleveland Pensacola Columbus Location X Code Identifer Angle Date Mass Area Classword X Mil Pay Civilian Pay Commercial Pay Accounting ... … X Location Business Line Classword
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    Business Line Concept Conceptual Business Extension Implementation
  • Conceptual Layer Tasks
    • Navigation
    • Clarity - provides foundation areas
    • Support ‘near’ alignment
    • Extensible; extend later if required
    • Multiple faceted taxonomies
      • Domain(s) Discipline
      • Information Architecture
      • Business Line
    Ontology Placement ? ? ? "Meaningful learning involves the assimilation of new concepts and propositions into existing cognitive structures" Prof. Joseph D. Novak Cornell University 1960s Ontology = Taxonomies + Thesaurus + Classifications + Codelists + Schemas + Models, etc.
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Business Concept Definition
    • Concepts Registration
    • Classification Assignment
    • Ontology Placement
    Stability least most Place concepts in ontology base Conceptual Business Extension Implementation
  • Conceptual Artifacts             Verbs Motivation Time People Rules Events Roles Transport Routing, Packaging 2 1 Source: Lubash Pyramid (Note: rows 1 & 2 equate to Zachman’s columns) Nouns Data/Codes Services/Functions Network Shift from Data Management to Metadata Management The power of the Conceptual Layer is having the artifacts unconstrained If you can’t agree at this level, you can’t do business
  • Conceptual Artifacts + Products   Verbs Motivation Time People Rules Events Roles Transport Routing, Packaging 2 1 Source: Lubash Pyramid (Note: rows 1 & 2 equate to Zachman’s columns) Nouns Data/Codes Services/Functions Network
    • Memorandum of Agreement (MOA)
    • Goals – Deliverables/Outcomes – Metrics
    • Concept – UID – Resource (Metadata)
    • Concept – Concept (Thesaurus)
    • Concept – Classification – Taxonomy
    • Resource – User – Role
  • Agenda Part I: Vision Agenda 1 2 3 Part II: Implementation 4 Artifacts Conceptual Extension Implementation Layers Detailed Deliverables Products Paradigm Shift Moving Enterprise Forward Environment Business
  • Business Layer
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    EAI - database structures for all requirements ; generalized structure with nominal constraints B2B – messages with maximum constraints For mechanisms this relationship is reversed : EAI mechanisms are a subset of B2B mechanisms - concept - linking - construct Tradeoff Business choices drive the Enterprise’s Agility and Interoperability Business Layer Concepts Communities of Interest Business Drivers: Model / Process / Patterns / Constraints Reuse - Compound Constructs Context Target Constructs
  • Business Layer Tasks
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    Define Business Rules Business rules e.g. triggers, email
    • Static Analysis
    • Extract
    • Interactive Sessions
    Identify business events and response outcomes Collection Methods Define rules, business logic in a declarative manner Conceptual Business Extension Implementation
  • Business Layer Tasks
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    Capture Business Patterns Business pattern - the business nature in specific context in order to understand and abstract best practices, or capture the essence of repeatable processes for reuse. Knock Knock Identify or reuse business patterns Conceptual Business Extension Implementation
  • Business Layer Tasks
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    Relationships Attributes SEQUENCE TARGET CONSTRUCT object
    • Atomics and Constructs in Exchange Scope
        • - independent
        • - dependent
    Attributes security From previously identified messages, identify exchanged objects Conceptual Business Extension Implementation
  • Business Layer Tasks
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    Structure: Resolution / Indenture - what is included in constructs? - use concatenated or atomic? Option #1 Separate constructs, all switching in ontology Option #2 Single construct, partial switching in construct Determine how to house artifacts and at what resolution level Conceptual Business Extension Implementation
  • Business Layer Tasks
    • Requirements
    • Business rules / patterns
    • Atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    Workflow / Process Identification Define the message flow and control ‘states’ between applications or collaboration partners Conceptual Business Extension Implementation
  • Business Layer Tasks
    • Requirements
    • Identify business rules / patterns
    • Scope; atomics & constructs
    • Structure: Resolution / Indenture
    • Workflow / process identification
    • Mandatory vs Optional
    • Sub-setting Codelists
    Mandatory vs Optional Sub-setting Codelists
    • # of requirements/parties increases the probability that an element becomes ‘optional’ - constraints simplify the message!
    Superset Subset Published Set e.g. EDI Standards Collaboration Partner or Industry Specific Focus on Attribute Details Determine what are the attributes; mandatory/optional and domains for each state of the business object Conceptual Business Extension Implementation
  • Business Layer Artifacts             Verbs Motivation Time People Messages Rules Events Roles Specifications Schema Transport Routing, Packaging 2 1 3 Nouns Data/Codes Services/Functions Network Process Workflow 4 Source: Lubash Pyramid Position to share workflow with Collaboration Partners Connect concepts with constraints Target Constructs = Concepts + Constraints Related to messages in multi-party workflow
  • Business Layer Artifacts + Products             Verbs Motivation Time People Messages Rules Events Roles Specifications Schema Transport Routing, Packaging 2 1 3 Nouns Data/Codes Services/Functions Network Process Workflow 4 Source: Lubash Pyramid
    • Business Line - Business Pattern
    • Pattern – Workflow
    • Workflow – Event – Process -- Service
    • Service – Component - Data – Rule
    • Rule – Role -- Security
    • Rule – Goals and Metrics
  • Agenda Part I: Vision Agenda 1 2 3 Part II: Implementation 4 Artifacts Conceptual Implementation Layers Detailed Deliverables Products Paradigm Shift Moving Enterprise Forward Environment Business Extension
  • Extension Layer
    • Outreach
    • Role-Process Identification
    • Standards & Framework Adoption
    • Thesaurus Assignment
    • Interchange Mapping
    • Qualifier to Object Breakout
    - concept - linking - construct Supporting heterogeneous trading partner environments; within existing capability while moving to the future. Baseline Specification Legacy Extension Layer Frameworks & Standards Target Constructs
  • Extension Layer Tasks - Who / How
    • Outreach
    • Role-Process Identification
    • Standards & Framework Adoption
    • Thesaurus Assignment
    • Interchange Mapping
    • Qualifier to Object Breakout
    Role-Process Identification Business Layer Extension Layer Implementation Layer Collaboration Partner specific From previous defined Use Cases, align partner Communities of Interest - COI to baseline specification. Want to find the ‘sweet spot’ in understanding and developing the baseline specification per COI by including as many partners as possible; but without stretching COI to become complex Conceptual Business Extension Implementation XML EDI UDF Community # 1 Community # 2 Community # 3
  • Extension Layer Tasks - What Collaboration Partner #1 Collaboration Partner #2 Business (Logical) Standards & Framework Adoption
    • Thesaurus Assignment
    • Interchange Mapping
    • Qualifier (typing) to Object Breakout (explicit vs. code)
    • Target – External / Legacy
  • Agenda Part I: Vision Agenda 1 2 3 Part II: Implementation 4 Artifacts Conceptual Layers Detailed Deliverables Products Paradigm Shift Moving Enterprise Forward Environment Business Extension Implementation
  • Implementation Layer - concept - linking - construct Tailor Collaboration Partner Specifics Technologist develop interchanges and user interfaces using [1] Target Constructs or [2] Baseline Specifications with supporting products within partner constraints. Baseline Specification Mappings Implementation Layer Physical
    • Transaction / Presentation
    • Collaboration Partner Specifics
    • Mandatory vs Optional
    • Elements vs Attributes
    • Length, Datatyping and Masking
    • Routing & Packaging
    • Service Parameters
    Contract Technology Model / Constraints
  • Implementation Layer – CAM Template <MapStructure> <Rules> <MapRule output=&quot;Product List&quot; input=&quot;@PARENT()&quot; path=&quot;&quot; /> <MapRule output=&quot; name &quot; input=&quot;Qrt/Product/Item@ name &quot; /> <MapRule output=“ madeby &quot; input=&quot;Qrt/Product/Item@ made &quot; /> <MapRule output=&quot; value &quot; input=&quot;Qrt/Product/Item@ value &quot; /> <MapRule output=&quot; sold &quot; input=&quot;Qrt/Product/Item@ sold &quot; /> <MapRule output=&quot;Product List&quot; input=&quot;@ENDPARENT()&quot; /> </Rules> </MapStructure> Content Assembly Mechanism <CAM> <AssemblyStructure/> <PartnerUseContext/> <ContentReference/> <DataValidations/> </CAM>
  • Ontology Providing Interpretation Support allowing for Enterprise-level crosswalks and light transactions Collaboration Partner #1 Collaboration Partner #2 Business (Logical) Registry PartNumber Color PartNo X12 EDIFACT DFAS.PartNum < ELEMENT name =‘PartNumber ’… <dc:identifer> DFAS.PartNum… Schema or CAM Template < ELEMENT name =‘PartNo ’… <dc:identifer> DFAS.PartNum… Schema or CAM Template (Physical) XML Instance /Content Data XML Instance / Content < PartNo > 999… Machine-to-Machine < PartNumber > 999… < Color > Black…
  • Implementation Layer Artifacts             Verbs Motivation Time People Messages Rules Events Process Roles Specifications Schema Workflow Transport Routing, Packaging Directory Services Collaboration Partner Profiles 2 1 3 4 Presentation Collaboration Partner Agreements Artifact relationships Nouns Data/Codes Services/Functions Network Contract 5 Source: Lubash Pyramid Contract is the formalization and linking of supporting pyramid Templates
  • Implementation Layer Artifacts + Products             Verbs Motivation Time People Messages Rules Events Process Roles Specifications Schema Workflow Transport Routing, Packaging Directory Services Collaboration Partner Profiles 2 1 3 4 Presentation Collaboration Partner Agreements Artifact relationships Nouns Data/Codes Services/Functions Network Contract 5 Source: Lubash Pyramid
    • Trading Partner Agreements (traditional - legal)
    • Trading Partner Agreements (organizations, local vs global)
    • Application Negotiation (see eCo)
    • Application Definitions (with choreography - PIPS, WSDL)
    • Service Level Agreements (with multi-part MIME & security)
    • Service Level Agreements (outsourcing)
    • Service Level Agreements (connection, leased lines)
    • Trading Partner Templates (XML/edi Group, SEF, IMPDEF, etc.)
    • Repository Interface (logical units with UID)
    CPA
    • Message – Internals (database, etc.)
    • Message – Communications - Topology
  • Summary
  • Root Causes / Tasks 1-3. Semantics 4. Frameworks are complex 5. Take back the steering wheel 6. One Size doesn’t fit all 7. Information is Power 8. Brain Drain paralysis Tasks Templates for pragmatic interoperability (general) Business Goals Define Business Context Use Case Sequence Diagrams Authoritative Source Business Concept Definition Registration Classification Ontology Placement Define Business Rules Capture Business Patterns Root Causes
  • Root Causes / Tasks 1-3. Semantics 4. Frameworks are complex 5. Take back the steering wheel 6. One Size doesn’t fit all 7. Information is Power 8. Brain Drain paralysis Tasks Atomic & Constructs in Exchange Scope Structure: Resolution / Indenture Workflow / Process Identification Focus on Attribute Details Baseline Specification Role-Process Identification Standard & Framework Adoption Map Library UID based (general) Layering of Constraints (general) Delay XML Physicalization (general) NetCentric; Visibility, accessibility, understandability Root Causes
  • Summary          
    • Present an methodology for agility & interoperability that …
      • addresses the root cause rather than just symptoms of our integration problems by providing semantic and pragmatic interoperability
      • is business-centric; shifting power to the business experts; managing Enterprise artifacts and governance through Communities of Interests (CoI)
      • provides visibility, accessibility, understandability, using open declarative mechanisms that allow for mass customization of diverse vocabularies and models within heterogeneous environments
      • insulates business from the high rate of change of technology by dividing the problem into multiple levels and applying constraints properly to reduce complexity and promote reuse
      • provides for Enterprise agility and prepares the Enterprise for new opportunities in doing business
    A tactical-only solution is a waste of money – we need to adopt an Enterprise solution that addresses business context and people.
  • Thank you Authors Mike Lubash - Defense Finance and Accounting Service Bruce Peat - eProcess Solutions David RR Webber - eProcess Solutions Contributors Eric Okin - Defense Finance and Accounting Service Kit C.J. Lueder - The MITRE Corporation Charlie Clark - Engineering, Management & Integration, Inc. http://BusinessCentricMethodology.com
  • Agenda Past Future Understanding the Challenge Today’s Approach Agility Model Information Architecture Part I: Vision Agenda 1 Momentum Doctrine for Agility and Interoperability 2 Operational View Strategy Infrastructure 3 Part II: Implementation 4 Artifacts Conceptual Business Extension Implementation Layers Detailed Opportunities BCM Deliverables Plans Products Paradigm Shift Tactics Moving Enterprise Forward CoI Environment Backup for side: 3
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Semantics, Semantics, and Semantics are the top three challenges for interoperability. Interoperability or integration efforts are about making information from one system syntactically and semantically accessible to another system. Syntax problems involve format and structure. An example is converting the representation of data from numeric to a character string. These conversions are well known and the problems documented. Many standard data sources, such as databases and applications can export XML for data transformation using code-free mapping tools. The accessibility of the information, or transport problem has been reduced to routine engineering tasks due to widespread investment in messaging infrastructures. Semantics relate to the understanding and integrity of the information. To put even greater emphasis on the challenge, the Gartner Group stated, “ Only 5% of the interface is a function of the middleware choice. The remaining 95% is a function of application semantics.” Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Frameworks are complex and conceptual - many times provides conceptual differences to working approaches; e.g. understanding and relying on classes in an object-oriented system. In addition, to the adoption hurdle problem, at times frameworks are duplicative and contradicting with multiple levels. Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Failure of business managers to ‘take back’ the steering wheel – and are not eager to accept responsibility for even the ‘what’ objectives much less than the ‘how’ details. Due to tool immaturity integration development has required technical know how which excluded the business practitioners. Today top-down techniques have exhibited impedance mismatch with current programmer’s tools (bottom-up) – with no automated solution that addresses development from business goals to the physical implementation well. Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture One size doesn’t fit all - Understanding the critical difference between (1) decontextualization of data ‘Standards’ and (2) ‘Conceptual-adaptive’ alignment. ‘Standardized data’ provides for inflexibility which leads to a plethora of standards – creating the “Tower of Babel”. Where as adopting a minimalist methodology built upon shared business concepts is simpler, doable, without expensive overhead which “Tower of Babel” syndrome brings to the Enterprise. Experience tells us that (1) one-size architectures don’t work, (2) one-size process models don’t work, (3) one-size data model doesn’t work, and (4) one-size transaction ‘standards’ don’t work. Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Information is power - thus interoperability requirements become skewed and outputting information becomes the driver, not a template driven exchange from the receiver’s input. In typical situations, the organization receiving the information is just plain glad to obtain it, and takes is in any form possible, dealing with the integration issues. The better model certainly would be where the receiver drives the exchange and the exchange is based on aligned concepts. Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Brain drain paralysis - Without knowledge retention, it is very difficult to determine impact of any effort to modernize – in some cases, there does not exist a baseline. For successful eGov, the ability to perform impact analysis is one of the prime challenges. Adding new information or making changes to database structures can have multiple effects. One change can ripple across an entire Enterprise. If data values are calculated from one another, based on one another, tied to one another — evaluating the effects of change can get very complicated very fast. Efforts on Y2K have given visibility into systems, and keen insight on the scope of the problem and provided government with a lesson learned, but probably will too be forgotten. Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Funding for integration infrastructure - Funding and goals are to business lines and IT with very few independent ‘integration’ tools/team initiatives – interoperability though a prime challenge for the Enterprise isn’t funded as such. Acquiring integration infrastructure capability is seldom funded properly as their success outcomes are intangible and difficult to measure. Ironically, these integration projects typically are funded through application projects via business lines or IT departments, of which integration between these two groups which typically their lack of communication is the source much of today’s problems. Should our federal government appoint an ‘Interoperability Facilitator’ as well as an ‘e-Gov Director’? Backup for side: 6
  • Root Causes 1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual) 5. Failure of business managers to ‘take back’ the steering wheel 6. One size doesn’t fit all 7. Information is power 8. Brain drain paralysis 9. Funding for integration infrastructure 10. Culture Culture - Human nature survival instincts for positioning in lieu of collaboration leads to anarchy and balkanization. In fact, outcomes typically are not measured on the whole; success metrics need to be viewed across traditional boundaries, with business goals and responsibilities aligned and traceable from the ‘out’ to ‘in’. The human element must be kept in mind with any proposed system. Report cards need to bring back the category of “work well with others” and rewarded accordingly. Sometimes just getting the right people in the room does wonders for interoperability, trust and sharing. Interoperability will not be achieved if real problems are not confronted, we have learned interoperability starts with people first. Keeping this in mind, eGov systems need to do whatever is technically possible to [1] reduce the politics of knowledge and its influence of power, [2] provide incentives to share, [3] provide collaboration tools with trust mechanisms, and [4] functions to share semantics of the business artifacts. Without a roadmap, the business users (goals) become disenfranchised, an intolerable effect that reduces business agility. Backup for side: 6
  • Environment: Today’s Approach BCM Complements with Value-Add Business-Centric Methodology Complements Backup for side: 7 provides non-standard option Standards with modularity EDI - recent added 'slotting' concept with XML http://www.disa.org ANSI Electronic Data Interchange X12 provides non-standard option Language, patterns, ERP perspective, ebXML support Content for business software interoperability via BODS http://www.OpenApplications.org Open Applications Interoperability Specification OAGIS Target Constructs with outreach mechanism Addresses linguistics for designing and implementing integration bridges between currently incompatible systems. http://www.ecimf.org/ E-Commerce Integration Meta-Framework ECIMF graphical representations of various systems sixteen methods, from IDEF0 to IDEF14 (and including IDEF1X), are each designed to capture a particular type of information through modeling processes. IDEF methods are used to analyze the model, create a model of a desired version of the system, and to aid in the transition from one to the other. http://www.idef.com/ Integrated Definition IDEF Proven in many developments, graphical ..engineering processes that provide you with guidance to streamline your team's development activities http://www.rational.com/products/rup Rational Unified Process™ RUP Seperates business from technology, graphical built on the solid foundation of well-established OMG standards, including: Unified Modeling Language™ (UML™) http://www.omg.org/mda/ Model Driven Architecture MDA Provides declarative templates, Addresses linguistics Provides declarative templates, Addresses linguistics Provides declarative templates, Addresses linguistics Provides declarative templates, Addresses linguistics Continues with modeling, development of language for communication, Registry based on configuring the Unified Process methodology developed by the Rational Corporation (UML) to meet UN/CEFACT needs for modelling business processes in addition to objects. http://www.gefeg.com/tmwg/n090r10.htm UN/CEFACT Modeling Methodology * ebXML adopted UMM Information Architecture, interoperability solution, conceptual alignment, rationale capture, traceabiity, scaleable Provides for architecture alignment via products, Includes narratives, demonstrated success in DoD agencies, aligns closely with previous Federal approach · Establish common architecture terms and definitions · Implement a common approach for architectures · Strengthen architecture policy and guidance · Define and use levels of interoperability · Build architecture relationships with other DoD processes · Manage DoD architectures http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/ Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance C4ISR - DoD BCM Value-Add Strong Points Initiative Brief Initiative
  • Discover, Align, eBusiness source: ebXML Backup for side: 10
  • Information Architecture Artifacts for Interoperability             Verbs Motivation Time People Messages Rules Events Process Roles Specifications Schema Workflow Contract Transport Routing, Packaging Directory Services 2 1 3 4 5 Presentation Artifact relationships Nouns Data/Codes Services/Functions Network Source: Lubash Pyramid Ontology; set of relationships, includes a Thesaurus to align vocabularies with business concepts Backup for side: 15
  • BCM Model - Constraints Defined in Layers Business Layer Conceptual Layer Business Drivers: Model / Process / Constraints Target Constructs & Patterns Implementation Layer Physical - Message & Presentation Extension Layer Contract - Collaboration Partner Specific Constraints Publish Baseline Specification per CoI Concepts in Ontology Business Goals Frameworks & Standards Legacy Authoritative Sources Strategic Tactical Backup for side: 16
  • Operational View: Interoperability Artifacts in Motion Events Rules Schema             Contract Agreement Pattern Workflow Modeling & Business Patterns response process reject accept propose counter Exchange Specification Model & Schemas Nouns Verbs Transport Roles Concept Ontology Template-driven Business Goals Goal Pattern Backup for side: 18 request process
  • Service-Oriented Architecture Reference Model Backup for side: 25 Business Applications and Functions Assurance Access Gateway Workflow Exchange Back-End Enterprise Information Services Layer - EISL Front-End DCR Collaboration Apps Web Browser Email Client Telephone Wireless Finance Account HR Project Mgmt Procure User Interface - Presentation 2 Common Exchange SOAP-based Envelope HTTP 1 Common Services Web Services DCW Registry DCD
  • Our Story, and we are sticking to it Backup for side: 27
  • Critical Communications Baseline Backup for side: 29 Information Management Value-Added Hierarchy  Packaged Solutions Metadata Management SEMANTICS Minimum Level Management Level = Degree of Control PORTAL Service, , Product
  • BCM Infrastructure Conops Backup for side: 34
  • Address Example Business Layer Concepts Conceptual Layer Business Goals Target Constructs Baseline Specification Mappings Implementation Layer Physical Legacy Extension Layer Alias Frameworks & Standards Publish Agreed XML Schemas based on Impl.Guide: - X12-Based - DFADM-based DFAS X12 & DFADM Implementation Guides X12 & DFADM Based Systems DFADM Constructs X12 EDI Standard Considered Concepts: CIQ HR-XML Quickbooks-XML Adopted Concepts: ECCMA DFADM (DDDS) DFAS Conceptual Constructs Based On USPS Published Target Constructs as XML Schemas Backup for side: 36
  • Resolve Semantics Address Example: Conceptual Layer Backup for side: 36
  • Resolve Requirements Address Example: Business Layer Backup for side: 36
  • Outreach to Legacy, Frameworks and Standards Address Example: Extension Layer Backup for side: 36
  • Resolve transactions, presentation Backup for side: 36 Address Example: Implementation Layer
  • Expedited “Fast Track” Alternative Backup for side: 42 Option #1: Metadata Management as a Natural Aspect of the Process Project Start Design Develop & Test Deploy Project Start Design Develop & Test Deploy Link Metadata Option #2: ‘ Fast Track’ Alternative Because we are [1] developing an alignment infostructure, [2] incorporating UIDs, [3] aligning at concept vs ‘standard vocabulary’ we are afforded a ‘Fast Track’ option because the link isn’t tied into programming structures and thus can easily linked into the ontology as a separate development process. Keep in Mind: ‘Fast Track’ Alternative maybe at a higher cost to the Enterprise than Option #1 for the resulting service defaults to Extension - Outreach , rather than opting for the opportunity to build from the Target Construct base. Also the loss of rationale is probable as decision criteria and tradeoffs are not documented along the way.
  • Expedited “Fast Track” Alternative - Costs Option #1: Non- Standard #2: Implement Standards #3: Target Construct Costs to the Enterprise are based on interoperability opportunities... CO$T $ $$$ $$$$$$$$ Interoperability Cost least most Backup for side: 42
  • Conceptual Layer - Concept Template Backup for side: 44
  • Conceptual Layer Tasks Backup for side: 44 Concept Breakout... Business Objects Communications e.g. exchange, notification, query/response e.g. address, organization, account
    • Independent
    • Dependent
    Code Lists classification List ? Which one? Put into Objects (bring-out semantics)
    • Semantics
    • Business Context
    • Use Case and Sequence
    • Authoritative Sources
    • Link Source Concepts
    • Internal Concepts Registration
    • Classification Assignment
    • Ontology Placement
    Concepts Conceptual Layer Business Goals Frameworks & Standards
  • Conceptual Layer Tasks Backup for side: 46 Source: HyperSystems Drill-down with Faceted Classification
  • Zachman Framework Backup for side: 48
  • Business Layer Tasks - Pattern Types Backup for side: 53
          • Business patterns identify the interaction between users, businesses, and data. Business patterns are used to create simple, end-to-end e-business applications.
          • Integration patterns connect other Business patterns together to create applications with advanced functionality. Integration patterns are used to combine Business patterns in advanced e-business applications.
          • Composite patterns are combinations of Business patterns and Integration patterns that have themselves become commonly used types of e-business applications. Composite patterns are advanced e-business applications.
          • Custom designs are similar to Composite patterns, as they combine Business patterns and Integration patterns to form an advanced, end-to-end solution. These solutions, however, have not been implemented to the extent of Composite patterns, but are instead developed to solve the e-business problems of one specific company, or perhaps several Enterprises with similar problems.
          • Application and Runtime patterns are driven by the customer's requirements and describe the shape of applications and the supporting runtime needed to build the e-business application.
          • Product mappings to populate the solution. The product mappings are based on proven implementations.
    Source: http://www-106.ibm.com/developerworks/patterns/
  • Business Layer Tasks - Pattern Examples Backup for side: 53
    • Verb-oriented If workflow is described as a process in whole or in part, then a pattern is one level of abstraction or the “best practice” of a process as learned from experience.
      • - Contract (Check for serviceability) - Negotiation (Check and variable for pricing eBay Auction Proxy/Agent) - Reconciliation - Document (outline… edit… signoff) - Business Reference Architecture - Information Aggregation (Rollups) - Procurement(s) (simple, large, services, products) (Buy, Sell) - Meeting (finding a room, invite, agenda… notes) - Shipping (to carrier, track, accept, call reconciliation pattern) - Travel Reservations - Publish/Subscribe - Integration (verb/services, noun/edi… )
    • Noun-oriented By using declaratives rather than procedural logic we begin to see ‘forms’ or structures in the nature of our business.
      • - BCM Template approach: Feasibility, Risk, Cost Benefit, Business Rule, Workflow, CAM… - UID, unique key - Header / Payload - HTML page with META components (somewhat the same as above) - Verb to this: Download form, complete, submit, next hyperlink page - Tree (Hierarchical/”Composite”) - Status Log - Classes (groupings) - Long-Line of Accounting - DoD Classwords
  • Setting the Tone: Electricity Analogy Joseph Priestley's Laboratory, c. 1775 Explaining XML technology today is much like explaining electricity during the era of gaslights… “ Why do I need electricity, my gaslights work fine?” Computers Light bulb Electrons Backup for side: 67
  • XML’s Strengths
    • Lowers the Bar - easy to read for business users and technologist alike – providing a common ground for communicating information. Available labor pool is large due to the fact that XML parallels HTML education and XML doesn’t require large amounts of specific training to leverage. Machines can easily parse XML and align with data in a robust manner.
    • Independence - from Operating Systems, Applications, Databases, Software Language, Presentation, etc . XSL stylesheets describe how to render data on different devices (monitors, printers, palm pilots, WebTV, voice and agent interactions).
    • Universal Clipboard - implemented as hierarchical nodal trees XML can accommodate entity-relationships, freeform, and network data representations. Any application can validate information prior to internal processing. With XML, all nodes can use the same methods for simplifying and automating processes. End-tagging and consistent syntax enables enhance detection of incomplete information packages.
    • Granularity - XML tagging provides high-resolution access to data enabling context-based searching and delta updates. Contextual information improve the ability to retrieve relevant information from total pool of information.
    Backup for side: 67
    • eXtensible - domain-specific vocabularies, that enable tag names to be specific business needs of a community (e.g., finance and accounting, human resources). Need not be limited to “standard” transactions, and many initiatives which to choose.
    • Semantic References - minimal prior knowledge of sender application is necessary to process information. Not positional or delimiter defined, thus allowing flexible packaging based on business needs.
    • Context Views – any application can extract and separate information it needs to satisfy business functions from other facilitation types of information (e.g., routing, security, archiving). Users (or applications) can on-demand select data views (e.g., one record or all, sort by different attributes, various details) based on business needs/rules.
    Client - Server Internet Productivity & Innovation
  • Products Linked Together with Templates BCM Templates to capture rationale Backup for side: 69
    • Collaboration Partner Agreements (CPA)
    • CPA - Choreography - Message
    • Message – Internals (database, etc.)
    • Message – Communications - Topology
    Implementation & Infrastructure
    • Target – External / Legacy
    Extension
    • Business Line - Business Pattern
    • Pattern – Workflow
    • Workflow – Event – Process -- Service
    • Service – Component - Data – Rule
    • Rule – Role -- Security
    • Rule – Goals and Metrics
    • Application Model – Integration Model
    Business
    • MOA – Contract
    • Goals – Deliverables/Outcomes - Metrics
    Management Conceptual
    • Concept – UID – Resource (Metadata)
    • Concept – Concept (Thesaurus)
    • Concept – Classification – Taxonomy
    • Resource – User – Role
    • Business Model – Application Model
  • BCM Overview Backup for side: 69
  • Search for the Solution When asked what single event was most helpful in developing the theory of relativity, Albert Einstein is reported to have answered, “Figuring out how to think about the problem.” Source: Wilbur Schramm & William Porter, Men, Women, Messages and Media: Understanding Human Communication