BusinessCentric Methodology

1
Business-Centric Methodology
For Enterprise Agility Interoperability
Mike Lubash DoD Finance and Accounting XML
Community Manager DFAS XML Team Leader Emerging
Technologies
2
Agenda

• Understanding the problem
• that requires a unique approach
• that complements your framework
• Business-Centric Methodology detailed
• Templates
• Concept, Business, Extension, Implementation
• Operational View
• Impact on the organization
• Summary

Exchange !deas
3
Top 10 List of Integration Inhibitors
1. Semantics 2. Semantics 3. Semantics
4. Frameworks are complex 5. Failure of
business managers to take back the steering
wheel 6. One size doesnt fit all 7.
Information is power 8. Brain drain paralysis
9. Funding for integration infrastructure 10.
Human nature
4
Inhibitors Opportunity
         

• Present an interoperability methodology that is
  unique because
• it addresses a majority of the Top 10
  Integration Inhibitors except for...
• 9. Convince management to fund
  interoperability mechanisms
• 10. Provide incentives for sharing to improve
  collaboration
• is business-centric
• Provides traceability from leaders vision to
  implementation
• Aligns the meaning and source of information
  unconstrained concepts
• Applies context constraints in two primary
  levels target constructs and extensions
• Capture the rationale in templates for
  communication re-use
• Templates define state and switching based on
  context
• ROI Templates created by the business user to
  generate communication artifacts
• Provides help from above supporting precise
  communications for Service-Oriented Architecture
  (SOA), between Business Managers/ Technologists,
  etc.
• in a timeless manner
• Captures the business separate from the high
  rate of change of technology
• Provides for an ontology of the organization
  which to build a solid base
• Flexible to allow for project tradeoff of time
  vs money, allowing for expedited tasking

• and provides open declarative mechanisms allowing
  mass customization of diverse vocabularies and
  models within heterogeneous environments

5
Inhibitors Opportunity
         
Present an interoperability methodology that
complements your

• Organizations efforts in linking its vision to
  implementation
• Architecture frameworks
• Reference models
• Documentation and knowledge capture efforts
• Interface specifications
• Modeling and modeling language preference
• Technical approach - e.g. object-oriented, Rapid
  Applications Development (RAD)
• Controls and metrics
• Technology - methodology is technology agnostic

6
Inhibitors Opportunity - Example Methods
7

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

- concept - linking - construct
Frameworks Standards
Business Goals
Conceptual Layer
Business Drivers Model / Process / Patterns /
Constraints
Alias
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Strategic
Business Layer
Context
Community of Interest
Legacy
Reuse - Compound Constructs
Target Constructs

• Outreach
• Role-Process Identification
• Standards Framework Adoption
• Qualifier to Object Breakout
• Thesaurus Assignment
• Interchange Mapping

Extension Layer
Alias
Publish
Technology Model / Constraints
Baseline Specification
Mappings
Partner Profile

• Transaction / Presentation
• Collaboration Partner Specifics

Tactical
Implementation Layer
Service Agreement

• Mandatory vs Optional
• Elements vs Attributes
• Length, Datatyping and Masking
• Routing Packaging
• Service Parameters

Contract
Physical
8
BCM Templates

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

         
 
Information
form
The difference between data and information is
context. Therefore, data must be put in form for
context to be learned.

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Templates

• Outreach
• Role-Process Identification
• Standards Framework Adoption
• Qualifier to Object Breakout
• Thesaurus Assignment
• Interchange Mapping

System of linked forms which are used to prompt
users for metadata and provide input for
automated mechanisms.

• Transaction / Presentation
• Collaboration Partner Specifics

• Mandatory vs Optional
• Elements vs Attributes
• Length, Datatyping and Masking
• Routing Packaging
• Service Parameters

9
BCM Templates for Effective Communication
Business Operational View Domain aspects of
business transactions
2. Using the same template mechanism to
communicate with our collaboration partners
1. Improving communication between business
domain experts (what) and technologist (how)
to maximize new exciting opportunities.
Technology Service View IT aspects of business
transactions
10
BCM Templates - Scope
In addition to rationale, the Templates house the
concepts, context, and constraints
Wisdom Knowledge Information Data
Synthesize Knowledge
Human Intelligence
Abstraction Meta- Metadata Metadata Data
Templates

