End User Perspective

David White
Technology Manager, webMethods
Johnson & Johnson

Ajay Anand
Manager - Architecture & Integration Services
Johnson & Johnson
Building an Enterprise
Integration Strategy
David White
 Johnson & Johnson
„ Diversifiedhealthcare company founded
in 1886 in New Brunswick, New Jersey.
„ More than 200 operating companies in 54
countries.
– International expansion started in 1919 with
Johnson & Johnson Canada
– Companies established in Latin America,
Europe, Africa and Australia for more than
50 years.
„ Company was family-owned until listed
on NYSE in 1944.
 Independent Businesses & Systems

Medical
Consumer
Devices & Pharmaceuticals
Products
Diagnostics
Customers Customers Customers
Processes Processes Processes
Systems Systems Systems

Corporate
Processes Systems
 Information Flow
External Partners

Medical
Consumer
Devices & Pharmaceuticals
Products
Diagnostics
80% 80% 80%

Corporate
 Funding
„ Project oriented funding model.
„ Contrary to almost all other systems in JNJ,
webMethods’ infrastructure was deployed as a
centralized shared service with cost recovery
model.
No overall fee paid by every company to fund
infrastructure.
Must prove value to the enterprise on a project-by-
project basis.
„ Decentralized IM.
No centralized development organization.
Projects must develop code themselves.
 Early Experiences
„ Decentralized development resulted in a
plethora of:
„ Methodologies
„ Project Plans
„ Documentation Standards
„ Naming Standards
„ Coding Standards/Organization
„ Error handling / Reporting facilities
„ Little reuse
 Total Business Integration
„ The challenges.
How can we design integration today that
will maximize reusability of data for the
integrations of tomorrow?
How can we design integration today that
will minimize the negative effects of
changing or adding systems in the future?
How can we reduce current project design
and development costs?
 Total Business Integration
„ The Solution.
Create a process-oriented integration
framework that is “future-proof” and
seamlessly links our heterogeneous business
applications to facilitate the sharing of
information internally and externally
including partners, customers and other
stakeholders.
 Assumptions
An integration can only be properly understood
in the context of a business process.
Standardizing messages is the key to
maximizing reusability while at the same time
minimizing the negative impact of changing or
adding systems to an integration.
Adopting a standard message structure that has
the support of a large number of software
companies provides the most flexibility,
acceptability, and durability.
 Value Proposition
„ Reusable architecture and processes
Reduced integration time & costs for initial
and follow-on projects.
Standard methodology and resulting
documentation stored in a repository
maximizes leveraging.
• Especially valuable in decentralized development!
Common vocabulary facilitates knowledge
transfer across the enterprise.
Setting the standard for future integration.
 Value Proposition
„ Reduced complexity
Minimizes point-to-point interfaces.
Long term reduction in change management
and maintenance costs.
„ Potential buffer for affiliates from
future changes in application
architecture.
„ Maximizes our middleware
investment and instantiates the use
of XML.
 Value Proposition
„ Ability to scale up development
„ We now have middleware development
taking place around the world rather than in
one place.
„ Being able to distribute integration
development allows the integration team to
be close to a large project no matter where
it takes place.
„ SAP deployment in FL or JDE deployment in NJ.
„ We require consulting firms to use our
methodology.
Application of TBI to a large
integration project
Ajay Anand
 Procure-to-pay Integration
C o rp o ra te F in a n c ia l B u s in e s s P ro c e s s e s

In d ire c t S to c k - D ire c t A c c o u n ts P a ya b le S to c k -In d ire c t M is c e lla n e o u s

(A rib a ) (e -p a ya b le s ) (e -p a ya b le s ) (T o o lc rib )

w e b M e th o d s (u s in g T B I fra m e w o rk )

S A P C o m m o n In te g ra tio n S e rvic e s J D E C o m m o n In te g ra tio n S e rvic e s

Com pany 1 C om pany 2 Com pany 3 Com pany 4

How TBI was applied ?

Define Design Build Deploy

1.0 2.0 3.0 4.0

Project Definition Logical Design Integration Implemented

Business Process Integration Test Design Integration
and Functional Cases Source Code and Solution
Areas Architecture Executables Lessons Learned
SIPOC Diagrams Document Documentation
Use Cases Simulation Unit Test Cases
CTQ Document Document Test Results
Technical CTQ Acceptance
Requirements
SQA Plan and
System Test
Cases
 Business Process Analysis
1 .1 R e q G L
Sequence
V e r ific a tio n

S u p p lie r C a r d 2 + -w a y M a tc h
Y e s (P C O )
O rd e r? (In te r n a l to A r ib a )
1 .2 S u b m it
R e q u is itio n

N o (9 9 )

G e n e ra te 1 .8 P C a r d
2 o r 3 -w a y M a tc h
S u m m a r y S u p p lie r In d v id u a l
(In te r n a l to
1 .3 F in a l C a rd P a ym e n t tr a n s a c tio n
e P a y a b le s )
R e q u is itio n Voucher p o s tin g
A p p ro v a l No

C re a te P a ym e n t IN T E G R A L
1 .6 C r e a te V o u c h e r fo r M o n th ly A M E X based
1 .4 C r e a te /C h a n g e B ill a ffilia te ?
A r ib a P O fo r N o n -
s to c k m a te r ia l
No

1 .7 C re a te
P a ym e n t
Ite m is M a r k e d A ffilia te
R e c e iv a b e ? p o s ts G L
e n tr ie s in
ERP

Yes
P o s t G L E n tr ie s in
Yes
In te g ra l
1 .5 C r e a te /C h a n g e
R e c e ip t

LEGEND

= TBI Scope
 Business Process Analysis
