For over 30 years, JDA has been the leading provider of end-to-end, integrated retail and supply chain planning and execution solutions. Their Open Source Center of Excellence (OSCOE) Is charged with standardizing implementation of open source software used within the JDA software ecosystem. JDA experts will share lessons learned and benefits reaped by building Open Source Center of Excellence.

1. Building an Open Source
Center of Excellence
John Vrankovich
Principal Architect, JDA Software

2. • Leading Supply Chain Solution Provider ($1 Billion+ Annual Revenue)
• Optimization and Execution of the End-to-End Supply Chain
JDA Software Group

3. Some of Our Customers

4. John Vrankovich, Principal Architect, Office of the CTO
• Working at JDA since 1998
• Director and Architect, JDA Platform (1998-2015)
• Technology Review Committee Lead
• Technology due diligence for Partnerships, Mergers and Acquisitions
• Current Focus
• Architecture Strategy and Standards Across our Portfolio
• Technology Strategy (SaaS, API Strategy, IAM, ALM)
• Security Processes and Application Security Architecture
• Open Source Compliance
• john.vrankovich@jda.com / john.vrankovich@gmail.com
About me…

5. JDA Acquisitions

6. Development Metrics
100+
Applications
6+
Major
Acquisitions
10M+
LOC
50+
Repositories
100s
Releases/Year
100+
Microservices/
Repositories
30
Years in
Business
2,000
+
Open Source
Components
*

7. Open Source Process Timeline
2000 2005 2010 2015 20182017
FOSS Education
Honor System
JDA acquires
Manugistics
(1st
M&A experience)
I2
Acquisition
RedPrairie
Merger
Black Duck
Code Center,
Protex
Black Duck
HUB
Technology Review
Committee
(Architecture, Commercials,
OS Licenses)
Full
Migration to
HUB
Very Little, “Versionless”, Spreadsheets, Honor System
Tracking
Black Duck Tools

8. • Tracking
• Spreadsheets, Honor System, Architecture tool review and approvals
• Education
• Basic guidance on permissive vs viral licenses
• Challenges
• Tracking ”System” / Spreadsheets highly inaccurate, not validated or
updated
• Many teams were not staying up-to-date
• No awareness of security issues in open source software
• Lack of awareness of open source license complexities
• Not as well prepared for M&A activity
Open Source Process before Black Duck

9. • Frequently asked for or of:
• BOM of all Commercial and Open Source components
• Results of a Code Scan
• Independent Code Scan and Analysis
• Acquiring company typically will use open source compliance
to drive down the acquisition price
• Very beneficial to be prepared
Mergers and Acquisition Experiences

10. Center of
Mediocracy
(CoM)
Center of
Excellence
(CoE)

11. Enter
Black Duck
2015

12. Black Duck Code Center Adoption
• Automate our TRC Review Process
• Architectural Review
• Security Review
• Commercial Review
• Executive Review
• Across all JDA Products
• Products primed in system
• Delegate entry to teams
• Globally approved components
• Release Gateways
• BOM Validation, Security,
License

13. • POC on core JDA Platform codebase
• Tactical scanning majority of codebases
• Major concern was code snippets and modified open source
• Found very few
• Prior investment in education of development staff paid off!
• Good build process standards insured 3rd party components
always isolated from our source code
• Remediation plans developed and tracked
• Found Protex too labor intensive to implement / automate
A Brief Foray Into Black Duck Protex (2015)

14. • Wrote a broad Open Source Compliance Strategy
• Identified all requirements and their priorities
• Identify our Open Source Goals
• Ensure no major Open Source license or security issues are
released
• Ensure all issues needing remediation are tracked
• Be prepared for M&A activities
• Know what we use, their licenses and remediate open issues
• Ensure all license obligations are met
• Only allow approved tools to be used in our products
Now That We Are Better Education (by using BD
Tools)

15. • Convincing Leadership – Fear Mongering (oops, I meant education)!
• Examples of M&A experiences work well with Executive Leadership
• Cautionary tales help
• Cisco/Linksys/Broadcom – open source license compliance
• Heartbleed security vulnerability - OpenSSL
• Equifax Breach – Apache Struts
• Examples in our past and their potential ramifications
• Modified viral licensed open source, modified open source without code distributed
• Use of copyrighted or licensed book source and snippets
• Use of source code that requires a commercial license
• Metrics
• #components, % components with issues, active remediations, what we know and don’t
know..
• Present a plan with resource requirements
The Need for More Investment in Compliance – building a
CoE