• Classification
• Ontology
• Patterns

Add Experience
Constraint
Context
Add Structure
Concept
Instance
11
BCM Templates Workflow Viewpoint
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
Where / Who
Where / Who
12
BCM Templates Agreement Viewpoint
This notion is applied as Agreement Templates for
exchanging information
Where / Who
Where / Who
Where / Who
13
Conceptual Layer
Semantics
14
Conceptual Layer Drivers
- concept - linking - construct
Business Goals
Frameworks Standards
Conceptual Layer
Concepts
Business Goals
Vision Statement
Targets, Measures Assessments
Balanced Scorecard
Goal Patterns
Policies
Performance Agreements
Strategic Plans
Architectures
15
Conceptual Layer Drivers
Business Goals
Frameworks Standards
Conceptual Layer
Concepts
Frameworks and Standards

• Some initiatives are
• complete frameworks
• small focused areas

Horizontal Standards (all industries)

• Standards are
• sanctioned bodies
• consortiums
• few companies

Vertical Standards
(specific industries)
Many standards overlap and are duplicative
16
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
You Are Here
Define Business Context
From Business Goals to concepts, constructs, and
communication

• Business Case Analysis (BCA)
• Align with Balanced Scorecard - are we
  addressing the enterprises needs?
• Identify overall issues - prepare problem
  statement(s)
• Feasibility, Risk, Cost Benefit
• Understand organizational drivers (pain,
  opportunity) from each stakeholders perspective
• 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
• Begin iterative process

17
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
Use Case
Sequence Diagrams

• Describe scenarios
• Diagram and/or paragraph form

• Players and objects in time sequence

18
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
Identify Authoritative Sources
Business Concept Definition

• Who is the subject matter experts?
• e.g. Address USPS

• Business Concepts Template
• Agree on definitions
• Alias with sources / derived
• Search Registry

Order of Authority Preference per your Community
Depending on life-cycle of initiative

• Established - Accept
• Early - Collaborate

19
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
Concepts Registration

• Register/Link to Authoritative Source Concepts

• Register/Store Internal Concept

Register
Register
Repository
Store
20
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
Classification Assignment

• e.g. DUNS
• Multiple Facets or combination of characteristics

Location
Classword
Location
Business Line
Arlington Indy Denver Cleveland Pensacola Columbus
X
Code Identifer Angle Date Mass Area
X
Mil Pay Civilian Pay Commercial Pay Accounting
X X
Concept
Business Line
Classword
21
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Business Concept Definition
• Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
Ontology Placement
"Meaningful learning involves the assimilation of
new concepts and propositions into existing
cognitive structures"
?

• Navigation Clarity
• Multiple faceted taxonomies
• Domain(s) Discipline
• Information Architecture
• Business Line

most
Stability
?
least
?
Prof. Joseph D. Novak Cornell
University 1960s
Ontology Set of Relationships
Classifications Taxonomies Codelists
Schemas
22
Conceptual Artifacts
         
 
Unconstrained
Motivation Time People
2
Rules
Events
Roles
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Shift from Data Management to Metadata Management
Source Lubash Pyramid (Note rows 1 2 equate
to Zachmans columns)
23
Conceptual Artifacts Products
 
Motivation Time People
2
Rules
Events
Roles
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Source Lubash Pyramid (Note rows 1 2 equate
to Zachmans columns)
24
Business Layer
Requirements
25
Business Layer
- concept - linking - construct
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
EAI - database structures for all requirements
B2B messages with maximum constraints
For mechanisms this relationship is reversed
EAI mechanisms are a subset of B2B mechanisms
26
Business Layer Tasks
Define Business Rules
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
Business rules e.g. triggers, email
Identify business events and response outcomes
Collection Methods

• Static Analysis
• Extract
• Interactive Sessions