Receives
Affiliate ERP

Project Current
Accounting Process
Data

Future

Verify business
End user Store in
rules, standard Create PO Type
creates requisition Ariba and No
in Ariba
data, Supervisor or PO Change
Reporting DW 99?
ARIBA

approves
YES

Send to
ePayables
ePayables

Store the PO
 Sequence Diagram
A r ib a A ffilia te E R P e P a y a b le s

G L S e q u e n c e V a lid a tio n R e q u e s t()

E R P v e r ifie s G L s e q u e n c e
G L S e q u e n c e V e r ific a tio n R e s p o n s e () a g a in s t its in te r n a l lo g ic .

R e q V a lid a tio n R e q u e s t()

E R P v e r ifie s R e q a g a in s t
R e q V a lid a tio n R e s p o n s e () its in te r n a l lo g ic

S u p p lie r In fo r m a tio n R e q u e s t()

e P a y a b le s s e a r c h e s
S u p p lie r In fo r m a tio n R e s p o n s e () fo r r e q u e s te d s u p p lie r

F in a l A p p r o v e d R e q V a lid a tio n R e q u e s t()

E R P v e r ifie s R e q a g a in s t
its in te r n a l lo g ic
F in a l A p p r o v e d R e q V a lid a tio n R e s p o n s e ()

S u p p lie r In fo r m a tio n R e q u e s t()

e P a y a b le s s e a r c h e s
S u p p lie r In fo r m a tio n R e s p o n s e () fo r r e q u e s te d s u p p lie r

P u rc h a s e O rd e r()
E R P s to re s
p u rc h a s e o rd e r

G o o d s R e c e ip t()
E R P s to r e s G o o d s R e c e ip t

E R P s to re s P C A R D
P C a r d T r a n s a c tio n P o s tin g () tr a n s a c tio n d e ta ils
(P O w ith c o rr e s p o n d in g
d o lla r a m o u n t)
 XML Standard Selection
Procurement

FIXML Human Resources fpML

FinXML
XBRL/XFRML
FIXML Product Development fpML
UBL OAGIS
Analysis Methodology FinXML
BODs
XBRL/XFRML
FIXML Sales, Marketing & CRM fpML
FAML for Financial Research IFX
UBL OAGIS
FinXML
BODs
Open Financial Exchange (OFX)
XBRL/XFRML
FAML for Financial Research Supply Chain Management
CIML fpML
IFX
UBL OAGIS
CPExchange XBRL/XFRML
BODs Exchange (OFX)
Open Financial
UBL FIXML
FAML for Financial Research Finance Business IFX Process
OAGIS fpML
BODs
Open Financial FinXML
Exchange (OFX)
for Financial Research
XBRL/XFRML
FIXML
IFX fpML
Criteria xBRL xCBL UBL OAGIS
FinXML XBRL
BODs
Raw Weighted Raw Weighted UBL OAGIS BODs
Score Score Score Score FAML for Financial Research IFX
FAML for Financial Research IFX
Maturity & Industry 2 0.5 3 0.75 Open Financial Exchange (OFX)
Acceptance(25% Open Financial Exchange (OFX) xCBL
Weight)
J&J Business Fit 1 0.25 2 0.50
(25% Weight)

Technical 2.1 1.05 2.3 1.15

Architecture (50%
Weight)
Total 5.1 1.8 7.3 2.4
 Conceptual Architecture
J D E d w a rd s
S AP
O n e W o r ld /W o r ld

In te g r a tio n
In te g r a tio n J D E d w a rd s
S AP S e rv e r
S e rv e r a d a p te r
a d a p te r

B ro k e r
T e rr ito r y

In te g r a tio n
S e rv e r

JD B C
TB D a d a p te r

R ead
F la t F ile s
A rib a e P a y a b le s
 Architecture Recommendation
• Architecture Analysis Document included:
¾Conceptual Architecture
¾Coordination Pattern For Component Communication
¾Application Communication Pattern Definition
¾Error Handling Approach
¾Architecture Review Approach
¾Security Considerations
¾Review of Infrastructure Needs

• Simulation was done to ensure that architecture

meets customer’s needs
 Build Activities
•Integration Design – Details the physical design of the interface
point(s); includes naming standards, error handling, and security
settings
•Unit Test Cases – Based on the integration physical design to
ensure that the interface point adhere to the integration physical
design
•Source Code and Executables – source code for the integrations
and any executables (run-time code that may have been created
•Code Review – Summarizes the results, issues, and follow-ups that
come out of a formal code review
•Test Results – Test Cases for unit, integration and system testing
are all run in this phase; a summary is produced of all of the tests
that were executed, and the results.
 Deliverables Flow
DEFINE DESIGN BUILD DEPLOY
Business Analyst

Business
Tech Req
Process
Document
Analysis
Quality Manager

Software Req WT Integration

Unit Test
QA Plan Report Test
Results
Results

Logical Integration Integration System

System Design WT Test Cases WT Report Test Result
Test Cases Report
Architect / Designer

Error
Architect. Logical Integration
Handling TBD
Document Design Design
Guide

Simulation Code
Document Reviews

Unit Test Source

Developer

Cases Code

FDR FDR FDR FDR Lessons

Governance

Report Report Report Report Learned

Repository Repository CTQ

Repository Repository
Signoff
Benefits from using TBI
Reduced integration time & costs for initial and
follow-on operating companies – 80% re-use goal
(estimated savings for 6 companies above $6
million)
Standardized methodology across multiple
companies (several sub-team’s and SI’s)
Improved accuracy of project estimates
Customer satisfaction
Improved reliability
Successful execution
Simplified governance
Lower TCO