16. Identify Roles and Activities (justifying needs)
Compliance Lead
•Policy Development
•Process Designer
•BlackDuck Tools
•Legal complexities of using open
source
•Ability to make and manage
remediation decisions
•Attribution requirements
•Obligations tracking and processes
•Manage integration of open source
compliance into JDA Tools
•Monitoring of overall process
•Continuous process improvements
•Liaison to JDA Legal
Other Tasks
•Standards development and Education
•Architecture Review
•Security review, remediation recommendations
•License Review
•Process Implementer (Rules, Workflow)
•Scanner, for tactical scans
•Build/CI Pipeline Integrator
•Obligations Compliance
•Metrics and Report development
•Remediation decision making, tracking,
publishing/dashboards
•Implement workflow strategy for overall JDA
Open Source processes

17. • Compliance Leadership
• John Vrankovich – Policy and TRC Lead
• Meghan Caudill – Commercial and Open Source Process Management /
Oversight
• Legal (3)
• Release Management (3)
• Security (2)
• Development Operations (3 - not enough!)
• BlackDuck Implementation and Maintenance
• Integration and Process Implementation
• Commercial and OS Metrics Development
Growing a Team: Cross Functional Team – most part time

18. • Education and Awareness
• Simple, concise process documentation
• License Categorization (Permissive, Viral, etc.), Top license of each kind.
• Explain risks with examples (fear mongering again)
• Licensing, Security, External and Internal Examples (current issues)
• License obligations and conflicts
• Processes
• Open Source Compliance Policy and Process Documentation
• Attribution Documentation Standards
• Technology Review Process
• Release Management Process (Gateways)
• Fostering Communication
• Enterprise Social Collaboration (avoiding email)
Product Development Education

19. Enter
Black Duck HUB
2017

20. • A New World
• SaaS Delivery
• PaaS Usage / Google Cloud Platform
• Microservices (50+), Separate Repositories, Duplication of components
• Continuous Delivery
• Polyglot Programming
• Containerization
• Challenges
• Need to also publish attribution and meet license obligations in ‘real-time’
• Volume of open source components (Javascript, Node, hundreds/repository)
• Partitioning distributed (Javascript, etc.) code from ‘behind the Cloud’ artifacts
JDA Next Open Source Challenges

21. • Timing of the release of Black Duck HUB could not
have been more perfect
• Protex too labor intensive to implement / automate
• Perfect tool for our JDA Next – Next Generation SaaS
Solution challenges
• Exception based issue management!
• Any other way would have been impossible
Black Duck HUB

22. Compliance Process with Black Duck HUB
Architecture and
Commercial
Approvals
Artifactory
Integration

23. Consolidating our
Processes
2017

24. Consolidation of Compliance Tracking, Metrics and Remediation
Combining OS License and Overall Security Compliance
HUB
Code Center
Static Source
Scanning
Dynamic Scanning
PEN Tests Results
(internal,
customers)
Customer Issues
Self Reporting
• Metrics
• Remediation Workflows

25. • Code Center  HUB Migration (2018)
• All ‘Classic’ products migrated to HUB. No Code Center use after 2018
• Gaps
• Workflow: Implementing some Code Center Processes
• Architectural and Commercial Review and Approval Process
• Cross Product Metrics
• Black Duck HUB 4.0 Hosting (IT and Legal Challenges)
• Continue On-premises?, Google Cloud Platform – Google Cloud Launcher
(POC)?
• Improved education and yearly certification of development staff
• Attribution Standardization
• Artfactory Integration, Whitelist/Globally Approved Components
What’s Next

26. • Don’t enable Bad Data (Code Center)
• Once it’s in the system it takes a LONG time to clean-up (7,000+
components)
• Review and Validate Critical Fields -- License and Usage Fields
• Manage by Exception
• BD Code Center – only require approvals for exception cases.
• BD HUB – designed in from the start!
• Narrow down what needs Architecture Review
• How much global oversight should there be?
• How much and what can be delegated to lead architects
• Don’t let Security Compliance be Overlooked
Lessons Learned

27. 1. Educate your teams as soon as possible
2. Understand the current status of all your open source usage
• License Compliance, Security Risk
• Develop Metrics for corporate education and future tracking
1. Develop an open source policy and goals
• Working with Legal team to get their guidance and approval
1. Use data to get leadership buy-in and investment
2. Automate everything
3. Use release gateway checks to validate compliance
4. Implement a common tracking and remediation process
Summary / Guidance

28. Q&A