27
Business Layer Tasks
Capture Business Patterns
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
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
28
Business Layer Tasks
Atomics and Constructs in Exchange Scope -
independent - dependent
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
SEQUENCE
TARGET CONSTRUCT
Relationships
Attributes
object
security
Attributes
29
Business Layer Tasks
Structure Resolution / Indenture - what is
included in constructs? - use concatenated or
atomic?
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
Option 1 Separate constructs, all switching in
ontology
Option 2 Single construct, partial switching in
construct
30
Business Layer Tasks
Workflow / Process Identification
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Business rules / patterns
• Atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
31
Business Layer Tasks
Focus on Attribute Details
Business Drivers Model / Process / Patterns /
Constraints
Concepts

• Requirements
• Identify business rules / patterns
• Scope atomics constructs
• Structure Resolution / Indenture
• Workflow / process identification
• Mandatory vs Optional
• Sub-setting Codelists

Business Layer
Context
Community of Interest
Reuse - Compound Constructs
Target Constructs
Mandatory vs Optional
Sub-setting Codelists

• of requirements/parties increases the
  probability that an element becomes optional -
  constraints simplify the message!

Published Set e.g. EDI Standards
Superset Subset
Collaboration Partner or Industry Specific
32
Business Layer Artifacts
         
 
Workflow
4
Process
Connect concepts with constraints
Specifications Schema
3
Messages
Motivation Time People
2
Rules
Events
Roles
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Position to share workflow with Collaboration
Partners
Source Lubash Pyramid
33
Business Layer Artifacts Products
         
 
Workflow
4
Process
Specifications Schema
3
Messages
Motivation Time People
2
Rules
Events
Roles
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Source Lubash Pyramid
34
Extension Layer
Outreach
35
Extension Layer
- concept - linking - construct
Frameworks Standards
Legacy
Target Constructs

• Outreach
• Role-Process Identification
• Standards Framework Adoption
• Thesaurus Assignment
• Interchange Mapping
• Qualifier to Object Breakout

Extension Layer
Baseline Specification
36
Extension Layer Tasks - Who / How
Frameworks Standards
Role-Process Identification
Legacy
Target Constructs

• Outreach
• Role-Process Identification
• Standards Framework Adoption
• Thesaurus Assignment
• Interchange Mapping
• Qualifier to Object Breakout

Extension Layer
Baseline Specification
Trading Partner specific
Business Layer
Extension Layer
Implementation Layer
37
Extension Layer Tasks - What
Standards Framework Adoption

• Thesaurus Assignment
• Interchange Mapping
• Qualifier (typing) to Object (identifier)
  Breakout

Collaboration Partner 1
Collaboration Partner 2
Business (Logical)
38
Transaction / Presentation
Implementation Layer
39
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.
Target Constructs
Scenario 1
Scenario 2
Publish
Technology Model / Constraints
Baseline Specification
Mappings
Partner Profile

• Transaction / Presentation
• Collaboration Partner Specifics

Implementation Layer
Service Agreement

• Mandatory vs Optional
• Elements vs Attributes
• Length, Datatyping and Masking
• Routing Packaging
• Service Parameters

Contract
Physical
40
Implementation Layer CAM Template
ltMapStructuregt ltRulesgt
ltMapRule output"Product List" input"_at_PARENT()"
path"" /gt ltMapRule output"name"
input"Qrt/Product/Item_at_name" /gt
ltMapRule outputmadeby" input"Qrt/Product/Item_at_
made" /gt ltMapRule
output"value" input"Qrt/Product/Item_at_value" /gt
ltMapRule output"sold"
input"Qrt/Product/Item_at_sold" /gt
ltMapRule output"Product List" input"_at_ENDPARENT()
" /gt lt/Rulesgt lt/MapStructuregt
Content Assembly Mechanism
41
Implementation Layer Artifacts
         
 
Collaboration Partner Agreements
Collaboration Partner Profiles
5
Contract
Contract is the formalization and linking of
supporting pyramid Templates
Workflow
4
Process
Specifications Schema
3
Messages
Artifact relationships
Motivation Time People
2
Presentation
Rules
Events
Roles
Directory Services
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Source Lubash Pyramid
42
Implementation Layer Artifacts Products
         
 
Collaboration Partner Agreements
Collaboration Partner Profiles
5
Contract
Workflow
4
Process
Specifications Schema
3
Messages
Artifact relationships
Motivation Time People
2
Presentation
Rules
Events
Roles
Directory Services
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Source Lubash Pyramid
43
Pyramid in Motion
         
 
Business Goals Goal Pattern
reject
counter
Contract Agreement Pattern
accept
propose
Workflow Modeling Business Patterns
response
Template-driven
process

