for enterprise agility
DESCRIPTION
TRANSCRIPT
For Enterprise Agility & InteroperabilityFor Enterprise Agility & Interoperability
Mike LubashDFAS XML Team LeadDOD Finance and Accounting XML Community MangerEmerging [email protected]
2
Part I: VisionI: Vision
Agenda
11
22
33 Part II: ImplementationII: Implementation
44
LayersDetailed
Agenda
Paradigm Shift
Moving Enterprise Forward
Environment
3
Past Future
Understandingthe Challenge
Today’sApproach
Part I: VisionI: Vision
Agenda
11Momentum Doctrine for Agility
and Interoperability
Doctrine for Agility and Interoperability
Agenda
Environment
4 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
5 Environment: Understanding the Challenge
1-3.
Seman
tics
4. Fra
mewor
ks ar
e com
plex
5. Tak
e bac
k the s
teerin
g whee
l
6. One S
ize do
esn’t
fit al
l
7. In
form
ation
is P
ower
8. Bra
in D
rain
para
lysis
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
6Environment: 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
7Environment: Today’s Approach Leading Methodologies
Initiative Initiative Brief Strong Points
C4ISR
- DoD
Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance
· 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/
Provides for architecture alignment via products, Includes narratives, demonstrated success in DoD agencies, aligns closely with previous Federal approach
UMM UN/CEFACT Modeling Methodology * ebXML adopted
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
Continues with modeling, development of language for communication, Registry
MDA Model Driven Architecture
built on the solid foundation of well-established OMG standards, including: Unified Modeling Language™ (UML™) http://www.omg.org/mda/
Seperates business from technology, graphical
RUP Rational Unified Process™
..engineering processes that provide you with guidance to streamline your team's development activities http://www.rational.com/products/rup
Proven in many developments, graphical
IDEF Integrated Definition 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/
graphical representations of various systems
ECIMF E-Commerce Integration Meta-Framework
for designing and implementing integration bridges between currently incompatible systems. http://www.ecimf.org/
Addresses linguistics
OAGIS Open Applications Interoperability Specification
Content for business software interoperability via BODS http://www.OpenApplications.org
Language, patterns, ERP perspective, ebXML support
X12 ANSI Electronic Data Interchange
EDI - recent added 'slotting' concept with XML http://www.disa.org Standards with modularity
8
Environment: Today’s Approach Existing Mechanisms
STANDARDS STANDARDS
AUTHORATATIVE
SOURCE PRIORITY
PRINCIPLES & RULESPRINCIPLES & RULES
OBJECTIVESOBJECTIVES
MODELS
MODELS
ONTOLOGY ONTOLOGY
REQUIREMENTSREQUIREMENTS
RISK MANAGEMENTRISK MANAGEMENTRISK MANAGEMENTRISK MANAGEMENT
RATIONALERATIONALERATIONALERATIONALE
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
BusinessArchitecture
Technology Architecture
Applications Architecture
Information &Data Architecture
BusinessArchitecture
9Environment: 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
10Environment: Momentum
Source: DONCIO
NetCentric
NetCentric
11
Business Lines Transformation
Federal Enterprise Architecture
DoD Architecture Framework
NASCIOAdaptive Enterprise Architecture
Agile Enterprise
ImplementationImplementation
Netcentricity
Doctrine for
Agility &
Interoperability
Roadmap for going forward and provide traceability from vision to implementation
ArchitectureArchitecture
Getting to the Future - Obtaining our Objectives
12
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
13
Agility Model Information Architecture
Part I: VisionI: Vision
Agenda
11
22
OperationalView
Agenda
OpportunitiesOpportunities
BCM
Paradigm Shift
Environment
14
Information Architecture*
Navigation
Products / Services
Enabling Technologies
Interfaces
Vocabularies
Content
Paradigm Shift Handle an Ever Changing Enterprise
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
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
Volatility
15
Information Architecture
Navigation
Products / Services
Enabling Technologies
Interfaces
Vocabularies
Content
Supporting Information Architecture
High
Low
Stability
Agility Model
Source: Lubash Pyramid
Information Architecture
Enables the management of critical Enterprise information artifacts
16
Source: BusinessCentricMethodology.com
Methodology
Str
ateg
ic T
actic
al
Information Architecture
Enables the management of critical Enterprise information artifacts
BCM ModelApplying Constraints in Layers Where Appropriate
17
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
Information
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
BCM Templates
18
ImplementationTemplates
Tem
plat
e-dr
iven
Tem
plat
e-dr
iven
Operational View - Interoperability Artifacts in Motion
19
Business Operational ViewDomain aspects of business transactions
Business Operational ViewDomain aspects of business transactions
Technology Service ViewIT aspects of business transactions
Technology Service ViewIT aspects of business transactions
1. Improving communication between business domain experts (‘what’) and technologist (‘how’) to maximize new exciting opportunities.
2. Usin
g the sam
e tem
plate m
echanism to
comm
unicate w
ith o
ur
collabora
tion p
artners
BCM Templates – for Effective Communication
20
Action Event
InformationRuleWhatWhy
How When
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
InformationRuleWhatWhy
How When
Action Event
InformationRuleWhatWhy
How When
BCM Templates – Workflow Viewpoint
21Opportunities: 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)
22
SemanticInteroperability
PragmaticInteroperability
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
SynthesizeKnowledge
Templates
Concept
Context
Instance
Constraint
HumanIntelligence
Opportunities: Afforded to an Agile Enterprise 1. Pragmatic & Semantic Interoperability
23
Poor Integration
Traditional Contract
Good Integration
Aligned Ontology
Semantics, Semantics, Semantics
CollaborationPartner #1
CollaborationPartner #1
CollaborationPartner #2
CollaborationPartner #2
Source: Lubash Pyramid
Opportunities: Afforded to an Agile Enterprise 2. Metrics for Interoperability
Separate Ontologies
Contractdriving
Templates
24
Mapping (Option 1)
TransStd
Trans
App
App
InstanceInstanceICIC
MapMap
MapMap
AcrossDomain
Domain
Specific
Trans
App
InstanceInstance
App
Template (Option 2)
Registry
Target
ICIC
Opportunities: Afforded to an Agile Enterprise 3. Providing Options for Interoperability
Baseline
Specification
PopulatedTemplates
What is harder? Sending or Receiving?
25 Opportunities: Afforded to an Agile Enterprise 4. Trend Toward Service-Oriented Architectures
SHIFTSHIFT SHIFTSHIFT
Hub n’ Spoke Service Oriented (SOA)Centralized data processing only
Virtual Pt.-to-Pt.Physical Artifacts
Broker-based Metadata Strategy Reuse: High Central
End-to-End Tracking: Yes, CentralIntegration at Broker
Lookup Info: Must publish to BrokerMapping: Two or more
Bandwidth Required: HighestComputing: Central; Big Iron
Impact of Changes: HighPt.-to-Pt. Real-time: No
Technology Solution
Central & Distributed data processing Common Pt.-to-Pt. Mechanism
Logical & Physical ArtifactsEnterprise Metadata Strategy
Reuse: Much OpportunityEnd-to-End Tracking: Services
Integration at Point of UseLookup Info: Kept at Domain
Mapping: OnceBandwidth Required: LowestComputing: Distributed Load
Impact of Changes: LowPt.-to-Pt. Real-time: Yes
Business Solution
Ad HocDistributed data processing
Simple Pt.-to-Pt.Physical Artifacts
No Metadata Strategy Reuse: Little OpportunityEnd-to-End Tracking: LowIntegration at Point of Use
Lookup Info: Kept at DomainMapping: Only Once
Bandwidth Required: LowestComputing: Distributed Load
Impact of Changes: LowPt.-to-Pt. Real-time: Yes
Immediate Solution
Business-Centric Methodology becomes ever more critical
26 Opportunities: Afforded to an Agile Enterprise 5. Supporting Communities of Interest - CoI
Ontology
Composite
• Institutional communicates and navigates Enterprise via ontology
• Expedient through discovery and use via CM Search
Viewports / Capabilities
CM Service
Sear
ch
Create
Domains
Source: http://www.CollaborativeMemory.com
Search
Results
Registry
Persistence
Using History-of-Use Filtering to leverage relationships between users and Enterprise artifacts
Architecture
Architecture
27
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.
28
Part I: VisionI: Vision
Agenda
11
22
Strategy Infrastructure
33 Part II: ImplementationII: Implementation
Agenda
PlansPlans
Paradigm Shift
Tac
ticsMoving Enterprise Forward
CoI
Environment
29Strategy to Moving the Enterprise ForwardBrown 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 ForwardGreen 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
Project Start DesignDesign Develop
& TestDevelop& Test
Metadata management plays a role
*
Deploy
31
Strategy to Moving the Enterprise ForwardInformation Architecture with XML technology
Motivation Time People
Specifications Schema
Workflow
Contract
Directory Services
Collaboration PartnerProfiles - CPP
Collaboration PartnerProfiles - CPP
2
1
3
4
5
Presentation
Collaboration PartnerAgreements- CPA
Collaboration PartnerAgreements- CPA
Artifact relationships
Content Assembly Mechanism - CAM
Content Assembly Mechanism - CAM
BP SpecificationBP Specification
Data/Codes Services/Functions Network
XFormsXForms
MSH/SOAPMSH/SOAP
Source: Lubash Pyramid
VerbsVerbs
MessagesMessages
RulesRules EventsEvents
ProcessProcess
RolesRoles
TransportRouting, Packaging
TransportRouting, Packaging
NounsNouns
Core Components
Core Components
WSDLWSDL
32
LegacyTransactions
LegacyTransactions
Business Layer
ConceptsConcepts
Conceptual Layer
Communities of Interest
Business Drivers: Model / Process / Patterns / Constraints
Alias
Business Goals
Reuse -CompoundConstructs
ContextContext
Target ConstructsTarget Constructs
Baseline SpecificationBaseline SpecificationMappingsMappings
Implementation Layer
PhysicalPhysical
LegacyModel / Stores
LegacyModel / Stores
Extension Layer
ContractContract
Technology Model / Constraints
Alias
Frameworks & StandardsFrameworks & Standards
Pub
lish
Middle Out Transitioning
Architecture Products
Architecture Products
Design ProductsDesign
Products
Business rules / Patterns / etc.
Ontology - Classification - Taxonomy - Thesaurus
Strategy to Moving the Enterprise Forward
Collect ConnectCommunicate Correlate Contract/ Choose
Catalog
11 22 33 44 55 66
Phase 1 Phase 2
Best Value
Register Alignment
RegisteredEntity
Relationships
Strategy to Moving the Enterprise ForwardDelivering Business Value
Infrastructure to Move the Enterprise ForwardMajor Supporting Services / Components
Rules/Mapping Engine
WorkflowOntology
•Taxonomy•Semantic Network
TemplateProcessor
•Thesaurus •Classifications
Federated
Visualization Tools
Index / Clustering
MajorInfrastructure
Services / Components
• Shared URLs (Favorites / Bookmarks)• Intelligent Filters – Dynamic Channeling• Issues and Risk Mitigation• Coexistence
• Conference / Thread Tracking• Presentations / Whiteboards
• Shared Directories / Documents• Forums• Chat, IRC, etc.• Email
• Shared Services / Applications• Contacts• Events• Project• Customer / Help, etc.
• Collaboration Partner Alignment – Map• Registry of concepts & reusables• Rationale Templates & Thesaurus• Classification – Taxonomy – Ontology
InformationEnabling
FunctionSharing
GroupLeveraging
InformationSharing
Infrastructure to Move the Enterprise Forward Collaboration Mechanisms
(Portal, etc.)
36Moving 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
37
Part I: VisionI: Vision
Agenda
11
22
33
Part II: ImplementationII: Implementation
44
Artifacts
ConceptualBusiness
ExtensionImplementation Layers
Detailed
Agenda
Del
ive
rab
les
Products
Paradigm Shift
Moving Enterprise Forward
Environment
38BCM 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
39
Business Layer
ConceptsConcepts
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
Str
ateg
ic T
actic
al
Alias
Business Goals
Reuse -CompoundConstructs
ContextContext
- concept
- linking
- construct
Target ConstructsTarget Constructs
Baseline SpecificationBaseline SpecificationMappingsMappings
Implementation Layer
PhysicalPhysical
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
LegacyLegacy
Extension Layer
ContractContract
Technology Model / Constraints
Alias
Frameworks & StandardsFrameworks & Standards
Pub
lish
BCM - Layers Detailed
40
Business Goals
Vision Statement
Vision Statement
Policies
Architectures
BalancedScorecard
A
Strategic Plans PerformanceAgreements
GoalPatterns
Targets, Measures &
Assessments
- concept
- linking
- construct
Conceptual Layer – Drivers
Align ambiguous, competing, and conflicting drivers to Enterprise goals
ConceptsConcepts
Conceptual Layer
Business Goals Frameworks & StandardsFrameworks & Standards
41
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
Conceptual Layer – Drivers
Align frameworks & standards selection to Enterprise goals
ConceptualBusiness
ExtensionImplementation
42
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
Conceptual Layer Tasks
From: Cost Issues To: Business Advantage Results: Customer Best Value
ConceptualBusiness
ExtensionImplementation
43
Use Case
• Describe scenarios• Diagram and/or paragraph form
Sequence Diagrams• Players and objects in time sequence• Happy and Sad Paths
Conceptual Layer Tasks
Maintain Account
Accounting System
Act Manager
Semantics• Business Context• Use Case and Sequence• Authoritative Sources• Business Concept Definition• Concepts Registration• Classification Assignment• Ontology Placement
ConceptualBusiness
ExtensionImplementation
44
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
Conceptual Layer Tasks
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
Preferenceper your
Community
Order of Authority
Preferenceper your
Community
Provides for lexical alignment to help understand our business semantics
ConceptualBusiness
ExtensionImplementation
45
Concepts Registration
• Register/Link to Authoritative Source Concepts
Conceptual Layer Tasks
RepositoryRepository
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
ConceptualBusiness
ExtensionImplementation
TrustTrust
46
Classification Assignment e.g. DUNS
• Multiple Facets or combination of characteristics
Conceptual Layer Tasks
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
Bus
ines
s L
ine
Classw
ord
Semantics• Business Context• Use Case and Sequence• Authoritative Sources• Business Concept Definition• Concepts Registration• Classification Assignment• Ontology Placement
Business Line
Concept
ConceptualBusiness
ExtensionImplementation
47
• 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
Conceptual Layer Tasks
?
?
?
"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
Sta
bi li
ty
least
most
Place concepts in ontology base
ConceptualBusiness
ExtensionImplementation
48
Conceptual Artifacts
VerbsVerbs
Motivation Time People
RulesRules EventsEvents RolesRoles
TransportRouting, Packaging
TransportRouting, Packaging
2
1
Source: Lubash Pyramid (Note: rows 1 & 2 equate to Zachman’s columns)
NounsNouns
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
49
Conceptual Artifacts + Products
VerbsVerbs
Motivation Time People
RulesRules EventsEvents RolesRoles
TransportRouting, Packaging
TransportRouting, Packaging
2
1
Source: Lubash Pyramid (Note: rows 1 & 2 equate to Zachman’s columns)
NounsNouns
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
50
Part I: VisionI: Vision
Agenda
11
22
33
Part II: ImplementationII: Implementation
44
Artifacts
Conceptual
ExtensionImplementation Layers
Detailed
Agenda
Del
ive
rab
les
Products
Paradigm Shift
Moving Enterprise Forward
Environment
Business
51
Requirements • Business rules / patterns• Atomics & constructs• Structure: Resolution / Indenture• Workflow / process identification• Mandatory vs Optional • Sub-setting Codelists
Business Layer
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
Business choices drive the Enterprise’s Agility and Interoperability
Business Layer
ConceptsConcepts
Communities of Interest
Business Drivers: Model / Process / Patterns / Constraints
Reuse -CompoundConstructs
ContextContext
Target ConstructsTarget Constructs
52
Requirements • Business rules / patterns• Atomics & constructs• Structure: Resolution / Indenture• Workflow / process identification• Mandatory vs Optional • Sub-setting Codelists
Define Business Rules
Business Layer Tasks
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
ConceptualBusiness
ExtensionImplementation
53
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.
Business Layer Tasks
Identify or reuse business patterns
ConceptualBusiness
ExtensionImplementation
54
Requirements • Business rules / patterns• Atomics & constructs• Structure: Resolution / Indenture• Workflow / process identification• Mandatory vs Optional • Sub-setting Codelists
RelationshipsRelationshipsAttributes
SEQUENCE TARGET CONSTRUCT
object
Atomics and Constructs in Exchange Scope
- independent- dependent
Business Layer Tasks
Attributes
secu
rity
From previously identified messages, identify exchanged objects
ConceptualBusiness
ExtensionImplementation
55
Requirements • Business rules / patterns• Atomics & constructs• Structure: Resolution / Indenture• Workflow / process identification• Mandatory vs Optional • Sub-setting Codelists
Business Layer Tasks
Structure: Resolution / Indenture
- what is included in constructs? - use concatenated or atomic?
Option #1Separate constructs, all switching in ontology
Option #2Single
construct, partial
switching in construct
Determine how to house artifacts and at what resolution level
ConceptualBusiness
ExtensionImplementation
56
Requirements • Business rules / patterns• Atomics & constructs• Structure: Resolution / Indenture• Workflow / process identification• Mandatory vs Optional • Sub-setting Codelists
Business Layer Tasks
Workflow / Process IdentificationDefine the message flow and control ‘states’ between applications or collaboration partners
ConceptualBusiness
ExtensionImplementation
57
Requirements • Identify business rules / patterns• Scope; atomics & constructs• Structure: Resolution / Indenture• Workflow / process identification• Mandatory vs Optional • Sub-setting Codelists
Business Layer Tasks
Mandatory vs Optional Sub-setting Codelists• # of requirements/parties
increases the probability that an element becomes ‘optional’ - constraints simplify the message!
Superset Subset
Published Sete.g. EDI Standards
Collaboration Partner or Industry Specific
Focus on Attribute DetailsDetermine what are the attributes; mandatory/optional and domains for each state of the business object
ConceptualBusiness
ExtensionImplementation
58
VerbsVerbs
Motivation Time People
MessagesMessages
RulesRules EventsEvents RolesRoles
Specifications Schema
TransportRouting, Packaging
TransportRouting, Packaging
2
1
3
NounsNouns
Data/Codes Services/Functions Network
ProcessProcess
Workflow4
Source: Lubash Pyramid
Business Layer Artifacts
Position to share workflow with Collaboration Partners
Connect concepts with constraints
Target Constructs = Concepts + Constraints
Related to messages in multi-party workflow
59
VerbsVerbs
Motivation Time People
MessagesMessages
RulesRules EventsEvents RolesRoles
Specifications Schema
TransportRouting, Packaging
TransportRouting, Packaging
2
1
3
NounsNouns
Data/Codes Services/Functions Network
ProcessProcess
Workflow4
Source: Lubash Pyramid
Business Layer Artifacts + Products
• Business Line - Business Pattern • Pattern – Workflow• Workflow – Event – Process -- Service• Service – Component - Data – Rule• Rule – Role -- Security• Rule – Goals and Metrics
60
Part I: VisionI: Vision
Agenda
11
22
33
Part II: ImplementationII: Implementation
44
Artifacts
Conceptual
Implementation LayersDetailed
Agenda
Del
ive
rab
les
Products
Paradigm Shift
Moving Enterprise Forward
Environment
Business
Extension
61
Outreach • Role-Process Identification • Standards & Framework Adoption• Thesaurus Assignment• Interchange Mapping • Qualifier to Object Breakout
Extension Layer
- concept
- linking
- construct
Supporting heterogeneous trading partner environments; within existing capability while moving to the future.
Baseline SpecificationBaseline Specification
LegacyLegacy
Extension Layer
Frameworks & StandardsFrameworks & Standards
Target ConstructsTarget Constructs
62
Outreach • Role-Process Identification • Standards & Framework Adoption• Thesaurus Assignment• Interchange Mapping • Qualifier to Object Breakout
Extension Layer Tasks - Who / How
Role-Process Identification
Business Layer Extension Layer Implementation Layer
Collaboration Partner specific
XML
EDI
UDF
Community # 1
Community # 2
Community # 3
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
ConceptualBusiness
ExtensionImplementation
63
Collaboration
Partner #1
Collaboration
Partner #2
Business (Logical)
Extension Layer Tasks - What
• Target – External / Legacy
Standards & Framework Adoption• Thesaurus Assignment• Interchange Mapping• Qualifier (typing) to Object Breakout (explicit vs. code)
64
Part I: VisionI: Vision
Agenda
11
22
33
Part II: ImplementationII: Implementation
44
Artifacts
Conceptual
LayersDetailed
Agenda
Del
ive
rab
les
Products
Paradigm Shift
Moving Enterprise Forward
Environment
Business
ExtensionImplementation
65
- concept
- linking
- construct
Implementation Layer
Tailor Collaboration Partner SpecificsTechnologist develop interchanges and user interfaces
using [1] Target Constructs or [2] Baseline Specifications with supporting products within partner
constraints.
Baseline SpecificationBaseline SpecificationMappingsMappings
Implementation Layer
PhysicalPhysical Transaction / Presentation • Collaboration Partner Specifics
• Mandatory vs Optional• Elements vs Attributes • Length, Datatyping and Masking• Routing & Packaging• Service Parameters
ContractContract
Technology Model / Constraints
66Implementation Layer – CAM Template
<MapStructure><MapStructure>
<Rules><Rules>
<MapRule output="Product List" input="@PARENT()" path="" /><MapRule output="Product List" input="@PARENT()" path="" />
<MapRule output="<MapRule output="namename" input="Qrt/Product/Item@" input="Qrt/Product/Item@namename" />" />
<MapRule output=“<MapRule output=“madebymadeby" input="Qrt/Product/Item@" input="Qrt/Product/Item@mademade" />" />
<MapRule output="<MapRule output="valuevalue" input="Qrt/Product/Item@" input="Qrt/Product/Item@valuevalue" />" />
<MapRule output="<MapRule output="soldsold" input="Qrt/Product/Item@" input="Qrt/Product/Item@soldsold" />" />
<MapRule output="Product List" input="@ENDPARENT()" /><MapRule output="Product List" input="@ENDPARENT()" />
</Rules></Rules>
</MapStructure></MapStructure>
Content Assembly Mechanism
<CAM> <AssemblyStructure/> <PartnerUseContext/> <ContentReference/> <DataValidations/></CAM>
<CAM> <AssemblyStructure/> <PartnerUseContext/> <ContentReference/> <DataValidations/></CAM>
67
allowing for Enterprise-level crosswalks and light transactions
Collaboration
Partner #1
Collaboration
Partner #2
Business (Logical)
RegistryRegistry
PartNumber Color
PartNo
X12
EDIFACT
DFAS.PartNum
<ELEMENT name=‘PartNumber’…
<dc:identifer> DFAS.PartNum…
<ELEMENT name=‘PartNumber’…
<dc:identifer> DFAS.PartNum…
Schema or CAM Template
<ELEMENT name=‘PartNo’…
<dc:identifer> DFAS.PartNum…
<ELEMENT name=‘PartNo’…
<dc:identifer> DFAS.PartNum…
Schema or CAM Template
(Physical)XML Instance /Content
DataXML Instance / Content
<PartNo> 999…Machine-to-
Machine
<PartNumber> 999…<Color> Black…
Ontology Providing Interpretation Support
68
VerbsVerbs
Motivation Time People
MessagesMessages
RulesRules EventsEvents
ProcessProcess
RolesRoles
Specifications Schema
Workflow
TransportRouting, Packaging
TransportRouting, Packaging
Directory Services
Collaboration PartnerProfiles
Collaboration PartnerProfiles
2
1
3
4Presentation
Collaboration PartnerAgreements
Collaboration PartnerAgreements
Artifact relationships
NounsNouns
Data/Codes Services/Functions Network
Contract
5
Source: Lubash Pyramid
Implementation Layer Artifacts
Contract is the formalization and linking of supporting pyramidTemplates
69
VerbsVerbs
Motivation Time People
MessagesMessages
RulesRules EventsEvents
ProcessProcess
RolesRoles
Specifications Schema
Workflow
TransportRouting, Packaging
TransportRouting, Packaging
Directory Services
Collaboration PartnerProfiles
Collaboration PartnerProfiles
2
1
3
4Presentation
Collaboration PartnerAgreements
Collaboration PartnerAgreements
Artifact relationships
NounsNouns
Data/Codes Services/Functions Network
Contract
5
Source: Lubash Pyramid
Implementation Layer Artifacts + Products
• 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)
CP
A
• Message – Internals (database, etc.)• Message – Communications - Topology
70
Summary
71 Root Causes / Tasks
1-3.
Seman
tics
4. Fra
mewor
ks ar
e com
plex
5. Tak
e bac
k the s
teerin
g whee
l
6. One S
ize do
esn’t
fit al
l
7. In
form
ation
is P
ower
8. Bra
in D
rain
para
lysis
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
72 Root Causes / Tasks
1-3.
Seman
tics
4. Fra
mewor
ks ar
e com
plex
5. Tak
e bac
k the s
teerin
g whee
l
6. One S
ize do
esn’t
fit al
l
7. In
form
ation
is P
ower
8. Bra
in D
rain
para
lysis
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
73
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.
74
Thank you
AuthorsAuthorsMike Lubash - Defense Finance and Accounting ServiceMike Lubash - Defense Finance and Accounting ServiceBruce Peat - eProcess SolutionsBruce Peat - eProcess SolutionsDavid RR Webber - eProcess SolutionsDavid RR Webber - eProcess Solutions
ContributorsContributorsEric Okin - Defense Finance and Accounting ServiceEric Okin - Defense Finance and Accounting ServiceKit C.J. Lueder - The MITRE CorporationKit C.J. Lueder - The MITRE CorporationCharlie Clark - Engineering, Management & Integration, Inc.Charlie Clark - Engineering, Management & Integration, Inc.
http://BusinessCentricMethodology.com
75
Past Future
Understandingthe Challenge
Today’sApproach
Agility Model Information Architecture
Part I: VisionI: Vision
Agenda
11Momentum Doctrine for Agility
and Interoperability
Doctrine for Agility and Interoperability
22
OperationalView
Strategy Infrastructure
33
Part II: ImplementationII: Implementation
44
Artifacts
ConceptualBusiness
ExtensionImplementation Layers
Detailed
Agenda
OpportunitiesOpportunities
BCM
Del
ive
rab
les
PlansPlans
Products
Paradigm Shift
Tac
ticsMoving Enterprise Forward
CoI
Environment
Backup for side: 3
76 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.”
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
77 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.
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
78 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.
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
79 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.
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
80 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.
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
81 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.
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
82 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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’?
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
83 Root Causes
1. Semantics, Semantics, and Semantics 4. Frameworks are complex (and conceptual)5. Failure of business managers to ‘take back’ the steering wheel6. One size doesn’t fit all7. Information is power8. Brain drain paralysis9. Funding for integration infrastructure10. 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.
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
84
Initiative Initiative Brief Strong Points BCM Value-Add
C4ISR
- DoD
Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance
· 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/
Provides for architecture alignment via products, Includes narratives, demonstrated success in DoD agencies, aligns closely with previous Federal approach
Information Architecture, interoperability solution, conceptual alignment, rationale capture, traceabiity, scaleable
UMM UN/CEFACT Modeling Methodology * ebXML adopted
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
Continues with modeling, development of language for communication, Registry
Provides declarative templates, Addresses linguistics
Provides declarative templates, Addresses linguistics
Provides declarative templates, Addresses linguistics
Provides declarative templates, Addresses linguistics
MDA Model Driven Architecture
built on the solid foundation of well-established OMG standards, including: Unified Modeling Language™ (UML™) http://www.omg.org/mda/
Seperates business from technology, graphical
RUP Rational Unified Process™
..engineering processes that provide you with guidance to streamline your team's development activities http://www.rational.com/products/rup
Proven in many developments, graphical
IDEF Integrated Definition 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/
graphical representations of various systems
ECIMF E-Commerce Integration Meta-Framework
for designing and implementing integration bridges between currently incompatible systems. http://www.ecimf.org/
Addresses linguistics Target Constructs with outreach mechanism
OAGIS Open Applications Interoperability Specification
Content for business software interoperability via BODS http://www.OpenApplications.org
Language, patterns, ERP perspective, ebXML support
provides non-standard option
X12 ANSI Electronic Data Interchange
EDI - recent added 'slotting' concept with XML http://www.disa.org Standards with modularity
provides non-standard option
Business-Centric Methodology ComplementsBackup for side: 7
Environment: Today’s Approach BCM Complements with Value-Add
85 Discover, Align, eBusiness
source: ebXML
Backup for side: 10
86
VerbsVerbs
Motivation Time People
MessagesMessages
RulesRules EventsEvents
ProcessProcess
RolesRoles
Specifications Schema
Workflow
Contract
TransportRouting, Packaging
TransportRouting, Packaging
Directory Services
2
1
3
4
5
Presentation
Artifact relationships
NounsNouns
Data/Codes Services/Functions Network
Source: Lubash Pyramid
Information Architecture Artifacts for Interoperability
Ontology; set of relationships, includes a Thesaurus to align vocabularies with business concepts
Backup for side: 15
87
Business Layer
Conceptual Layer
Business Drivers: Model / Process / ConstraintsTarget Constructs & Patterns Target Constructs & Patterns
Implementation Layer
Physical - Message & PresentationPhysical - Message & Presentation
Extension Layer
Contract -Collaboration Partner Specific Constraints
Pub
lish
Baseline Specification per CoIBaseline Specification per CoI
Concepts in OntologyConcepts in Ontology
Business Goals
Frameworks & Standards
Legacy
Authoritative Sources
Str
ateg
ic T
actic
al
Backup for side: 16
BCM Model - Constraints Defined in Layers
88
EventsRules
Schema Schema
Operational View: Interoperability Artifacts in Motion
ContractContractAgreement Pattern
WorkflowWorkflowModeling & Business Patterns
request
process
response
process
reject
accept propose
counter
Exchange Exchange
SpecificationSpecificationModel & Schemas
Nouns
VerbsTransport
RolesConceptConceptOntology
Tem
plat
e-dr
iven
T
empl
ate-
driv
en
Bus
ines
s G
oals
Bus
ines
s G
oals
Go a
l Pa t
tern
Backup for side: 18
89
Backup for side: 25
Business Applications and Functions
Assurance
Access
Gateway
Workflow
Exchange
Bac
k-E
nd
En
terp
rise
In
form
atio
n
Ser
vice
s L
ayer
-
EIS
LF
ron
t-E
nd
DCR
Collaboration
AppsWeb
BrowserEmailClient
Telephone Wireless
Finance Account HRProjectMgmt
Procure
User Interface - Presentation
22CommonExchangeSOAP-basedEnvelope HTTP
11
Common ServicesWeb Services
DCW
Registry
DCD
Service-Oriented Architecture Reference Model
90Our Story, and we are sticking to it
Backup for side: 27
91
Backup for side: 29
Information Management
Value-Added Hierarchy
PackagedSolutions
MetadataManagement
SEMANTICS
Minimum Level
Management Level = Degree of
Control PORTAL PORTAL
Critical Communications Baseline
Service, , Product
92
Backup for side: 34
BCM Infrastructure Conops
93
Business Layer
ConceptsConcepts
Conceptual Layer
Business Goals
Target ConstructsTarget Constructs
Baseline SpecificationBaseline SpecificationMappingsMappings
Implementation Layer
PhysicalPhysical
LegacyLegacy
Extension Layer Alias
Frameworks & StandardsFrameworks & Standards
Pub
lish
Agreed XML Schemas based on Impl.Guide: - X12-Based - DFADM-based
DFAS X12 & DFADMImplementationGuides
X12 & DFADMBased Systems
DFADM Constructs
X12 EDIStandard
Considered Concepts: CIQ HR-XML Quickbooks-XML
Adopted Concepts: ECCMA DFADM (DDDS)
DFAS Conceptual Constructs Based On USPS
Published Target Constructsas XML Schemas
Backup for side: 36
Address Example
94
Resolve Semantics
Define business context Collaborative postal address & name, between USPSand DoD
Use case, sequencediagram
Use Case: Scopes the project, addr. taxonomySequence Diagram: N/A; reusable artifact embedded inother processes
Identify authoritativesources
USPS, ECCMA, X12, DFADM, CEN, OASIS CIQ, HR-XML, QuickBooks (In priority order)
Register/link sourceconcepts
ECCMA chosen because: Endorsed by USPS; ECCMAattributes at atomic level.
Register internalconcepts
XML Schema file of postal address based on ECCMAelements (named data types)
Assign classification ECCMA single-layer groupings (name, address,administrative attributes), DoD Classword
Place in ontology fororganization
DoD XML Registry, Finance namespace; promote toEnterprise NS if general interest
Address Example: Conceptual Layer
Backup for side: 36
95
Resolve Requirements
Document business rules& patterns
Rules: Default country=USARequire name, address-line, city, state, zip.Patterns: Hierarchical layers with bottom-up routing
Scope: atomic & constructartifacts
Atomic: individual ECCMA/X12 attributesConstruct: Postal address, name, addr linesAttributes grouped Name, Addr. Lines, City,State/Prov., Post-Code, Country
Structure: resolution,indenture
High resolution detailed elementsLow res. concatenated fields (X12 legacy)
Workflow & processidentification
Postal address for ship-to party, vs. bill-to, vs. payableparty, ...
Mandatory vs. optional General atomic & assembly artifacts optional.Mandatory N/A determined by business rules
Sub-setting codelists(multi-field issue)
E.g., If country=USA, State/province code limited to theUSPS code values for US.
Address Example: Business Layer
Backup for side: 36
96
Outreach to Legacy, Frameworks and Standards
Role-process identification N/A; reusable artifact embedded in other processes
Standards & frameworkadoption
XML-based transaction syntaxECCMA postal & name attributes (for target)DFADM & X12-based attributes (for legacy)Resource Description Framework (RDF) & DublinCore for metadataCEN (future, based on USPS adoption)
Qualifier to object breakout "Urbanizaton" qualifies "BoxNumber" as Rural Routeor APO (not discrete elements)
Thesaurus assignment Spreadsheet to associate related attributes: inECCMA, X12, DFADM with business mapping rules.E.g., ECCMA CityName to X12 City.
Interchange mapping (No ECCMA XML interchange now.)Near term: DFADM, XML artifacts to legacy DFASCorporate Database (DCD) & X12 EDI
Address Example: Extension Layer
Backup for side: 36
97
Backup for side: 36
Collaboration Partnerspecifics
DFAS Published:Specifies interchange generation and processing
Elements vs.attributes
Each artifact is an XML element, defined using nameddatatypes.
Length, datatyping &masking
Length unspecifiedMost datatypes are xsd:stringMasking by xsd:enumeration or xsd:pattern
Routing & packaging N/A; reusable artifact embedded in other constructs
Service parameters N/A; reusable artifact embedded in other contexts
Framework envelope N/A; reusable artifact embedded in other constructs
ImplementationLayer:Based UponImplementationAgreement
Resolve transactions, presentation
Address Example: Implementation Layer
98
Backup for side: 42
Option #1: Metadata Management as a Natural Aspect of the Process
Expedited “Fast Track” Alternative
Project Start
Project Start DesignDesign Develop
& TestDevelop& Test
Deploy
Project Start
Project Start DesignDesign Develop
& TestDevelop & Test
Deploy
LinkMetadata
LinkMetadata
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.
99
Option #1: Non- Standard #2: Implement Standards #3: Target Construct
Expedited “Fast Track” Alternative - Costs
Costs to the Enterprise are based on interoperability opportunities...
CO$T
Current Approach Business-CentricMethodology
Notes
Metric $ Metric $
Conceptual Layer Priceless Understanding Business Scope
$20,000 Defining Authorative Source Preference Tree
|
Concepts 5,000 $2,500,000 Business concepts = Data concepts * 2
| 276,000 $8,280,000 Alias costs = Partners * Elements * $30
|
Business Layer Average number of concepts per construct: 15
|
Target Constructs 333 $1,666,667 Construct costs: $5,000
|
Extension Layer 6,000 $950,000 Trading partner - standard
| 132,000 $20,900,000 Trading partner - non-standard
Implementation Guide 52,800 $8,360,000 Legacy
|
|
Implementation Layer 200,000 190,800 $1,590,000 Syntax for Extension Layer
| 9,200 $1,533,333 Remaining links (Model and Syntax Costs)
|
Physical $133,333,333
$133,333,333 $45,800,000
$$$$$$$$$$$$
InteroperabilityCost
least
most
Backup for side: 42
100Conceptual Layer - Concept Template
Backup for side: 44
101
Backup for side: 44
Concept Breakout...
Conceptual Layer Tasks
Business ObjectsBusiness ObjectsCommunicationsCommunications
e.g. exchange, notification, query/response e.g. address, organization, account
• Independent• Dependent
Code Listsclassification
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
ConceptsConcepts
Conceptual Layer
Business Goals Frameworks & StandardsFrameworks & Standards
102
Backup for side: 46Source: HyperSystems
Drill-down with Faceted ClassificationConceptual Layer Tasks
103
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE(CONTEXTUAL)
MODEL(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEMMODEL(LOGICAL)
TECHNOLOGYMODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = FieldReln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data EntityReln = Data Relationship
e.g. Semantic Model
Ent = Business EntityReln = Business Relationship
List of Things Importantto the Business
ENTITY = Class ofBusiness Thing
List of Processes theBusiness Performs
Function = Class ofBusiness Process
e.g. "Application Architecture"
I/O = User ViewsProc .= Application Function
e.g. "System Design"
I/O = Screen/Device FormatsProc.= Computer Function
e.g. "Program"
I/O = Control BlockProc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business ProcessI/O = Business Resources
List of Locations in which the Business Operates
Node = Major BusinessLocation
e.g. Logistics Network
Node = Business LocationLink = Business Linkage
e.g. "Distributed System
Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics
e.g. "System Architecture"
Node = Hardware/SystemSoftware
Link = Line Specifications
e.g. "Network Architecture"
Node = AddressesLink = Protocols
e.g. NETWORK
Architecture"
Planner
Owner
Builder
ENTERPRISEMODEL
(CONCEPTUAL)
Designer
SYSTEMMODEL
(LOGICAL)
TECHNOLOGYCONSTRAINED
MODEL(PHYSICAL)
DETAILEDREPRESEN-
TATIONS (OUT-OF
CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-conditionMeans = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural AssertionMeans =Action Assertion
End = Business ObjectiveMeans = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing CycleTime = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine CycleTime = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business EventCycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization UnitWork = Work Product
e.g. Human Interface
People = RoleWork = Deliverable
e.g. Presentation Architecture
People = UserWork = Screen Format
e.g. Security Architecture
People = IdentityWork = J ob
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
Copyright - John A. Zachman, Zachman International
SCOPE(CONTEXTUAL)
Architecture
e.g. STRATEGY ENTERPRISE
e.g. Business Plan
TM
Zachman Institute for Framework Advancement - (810) 231-0531
Zachman Framework
Backup for side: 48
104
Backup for side: 53
Business Layer Tasks - Pattern Types
· 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/
105
Backup for side: 53
Business Layer Tasks - Pattern Examples
Verb-orientedIf 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
106Setting the Tone: Electricity Analogy
Joseph Priestley's Laboratory, c. 1775
Impl
emen
tati
on C
ompl
exit
y
Bus
ines
s V
alue
XMLTechnology
GenericCapability
Level
LowestLevel
(Atomic)
IntermediateLevel
(Structural)
HighestLevel
(Contextual)
XML VocabularyTagging of Nouns and
Verbs
IdentifiableContent and
Actions
XML Aggregation &Structural Collection of
Transactional andRelated Content
Structure andProcesses
XML Classification andRepresentation of DFAS
Business Processes
BusinessIntegration --
Context DefinedBusiness
Constraints
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
107
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.
• 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
Productiv
ity
& Innovatio
n
BCMTemplates to capture rationale
• Collaboration Partner Agreements (CPA)• CPA - Choreography - Message• Message – Internals (database, etc.)• Message – Communications - Topology
Implementation & Infrastructure
• Target – External / LegacyExtension
• 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
Products Linked Together with Templates
Backup for side: 69
BCM Overview
Backup for side: 69
110Search 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