2. Housekeeping
• Welcome
• The
Usual
Concerns
– Ques2ons
and
Answers
– Addi2onal
Materials
– Copies
of
Slides
• Presenter:
Ø
Kevin
King,
Vice
President
for
Client
Delivery
at
AgilePath
Over
20
years
in
Solu2on
Delivery
in
Financial
Services
and
Healthcare
domains
before
joining
AgilePath
three
years
ago
Ø Senaka
Fernando,
Senior
Technical
Lead
at
WSO2
Member
of
WSO2
since
2009,
focused
on
the
WSO2
Governance
Registry
and
WSO2
Cloud
Services
Gateway
@agilepathcorp
|
www.agile-path.com
2
3. Agenda
•
•
•
•
•
•
Who
is
AgilePath?
Why
a
Service
Registry?
Selec2on
of
a
Registry
Tool
Extending
the
WSO2
Model
WSO2
Vision
for
Governance
Registry
Q&A
@agilepathcorp
|
www.agile-path.com
3
4. AgilePath:
More
Than
10
Years
of
Innova2on
• Founded
by
Eric
Marks
in
2003,
AgilePath
brings
industry
innova2on
and
thought
leadership
to
our
clients.
• AgilePath
Corpora2on
delivers
management
and
technology
consul2ng
services
based
on
AgilePath’s
Playbook™
methodologies
for
SOA,
Cloud
Compu2ng,
Enterprise
Governance,
Legacy
PorYolio
Moderniza2on
and
Mobile-‐Social-‐Cloud
Fusion.
• AgilePath
provides
vendor-‐independent
solu2ons
and
technical
services
to
accelerate
business
results
through
superior
technology
adop2on.
@agilepathcorp
|
www.agile-path.com
4
5. AgilePath
(cont’d)
• AgilePath
provides
services
focused
on
today’s
technology
challenges:
– Next
Gen
Architecture
(Social,
Mobile,
Cloud),
Cloud
Compu2ng
– Service
Oriented
Architectures
&
Business
Process
Modeling
– Integra2on,
Legacy
Migra2on
• Established
reputa2on
with
F100/F500
and
Public
Sector
Clients
– Governance
frameworks
and
implementa2ons
– Cloud
Architecture
and
Legacy
System
Migra2on
strategies
• Cueng
edge
innova2ons
that
accelerate
2me
to
market,
reduce
business
and
IT
costs,
and
improve
efficiency
– Pioneering
governance
and
modeling
solu2ons
– AgileQuad™
Modeling
PlaYorm
(PaaS):
Expedite
Solu2on
Time
to
Market,
Agile
Development
– Governance
PaaS
for
Cloud,
SOA,
Governance
Managed
Services:
Reduce
Cost
of
Opera2ons
• Recently
joined
WSO2
Community
Partner
Program
AgilePath
delivers
strategic
insight
coupled
with
technology
implementa2on
@agilepathcorp
|
www.agile-path.com
5
6. Representa2ve
AgilePath
Clients
• US
Air
Force
•
• Marine
Corps
•
• Military
Health
•
Services
(MHS)
• NGA
•
• ODNI
•
• NSA
•
• State
of
California
• USTransComm
•
•
@agilepathcorp
|
www.agile-path.com
6
WalMart
Staples
Kaiser
Permanente
Federal
Express
Intel
Corpora2on
Mohawk
Fine
Papers
GE
Healthcare
Yale
University
7. AgilePath
Core
Prac2ces
Governance
IT,
EA,
Data,
SOA,
Cloud
Governance
Enterprise
Governance
Governance
&
Managed
Outsourcing
Compliance
&
Risk
Services
Change
Management
&
Mentoring
Dashboard
&
Metrics
Strategic Alignment
Technology
SOA,
BPM
&
IntegraDon
Cloud
CompuDng
Enterprise
&
Data
Architecture
Data
InnovaDon:
Data
Science
&
Big
Data
Legacy
Asset
MigraDon
&
ModernizaDon
Capability
DecomposiDon
Systems
Engineering
SoIware
Development
Architectures
|
www.agile-path.com
Business
&
Technology
Governance
Strategic
SoluDon
Modeling
Alignment
Staffing
Services
OrganizaDonal
Design
Technology
Gen
Fusion
&
Next
@agilepathcorp
Service
Registry
Fits
Here
7
8. Convergence
of
Technology
and
Governance
Cloud
SOA
&
Service
Registry
Social
Media
@agilepathcorp
|
www.agile-path.com
Mobile
8
9. SOA
or
Services-‐Based
Architecture
is
Crucial
• "We have learned that about 70 percent of the work
in successfully adopting a service-based
architecture lies in defining and implementing the
governance model." - internal white paper, Intel Corp.
• In our experience: one business unit won’t fund all
reusable services. The Funding Models are antiquated in
most organizations yet they are a critical component for
the success of SOA, Cloud, Mobile and Enterprise
Technology requirements.
Gartner:
“Can’t
Do
Cloud
Without
SOA”
@agilepathcorp
|
www.agile-path.com
9
10. Characteris2cs
of
a
Service
Repository
DefiniDon:
A
central
‘database’
that
includes
ar2facts
for
all
services
planned
for
development,
in
development,
in
use
and
re2red
CharacterisDcs:
•
The
registry
is
the
driver
of
a
“Catalog”
of
Services
•
Searchable
by
service
consumers
and
providers
– Service
registra2on
is
performed
by
service
owners
– SOA
COE
ensures
SLAs
are
implemented
and
agreed
upon
before
services
are
in
produc2on
and
consumers
implemented
•
It
enforces
service
design-‐2me
policies
•
Service
meta-‐data
is
updated
throughout
the
SDLC
and
includes
content
from
the
Business
Owner,
Development
Owner,
and
Opera2ons
/
Deployment
Owner
–
–
–
–
–
–
•
Interface
defini2ons
(e.g.
opera2ons,
XSD,
sample
XML
messages)
Security
mechanisms
used/employed
by
the
service
along
with
any
access
criteria
and
restric2ons
Relevant
design
documents
or
links
to
them
Business/func2onal
behavior
Development
URLs
where
appropriate
Sample
consumer
code
Registry
provides
support
for
and
iden2fica2on
of
composite
services
@agilepathcorp
|
www.agile-path.com
10
11. Actors
In
The
Service
Lifecycle
• Service
Registry
Actors
– Business
owner
-‐
manages
requirements
and
change
requests
– Service
development
owner
-‐
develops
and
maintains
the
service
– Service
opera2ons/deployment
owner
-‐
manages
the
service
when
deployed
• Lifecycle
Actors
– Business
–
manages
priori2es,
requirements,
change
requests
– SOA
Working
Group
–
enforces
standards,
governance,
facilitates
iden2fica2on
– SOA
Center
of
Excellence
–
handles
excep2ons
and
escala2ons
– Service
Provider
–
typically
source
system
owner,
leads
support
efforts
and
manages
capacity
– Service
Consumer
–
the
user
of
the
service,
can
be
a
human
or
applica2on
but
every
applica2on
must
have
human
POC
@agilepathcorp
|
www.agile-path.com
11
12. Tac2cal
Lifecycle
Processes/Rela2onships
Identify
Projects &
Programs
Business
Prioritization
Enterprise
Architecture
Process
Potential
Service
Requirement
Identified
SOA Working Group
SOA COE
Service
Candidate ID
Service
Modeling
Service
Design
Service
Development
QA / Testing
Service Consumer
Initiate New
Potential
Service
Request
Design-Time
Governance
|
www.agile-path.com
Run-Time Governance
Deploy
Management/
Monitoring
Consume /
Reuse
Service
Discovery
@agilepathcorp
Funding and
Budgeting
Service
Portfolio
Management
Service
Repository
Process
Begins
Design-Time Governance
Service Provider
Service
Qualification
12
Run-Time Governance
13. Process
for
Registry
Entry
Crea2on
/
Update
Governance
Process
Triggers, Events
New Candidate Identified
and Verified
Pre-conditions
• Service Candidate
Identified
• Agreement that
Capability is
required
Candidate
Iden2fica2on
Major Process Steps
Candidate
Capability
Iden2fied
Governance
Boards
Project
or
Service
SDLC
Discovery
SDLC
Phase
Change
Service
Design
Change
Key Policies
Enforced
Business
Sponsor
/
Capability
Domain
Owner
Create
New
Registry
Entry
Update
Registry
Entry
Throughout
SDLC
• SOA First
• Re-Use
• Complexity
Reduction
• P2P Elimination
• Data Governance
Iden2fy
and
Maintain
List
of
Consumers
Plan
for
Version
Management
and
Re2rement
Portfolio
Mgmt.
Process
Publish,
Discover,
Register
Service
Consumption
Modeling
Service
Discovery
@agilepathcorp
|
www.agile-path.com
SOA
Center
of
Excellence
Enterprise
or
Domain
Architecture
Office
Overview
Registry
Entry
CreaDon
and
Update
Process:
This
process
describes
the
process
for
crea2ng
a
new
capability
in
the
Registry
and
maintenance
of
the
content.
This
is
complimentary
to
the
SDLC,
Consumer
and
Provider
processes.
Example:
Capability
Candidate
is
iden2fied
during
Modeling
and
Decomposi2on
process.
The
Candidate
may
not
be
completed
development
for
several
months.
Input:
There
is
a
candidate
capability
iden2fied.
Summary
Steps:
A
capability
candidate
is
iden2fied
and
needs
to
be
verified
that
a
similar
capability
does
not
already
exist.
If
one
is
close,
then
the
request
should
be
for
an
enhancement
/
new
version
of
the
exis2ng
capability.
If
one
does
not
exist,
the
request
is
for
a
new
capability.
As
soon
as
the
need
for
a
new
capability
is
confirmed,
the
candidate
should
be
registered
with
minimal
data
in
the
Registry.
As
the
capability
proceeds
through
the
SDLC
process,
the
Registry
should
be
updated
with
details
as
they
are
known.
Preliminary
content
is
acceptable
as
long
as
it
is
clearly
noted.
The
progression
from
planning
to
development
to
tes2ng
and
ul2mately
Produc2on
is
indicated
through
the
SDLC
Phase
or
Status
field
in
the
Registry.
Output:
The
capability
is
created
and
maintained
in
the
Registry.
Internal reference: L07.02
13
14. Process
for
Discovery
Governance
Process
Triggers, Events
New
Capability
Approved
Process for Discovery
Pre-conditions
• Capability has been
added to or updated
in Registry
Major Process Steps
Registry
Is
Accessible
Change
in
Registry
Content
Change
in
Solu2on
Design
Key Policies
Enforced
• SOA First
• Re-Use
• Complexity
Reduction
• P2P Elimination
• Publishing
• Registration
SDLC
Phase
Gate
or
Milestone
Achieved
Capability
Iden2fied
as
“Needed”
Prospec2ve
Consumer
conducts
“Discovery”
Exact
or
Near
Match
Found
No
Match
Found
Realization,
Utilization,
Re-Use
Portfolio
Mgmt.
Process
Service
Identification
Publish
Requirement
or
Design
Change
in
Current
Project,
Trigger
Discovery
Discovery
Excep2on
&
Escala2on
process
as
needed
Governance
Boards
Self-‐Governance
Domain
Working
Group
Enterprise
or
Domain
Architecture
Office
Development
Manager,
Technical
Lead
Overview
Process
for
Discovery.
Process
for
searching
meta-‐data
in
the
registry
to
uncover
a
capability.
NOTE:
This
can
be
done
through
a
registry
tool
by
no2fying
previously
registered
consumers,
those
consumers
who
have
contracts
to
consume
it
and
through
other
internal
organiza2on
mechanisms
(ex.
development
mee2ngs,
wikis,
etc.).
Input:
There
is
a
new
capability
iden2fied
OR
a
change
to
an
exis2ng
capability
entry
in
the
registry.
There
are
known
consumers
iden2fied
in
the
registry
(either
actual
or
poten2al).
Excep2on:
Consumer
required
to
consume
new
version
of
exis2ng
capability.
Summary
Steps:
Search
is
by
keyword
or
other
registry
schema
element
in
order
to
obtain
a
list
of
poten2al
capabili2es
that
will
meet
the
need.
Person
conduc2ng
the
search
compares
the
return
list
with
the
required
func2onality
to
determine
if
there
is
an
exact,
near,
or
no
match.
When
an
exact
match
is
found,
follow
L7.5;
if
a
near
match
is
found,
follow
L7.5
and
nego2ate
with
the
provider
to
execute
L8.2;
if
no
match
is
found,
work
with
the
Architecture
Team
to
iden2fy
a
provider
who
can
then
follow
L7.2
and
add
the
capability
to
the
registry
Output:
Updated
list
of
consumers;
new
capability
added
to
Registry.
Internal reference: L07.04
@agilepathcorp
|
www.agile-path.com
14
15. Registry
Process
Aligns
with
SDLC
Process
Service Portfolio Management
Catalog
Ac2ons
SDLC
Provider
Ac2vi2es
• Update Catalog Content
• Perform Service
o Preliminary Architecture
Discovery
o Preliminary Payload
• Create Registry
Schema
Entry
o Define SLA Content
o Name
• Status = In Development
o Description
• Register Consumers
o Owner
o Domain
• Start Service Mgmt
• Register
Consumers
Concept
• Perform
Architecture
Assessment
• “Business”
Justification
• Perform Existing
Service Analysis
• Begin Formal
Development
• Update Catalog Content
o Final Architecture
o Final Payload Schema
o Final Service
Operations
o Final SLA details
• Status = In Development
• Status = In Test
• Register Consumers
• Update Catalog
• Confirm and
validate all Catalog
Artifacts are final
versions.
• Status = In
Production
• Register
Consumers
Develop
Launch
DefiniDon
/
Planning
• Define Service Architecture • Technical Design
& Technical Requirements • Build Service
• Define Functional Service • Perform QA Testing,
Description
including System and
• Complete Funding Request Integration Testing
• Perform Service Modeling
and Design
• Implement Versioning
• Confirm Service
Qualification
• Perform Release
Management
• Consumer
Management
• Issue Resolution
• Change
Management
• SLA Management
• Version /
Retirement
Planning
• Metrics Reporting
• Status
o In Production
o Retired
o Deprecated
• Register
Consumers
Support
• Perform
Operational & SLA
Monitoring
• Performance
Monitoring
• Security Monitoring
• Capacity
Management
Internal reference: L07.02
@agilepathcorp
|
www.agile-path.com
15
16. Example:
US
Air
Force
Program
Service
Registry
• AgilePath
is
engaged
in
a
moderniza2on
program
for
a
global
US
Air
Force
enterprise
system
• Our
responsibility
is
implemen2ng
SOA
Governance
for
the
System
Integrator,
suppor2ng
3rd
Party
solu2on
development
and
tes2ng
• AgilePath
is
responsible
for
enforcement
of
service
lifecycle
governance
across
development
and
tes2ng
environments
• AgilePath
is
also
filling
the
role
of
Service
Registry
training
and
Tier
1
end
user
support
for
customer
requirements
@agilepathcorp
|
www.agile-path.com
16
17. Program
Service
Registry
Requirements
ü Import
of
XLS
style
data
ü Define,
Import
and
Export
AF
specific
service
meta-‐data
ü Ability
to
filter
services
by
site
or
by
source
system
ü Access
based
on
role
ü On-‐site
implementa2on
but
accessible
by
3rd
par2es
ü Service
Lifecycle
Management
ü No
“heavy”
vendor
overhead
or
vendor
lock-‐in
ü Design-‐2me
unlinked
from
run-‐2me
ü No
‘linking’
across
environments
or
to
external
vendor
sites
ü Flexibility
for
customiza2on
@agilepathcorp
|
www.agile-path.com
17
18. Managed
Service
Documenta2on
Workflow
Architects
Testers
Us
e
&
ate
Up
d
d
Up
Use
&
Update
at
e
Developers
e
&
Us
Identify
Services
&
Functions
Service
&
Function
Trackers
Use
&
Update
Populates
Support
XLS-based
Service
Registry
Li
e
vic
er
Site
Specific
Services
ll
S
st
ll
S
st
Fu
Fu
i
e
L
vic
er
Service
Catalog
EVTS
Export
Site
X
Legend:
UDDI
Registries
Security
Domain
“A”
@agilepathcorp
Security
Button
Domain
“B”
|
Security
Domain
“C”
Security
Domain
“D”
www.agile-path.com
Summary
Steps:
1. A
service
candidate
is
iden2fied
and
the
user
queries
the
Service
Registry…
a) If
a
service
is
found
that
meets
the
requirements,
request
consumer
registra2on;
b) If
there
is
a
similar
but
not
sufficient
service,
request
an
enhancement
/
new
version
of
the
exis2ng
service;
c) If
one
does
not
exist,
request
a
new
service.
2. For
a
new
service,
the
candidate
service
is
registered
with
minimal
data
in
the
Service
Registry.
3. As
the
service
is
matured
and
proceeds
through
the
SDLC
process,
the
Registry
is
updated
with
details
as
they
become
available.
Preliminary
content
is
acceptable
as
long
as
it
is
clearly
noted.
The
service
progression
from
planning
to
development
to
tes2ng
and
ul2mately
Produc2on
is
indicated
through
a
Service
Status
field
and
Service
Lifecycle
state
in
the
Service
Registry.
18
19. Vendor
Assessment
Process
• We
used
our
standard
Vendor
Assessment
Process
to
evaluate
poten2al
Registry
Products
• Tested
and
evaluated
8
vendor
products,
scoring
each
with
a
1-‐5
ra2ng
across
6
categories
comprising
29
different
criteria.
• Category
and
criteria
items
were
provided
by
AgilePath
and
individual
weigh2ng
of
items
was
determined
by
analyzing
customer
criteria
and
requirements.
@agilepathcorp
|
www.agile-path.com
19
20. Customer
Requirements
Mapped
To
AP
Scoring
Customer
DescripDon
/
Requirement
Maps
to
AP
Criteria
Category
Web-‐based
user
interface
easily
accessible
through
On-‐site
/
Installed
Applica2on
or
Cloud
Install
Portal
or
intranet.
Hosted
Easy
to
populate
and
usable
to
the
end
consumer
Import
/
Export
to
XLS
User
Advanced
search
capability
(non-‐linear
queries,
Robust
Keyword
Search
/
Discovery
User
more
than
just
search
on
columns).
Across
all
meta-‐data
fields
There
are
frequent
requests
for
a
Service
Catalog
Customizable
Service
Provider
Must
Have
Feature
related
to
a
specific
build.
Where
is
the
SC
for
Build
workflow
1?
Build
2?
Each
build
is
a
source
of
services
informa2on.
Service
Lifecycle
Management
Must
Have
Feature
Ability
to
add,
change,
edits
and
customize
service
Support
for
customizable
meta-‐data
Content
metadata.
fields
and
tags
Simultaneous
edi2ng
capability
with
row-‐level
Full
audit
log
to
track
changes
Security
locking.
Design-‐2me/Run-‐2me
Synchroniza2on
Run-‐2me
and
Design-‐2me
Instances
Install
Support
for
data
import/export
func2onality
and
Import
/
Export
to
XLS
User
possibly,
ability
to
interface
with
CMDB.
Ability
to
track
service
pedigree.
Version
Differen2a2on
Must
Have
Feature
Service
Consumer
registra2on
and
maintenance
of
Consumer
Registra2on
and
Status
Must
Have
Feature
consumer
auributes
with
high
data
integrity.
Service
usage
count
in
number
of
consumers.
Consumer
Registra2on
and
Status
Must
Have
Feature
Service
Depreca2on
Status
-‐
Which
services
are
Version
Differen2a2on
Must
Have
Feature
planned
to
be
deprecated
in
the
next
6
months?
This
would
enable
planning
for
service
replacement.
@agilepathcorp
|
www.agile-path.com
20
21. Standardized
Scoring
Values
0
1
2
3
4
5
•
•
•
•
•
•
DefiniDon
Not
evaluated
Does
not
meet
requirement
Par2ally
meets
the
requirements
Sufficiently
meets
the
requirement
Meets
requirement
and
has
few
addi2onal
capabili2es
Significantly
exceeds
requirement
in
this
area
Each criteria is “scored” using standard point values
Individual criteria values are ‘rolled up’ to determine the category score
Category scores are ‘rolled up’ to determine a weighted score
Raw point totals, unweighted, are accumulated for reference
Results automatically adjust. We re-do evaluations for new vendor releases
The same AgilePath resource evaluated all products within a specific
category to eliminate bias and personal preferences
@agilepathcorp
|
www.agile-path.com
21
22. Vendors
Scored
Across
Mul2ple
“Categories”
Major
Category
Content
Weight
DefiniDon
15%
Is
there
flexibility
in
underlying
content,
predefined
values?
Install
10%
Requirements
that
are
important
to
understand
the
technical
requirements
User
20%
User
experience
requirements
to
ensure
it
meets
the
customer
need
Security
Lifecycle
Miscellaneous
20%
25%
10%
Fundamental
site
and
access
security
requirements
Requirements
focused
on
lifecycles
or
processes
Features
that
would
enhance
the
customer
implementa2on
• Weights are tuned based on client requirements
• Within each category, we also give a client-specific weight to each criteria
• At each level, the individual weights add up to 100%
@agilepathcorp
|
www.agile-path.com
22
23. Categories
Break
Down
into
Mul2ple
Criteria
Content
Support
for
customizable
meta-‐data
fields
and
tags
Support
for
Links
across
internal
network
Support
for
Links
to
external
/
public
websites
Support
for
Composite
Services
and
Linking
to
Component
Services
Viewpoint:
Is
there
flexibility
in
underlying
content,
Weight
predefined
values?
45%
Ability
for
client
to
define
meta-‐data
fields
for
quick
reference
content
20%
Ability
for
client
to
link
content
within
company
network
(ex.
Link
to
XML
Schema
in
source
code
repository)
20%
Ability
to
link
to
external
website
for
content
(ex.
WS-‐
Security
standards)
15%
Easily
iden2fied
composite
services
and
ability
to
trace
back
to
component
services
for
related
content
Viewpoint:
these
requirements
ensure
the
product
User
Weight
meets
the
basic
customer
need
Import
/
Export
to
XLS
20%
Can
the
applica2on
import
or
export
data
to
/
from
the
repository
for
easy
popula2on,
backup,
migra2on
capability?
Is
it
a
selec2ve
export?
Robust
Keyword
Search
/
Discovery
25%
Does
the
applica2on
support
key
word
search
across
Across
all
MetaData
fields
custom
meta-‐data
fields?
Simple
Keyword
Search
/
Discovery
15%
Does
the
search
feature
search
free
form
descrip2ve
across
descrip2on
field
text?
Ability
to
iden2fy
service
20%
Does
the
applica2on
show
which
services
are
consuming
dependencies
other
services,
which
consumers
are
using
which
services?
Bonus:
Does
it
build
a
"mind-‐map"
style
diagram
of
the
environment?
Version
Differen2a2on
20%
Does
the
applica2on
support
one
or
mul2ple
versions
of
services?
Does
it
facilitate
version
transla2on
for
request/response
messages?
Are
re2red
service
versions
accessible
via
search,
view
for
reference?
@agilepathcorp
|
www.agile-path.com
23
24. Vendor
Assessments
Presented
to
Client
Weighted
Average
Scoring
Average
Total
Points
WSO2
Governance
Registry
3.29
3.24
94
SoywareAG
CentraSite
3.35
3.17
92
IBM
WSRR
3.09
3.07
89
HP
Sys2net
2.91
2.90
84
SOA
Soyware
Repository
Manager
2.83
2.79
81
Oracle
Service
Registry
2.75
2.72
79
Jboss
Enterprise
SOA
PlaYorm
2.55
2.59
75
Mule
Galaxy
2.52
2.55
74
Vendor
/
Product
Name
• Three scores generated for each vendor: weighted average, straight
average and total points
• Conducted a virtual “bake off” with top two vendors
• Bake-off: WebEx style demo of 2 use cases created by the customer and
provided to the vendor.
• Vendor conducted the walk-through of their tool directly with the customer.
• Prior assessment activities were driven by AP to identify top two vendors.
• All results were reviewed with the client prior to selection to ensure
transparency and that scoring was done to their specifications.
• Client selected WSO2 Governance Registry Product
@agilepathcorp
|
www.agile-path.com
24
25. Extending
the
WSO2
Data
Model
• To
support
the
requirements,
we
extended
the
core
Governance
Registry
Database:
– Modeled
Air
Force
/
DoD
specific
meta-‐data
• Ex.
custom
risk
exposure
fields,
mul2ple
levels
of
system
iden2fica2on
(type
of
system,
sub-‐system,
etc.),
related
customer
use
case
(ex.
Targe2ng)
– Custom
tables
have
primary
key
/
foreign
key
rela2onships
that
we
needed
to
enforce
• We
will
be
building
a
custom
extract
for
Risk
Exposure
for
services
connec2ng
across
firewalls
@agilepathcorp
|
www.agile-path.com
25
26. Extended
Data
Concepts
• Requirement to support custom fields
• This outline helped ‘demonstrate’
those fields and their relationships
• Within each Asset Type, there are 1+
related fields and tables
@agilepathcorp
|
www.agile-path.com
26
27. Data
Concepts
Translated
to
Rela2onal
Tables
Asset
Type
Providing
Component
Providing
Component
Providing
Component
Asset
Type
Providing
Component
Asset
Type
Providing
Component
Providing
Component
Providing
Component
Asset
Type
Providing
Component
Providing
Component
Providing
Component
Table
Overview
Overview
Overview
Table
Taxonomy
Table
Technical
Technical
Technical
Table
Miscellaneous
Miscellaneous
Miscellaneous
Element
Name
Version
DescripDon
Element
Keywords
Element
Constraints
Language
Pla]orm
Element
Usage
Fee
ExpiraDon
Date
ReDrement/Decommission
Date
Type
Text
Field
Numeric
Text
Field
Text
Field
Type
Editable
List
Type
Text
Field
Drop-‐down
Box
MulDple
SelecDon
List
Type
Numeric
Text
Field
Date
Field
Date
Field
• Relational Tables were designed to maintain the affinity and cardinality of
values to the underlying services
@agilepathcorp
|
www.agile-path.com
27
28. Client
Requested
Custom
Report
Required
• Custom
Field
iden2fies
requirement
for
extract
(if
value
=
Y,
then
include
in
report)
• Extract
includes
custom
fields
as
well
as
core
WSO2
fields
• Output
will
be
CSV
and
then
input
into
PPT
• Report
currently
planned
for
manual
genera2on
monthly
but
may
explore
automa2on
in
the
future
• Challenge:
Access
to
Business
&
Technical
Resources
that
are
not
co-‐located
is
slowing
requirements
gathering
and
solu2on
design
@agilepathcorp
|
www.agile-path.com
28
29. Keys
to
our
successful
implementa2on
• Government
customer
was
comfortable
with
Open
Source
solu2on
• WSO2
resources
were
helpful
during
sales
cycle
and
with
implementa2on
ques2ons
• Combined
service-‐based
solu2on
knowledge
of
System
Integrator
and
AgilePath
was
cri2cal
in
driving
solu2on
analysis
and
design
@agilepathcorp
|
www.agile-path.com
29
30. Governance
Support
Through
Technology
• Governance
processes
can
be
built
directly
within
the
WSO2
product
for
enforcement
• Consumer
and
Providers
benefit
from
a
central
Service
Registry
• User
educa2on
about
Registry
is
s2ll
required
• SLA
tracking
and
enforcement
can
be
conducted
within
the
WSO2
tool
@agilepathcorp
|
www.agile-path.com
30
31. Summary
• A
robust,
user
friendly
Service
Registry
is
required
for
the
success
of
SOA
and
Cloud
solu2ons
• WSO2
Product
met
the
needs
given
its
flexibility,
extendibility
and
licensing
approach
@agilepathcorp
|
www.agile-path.com
31
38. Ques2ons
• Contact
AgilePath
to
help
develop
your
Registry
Implementa9on
Strategy
and
SOA
Solu9on
Design
– 978.462.5737
Office
/
Info@agile-‐path.com
• Contact
WSO2
to
learn
more
about
the
Governance
Registry
Tool
and
other
Open
Source
Components
– hOp://wso2.com/contact/
@agilepathcorp
|
www.agile-path.com
38