Specification Model Schemas
Schema

Exchange
Concept Registry
Verbs
Roles
Transport
Nouns
Rules
Events
44
Discover, Align, eBusiness
source ebXML
45
Ontology Providing Help From Above
allowing for enterprise-level crosswalks and
light transactions
Business (Logical)
Collaboration Partner 1
Collaboration Partner 2
Registry
DFAS.PartNum
X12
PartNo
EDIFACT
PartNumber
Color
Schema or Template
ltELEMENT namePartNumber
ltdcidentifergt DFAS.PartNum
Schema or Template
ltELEMENT namePartNo ltdcidentifergt
DFAS.PartNum
Machine-to-Machine
XML Instance
XML Instance
Data
ltPartNogt 999
ltPartNumbergt 999 ltColorgt Black
(Physical)
46
Impact on the Organization
47
Trend Toward Service-Oriented Architectures
SHIFT
SHIFT
Hub n Spoke
Service Oriented (SOA)
Ad Hoc
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
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
48
Develop with Metadata Management
Project Start
Design
Develop Test
Deploy

• 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

• 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)

Metadata management plays a role
49
Providing Options for Interoperability
Mapping (Option 1)
Template (Option 2)
App
App
Domain
Std
Trans
Trans
Map
IC
Instance
IC
Instance
Template
Specific
Baseline Specification
Across Domain
Trans
Map
Registry Target
App
App
What is harder sending or receiving?
50
Volatility and the Ever Changing Enterprise
Some of our artifacts are more stable than others
A layered model helps in understanding and
leveraging unique qualities of various
information architecture components
Content
Vocabularies
Interfaces
Enabling Technologies
Services
Need to build on solid base
Navigation Systems
Portal Effort
Ontology Full Business Semantics
51
Artifacts for Interoperability
         
 
5
Contract
Workflow
4
Process
Specifications Schema
3
Messages
Artifact relationships
Motivation Time People
2
Presentation
Rules
Events
Roles
Directory Services
Data/Codes Services/Functions
Network
1
Verbs
Transport Routing, Packaging
Nouns
Source Lubash Pyramid
52
Metrics for Interoperability
         
 
Poor Integration
Good Integration
Collaboration Partner 1
TraditionalContract
Contract driving Templates
Collaboration Partner 2
Aligned Ontology
Separate Ontologies
Semantics, Semantics, Semantics
Source Lubash Pyramid
53
Delivering Business Value
Alignment
Register
Phase 1
Phase 2
Relationships
Registered Entity
Best Value
1
2
3
4
5
6
Collect
Connect
Communicate
Correlate
Contract / Choose
Catalog
54
Executive Summary
         
 

• Business-Centric Methodology is derived from
• Lessons learned from experience
• Mapping EDI transactions and developing
  integration tools
• Language interpretation how concepts are
  critically important
• B2B Exchanges require constrained Information
  Data Context
• Standard languages dont work been there, done
  that
• Business use of spreadsheets metaphor templates
  to guide users
• Asset management assets are metadata and
  meta-metadata
• Search for patterns and best practices e.g.
  agreement

• Business-Centric Methodology is a strategic
  solution that addresses
• Top 10 Integration Inhibitors
• Service-Oriented Architecture (SOA) trend

A tactical-only solution is a waste of money we
need to adopt an enterprise solution that
addresses business context and people.
55
Executive Summary (continued)
         
 

• Business First Templates describe the what
  not the how
• Provides the structure for patterns
• Capture the rationale for later re-course
• Extract Implementation Conventions into
  templates
• Templates to supplement other artifacts, models,
  etc.
• Apply constraints where appropriate for maximum
  reuse
• ROI templates created by business users
  generate message definitions
• Context everywhere through help from above

• It is impossible to unambiguously define
  information for all potential uses unless the
  proper metadata is defined in context
