for enterprise agility

110
For Enterprise Agility & Interoperability Mike Lubash DFAS XML Team Lead DOD Finance and Accounting XML Community Manger Emerging Technologies [email protected]

Upload: aamir97

Post on 28-Jan-2015

122 views

Category:

Technology


1 download

DESCRIPTION

 

TRANSCRIPT

Page 1: For Enterprise Agility

For Enterprise Agility & InteroperabilityFor Enterprise Agility & Interoperability

Mike LubashDFAS XML Team LeadDOD Finance and Accounting XML Community MangerEmerging [email protected]

Page 2: For Enterprise Agility

2

Part I: VisionI: Vision

Agenda

11

22

33 Part II: ImplementationII: Implementation

44

LayersDetailed

Agenda

Paradigm Shift

Moving Enterprise Forward

Environment

Page 3: For Enterprise Agility

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

Page 4: For Enterprise Agility

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

Page 5: For Enterprise Agility

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

Page 6: For Enterprise Agility

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

Page 7: For Enterprise Agility

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

Page 8: For Enterprise Agility

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

Page 9: For Enterprise Agility

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

Page 10: For Enterprise Agility

10Environment: Momentum

Source: DONCIO

NetCentric

NetCentric

Page 11: For Enterprise Agility

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

Page 12: For Enterprise Agility

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

Page 13: For Enterprise Agility

13

Agility Model Information Architecture

Part I: VisionI: Vision

Agenda

11

22

OperationalView

Agenda

OpportunitiesOpportunities

BCM

Paradigm Shift

Environment

Page 14: For Enterprise Agility

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

Page 15: For Enterprise Agility

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

Page 16: For Enterprise Agility

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

Page 17: For Enterprise Agility

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

Page 18: For Enterprise Agility

18

ImplementationTemplates

Tem

plat

e-dr

iven

Tem

plat

e-dr

iven

Operational View - Interoperability Artifacts in Motion

Page 19: For Enterprise Agility

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

Page 20: For Enterprise Agility

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

Page 21: For Enterprise Agility

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)

Page 22: For Enterprise Agility

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

Page 23: For Enterprise Agility

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

Page 24: For Enterprise Agility

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?

Page 25: For Enterprise Agility

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

Page 26: For Enterprise Agility

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

Page 27: For Enterprise Agility

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.

Page 28: For Enterprise Agility

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

Page 29: For Enterprise Agility

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

Page 30: For Enterprise Agility

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

Page 31: For Enterprise Agility

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

Page 32: For Enterprise Agility

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

Page 33: For Enterprise Agility

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

Page 34: For Enterprise Agility

Infrastructure to Move the Enterprise ForwardMajor Supporting Services / Components

Rules/Mapping Engine

WorkflowOntology

•Taxonomy•Semantic Network

TemplateProcessor

•Thesaurus •Classifications

Federated

Visualization Tools

Index / Clustering

Page 35: For Enterprise Agility

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

Page 36: For Enterprise Agility

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

Page 37: For Enterprise Agility

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

Page 38: For Enterprise Agility

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

Page 39: For Enterprise Agility

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

Page 40: For Enterprise Agility

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

Page 41: For Enterprise Agility

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

Page 42: For Enterprise Agility

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

Page 43: For Enterprise Agility

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

Page 44: For Enterprise Agility

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

Page 45: For Enterprise Agility

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

Page 46: For Enterprise Agility

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

Page 47: For Enterprise Agility

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

Page 48: For Enterprise Agility

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

Page 49: For Enterprise Agility

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

Page 50: For Enterprise Agility

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

Page 51: For Enterprise Agility

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

Page 52: For Enterprise Agility

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

Page 53: For Enterprise Agility

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

Page 54: For Enterprise Agility

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

Page 55: For Enterprise Agility

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

Page 56: For Enterprise Agility

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

Page 57: For Enterprise Agility

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

Page 58: For Enterprise Agility

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

Page 59: For Enterprise Agility

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

Page 60: For Enterprise Agility

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

Page 61: For Enterprise Agility

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

Page 62: For Enterprise Agility

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

Page 63: For Enterprise Agility

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)

Page 64: For Enterprise Agility

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

Page 65: For Enterprise Agility

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

Page 66: For Enterprise Agility

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>

Page 67: For Enterprise Agility

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

Page 68: For Enterprise Agility

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

Page 69: For Enterprise Agility

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

Page 70: For Enterprise Agility

70

Summary

Page 71: For Enterprise Agility

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

Page 72: For Enterprise Agility

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

Page 73: For Enterprise Agility

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.

Page 74: For Enterprise Agility

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

Page 75: For Enterprise Agility

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

Page 76: For Enterprise Agility

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

Page 77: For Enterprise Agility

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

Page 78: For Enterprise Agility

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

Page 79: For Enterprise Agility

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

Page 80: For Enterprise Agility

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

Page 81: For Enterprise Agility

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

Page 82: For Enterprise Agility

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

Page 83: For Enterprise Agility

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

Page 84: For Enterprise Agility

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

Page 85: For Enterprise Agility

85 Discover, Align, eBusiness

source: ebXML

Backup for side: 10

Page 86: For Enterprise Agility

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

Page 87: For Enterprise Agility

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

Page 88: For Enterprise Agility

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

Page 89: For Enterprise Agility

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

Page 90: For Enterprise Agility

90Our Story, and we are sticking to it

Backup for side: 27

Page 91: For Enterprise Agility

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

Page 92: For Enterprise Agility

92

Backup for side: 34

BCM Infrastructure Conops

Page 93: For Enterprise Agility

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

Page 94: For Enterprise Agility

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

Page 95: For Enterprise Agility

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

Page 96: For Enterprise Agility

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

Page 97: For Enterprise Agility

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

Page 98: For Enterprise Agility

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.

Page 99: For Enterprise Agility

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

Page 100: For Enterprise Agility

100Conceptual Layer - Concept Template

Backup for side: 44

Page 101: For Enterprise Agility

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

Page 102: For Enterprise Agility

102

Backup for side: 46Source: HyperSystems

Drill-down with Faceted ClassificationConceptual Layer Tasks

Page 103: For Enterprise Agility

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

Page 104: For Enterprise Agility

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/

Page 105: For Enterprise Agility

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

Page 106: For Enterprise Agility

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

Page 107: For Enterprise Agility

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

Page 108: For Enterprise Agility

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

Page 109: For Enterprise Agility

BCM Overview

Backup for side: 69

Page 110: For Enterprise Agility

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