• Context eases integration and reduces cost
• Metadata accessible throughout the workflow for
  interpretation

Build with existing infrastructure and have 1,
2, 5, 10 year plan

• Leverage portal efforts to derive organizations
  ontology
• Develop support network of part-time metadata
  managers and teams
• Apply methodology to proof-of-principles and new
  developments

56
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.
57
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
survival instincts
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.
58
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
Frameworks are complex and 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.
59
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
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
programmers tools (bottom-up) with no
automated solution that addresses development
from business goals to the physical
implementation well.
60
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
survival instincts
One size doesnt 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 dont work, (2) one-size
process models dont work, (3) one-size data
model doesnt work, and (4) one-size transaction
standards dont work.
61
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
Information is power - thus interoperability
requirements become skewed and outputting
information becomes the driver, not a template
driven exchange from the receivers 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.
62
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
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.
63
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature

• 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 isnt 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 todays problems. Should our
  federal government appoint an Interoperability
  Facilitator as well as an e-Gov Director?

64
Top 10 List of Integration Inhibitors
1. Semantics, Semantics, and Semantics 4.
Frameworks are complex 5. Failure of business
managers to take back the steering wheel 6.
One size doesnt fit all 7. Information is
power 8. Brain drain paralysis 9. Funding
for integration infrastructure 10. Human nature
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.

65
Expedited 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 isnt tied into programming structures and
thus can easily linked into the ontology as a
separate development process.
Option 1 Metadata Management as a Natural
Aspect of the Process
Project Start
Design
Develop Test
Deploy
Option 2 Fast Track Alternative
Project Start
Design
Develop Test
Link Metadata
Deploy
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.
66
Expedited Fast Track Alternative - Costs
Costs to the Enterprise are based on
interoperability opportunities...
most
Option 1 Non- Standard 2
Implement Standards 3 Target
Construct
COT
least
Interoperability Cost

67
Conceptual Layer - Concept Template
68
Conceptual Layer Tasks

• Semantics
• Business Context
• Use Case and Sequence
• Authoritative Sources
• Link Source Concepts
• Internal Concepts Registration
• Classification Assignment
• Ontology Placement

Business Goals
Frameworks Standards
Conceptual Layer
Alias
Concepts
Code Lists classification
Concept Breakout...
Put into Objects (bring-out semantics)
List ? Which one?
Business Objects
Communications
e.g. exchange, notification, query/response
e.g. address, organization, account

• Independent
• Dependent

69
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/patt
erns/
70
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
71
Setting the Tone Electricity Analogy
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
Joseph Priestley's Laboratory, c. 1775
72
XMLs 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 doesnt 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.

73
Service-Oriented Architecture Reference Model
User Interface - Presentation
Apps
Web Browser
Email Client
Telephone
Wireless
Front-End
Common Services Web Services
Assurance
1
DCR
Registry
Workflow
Access
Enterprise Information Services Layer - EISL
DCW
DCD
Exchange
Common Exchange SOAP-based Envelope HTTP
2
Collaboration
Gateway
Business Applications and Functions
Back-End
Finance
Account
HR
Project Mgmt
Procure
74
Zachman Framework
75
Products Linked Together with Templates

• MOA Contract
• Goals Deliverables/Outcomes - Metrics

Management
BCM Templates to capture rationale

• Concept UID Resource (Metadata)
• Concept Concept (Thesaurus)
• Concept Classification Taxonomy
• Resource User Role
• Business Model Application Model

Conceptual

• 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
Extension

• Target External / Legacy

• Collaboration Partner Agreements (CPA)
• CPA - Choreography - Message
• Message Internals (database, etc.)
• Message Communications - Topology

Implementation Infrastructure
76
Collaboration Mechanisms
Information Enabling
Collaboration Mechanisms (Portal, etc.)

• Shared URLs (Favorites / Bookmarks)
• Intelligent Filters Dynamic Channeling
• Issues and Risk Mitigation
• Coexistence
• Conference / Thread Tracking
• Presentations / Whiteboards

Group Leveraging

• Shared Services / Applications

Function Sharing

• Contacts
• Events
• Project
• Customer / Help, etc.

Information Sharing
77
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