Congratulations, you have a project to migrate a large legacy software system to the cloud. Also it needs some updates and the clients have a whole list of feature requests. Are you experiencing feelings of dread or exciting visions of the possibilities? The good news is that it can and should be the latter. The Open API ecosystem makes it easier than ever to take on a project like this and be successful. In this talk Seth will introduce his team’s ongoing migration project as a case study. He will discuss the primary benefits of open APIs as part of the migration and how they contribute to velocity, visibility, team focus, and feature development. He will examine strategies for identifying APIs, validating APIs, and integrating APIs into a legacy migration project. He will then discuss the layers of a legacy application that APIs can be used to address (hint: more than you may think).

2. Lifting Legacy to the Cloud
on API Boosters
Seth Lachner, Avantas

3. A journey out of the datacenter
All Images Nasa.gov unless noted

4. Avantas – Smart Square®
We leverage technology and
evidence-based solutions to help
healthcare providers better manage
their workforce.

5. Stuck in the
Datacenter
• Old Codebase
• Outdated tech
• Outdated architecture
• Add-hardware Fixes
• Overly-complicated
logic
• Spaghetti Code
• etc
Image from TechRepublic: http://www.techrepublic.com/pictures/real-world-server-room-nightmares/12/

6. Destination:
Cloud
Modernization,
here we come!

7. Goal 1: Move It

8. Avantas always managed its own software...

9. The Cloud is Services
•It’s not just “Someone else’s computer”
•Services and Frameworks
•Services provide features at scale
•Composability
•Frameworks provide access to the services
•APIs are the ideal framework
Teepublic.com

10. Leaving Behind
•Dedicated Hardware
•VPNs
•Firewalls
•DB Servers
•Backup Systems

11. Leaving Behind
•Dedicated
Infrastructure
•VOIP
•Email
•Networking

12. Monolithic Software
DB
UI
BL
P

13. Service Based System
Smart
Square
Core
ServiceService
Service Service
APIs
Partner API

14. Goal 2: Extend It

15. API First
“API-first development is a strategy in which the
first order of business is to develop an API that
puts your target developer’s interests first and
then build the product on top of it (be it a website,
mobile application, or a SaaS software).”
-Guy Levin, https://dzone.com/articles/an-api-first-development-approach-1

16. API Next What
Preparing for a Service Level API Offering
•The “real” reason for moving to the cloud
•Long term thinking
•Informs every decision
•Priority factor
•Finding the services
•Internal
•External

17. API Next How
•Analysis
•In-depth process level
•Point-in-time component level
•Business focused
•Documentation

18. API Next How
•Service Boundaries/Interfaces
•Analysis driven
•Identifies non-core features
•Identifies atrophied modules
•Exposes core components
•Features we want to expose
•Core competencies

19. API Next Why
Strategy for the foreseeable future
•We must focus on core features
•We must modernize our architecture
•We must provide an Open API interface
•Clients need it
•Partners will require it

20. We made it!

21. Let’s Get Going
• Platform
Equivalency
• Load
Partitioning
• What Services
will we need?

22. The Power of APIs (Velocity + Agility)
•Rapid iteration
•Build->Test->Teardown
•Rapid proliferation
•Scale it up
•Rapid exploration
•Get around the roadblocks

23. That Missing Thing
Wait,
telephony?

24. Visibility
•Service providers are experts
•Expert level insights
•Nuanced implementation
•API Structure informs
•Guides the developer
•Educates the developer

25. Team Focus
Platform Migration
+
Product Enhancements
+
Maintenance
–
Limited resources
=
Tough choices and Requires
FOCUS

26. Team Focus
•Open APIs let the team
focus on core solutions
•We embrace the
expertise in the service
for ancillary features
•We focus on our platform

27. I Wish I Knew More About Our Email
ServiceToPlatform

28. Features
•APIs give us access to
expert features
•Features we shouldn’t try
to build
•We build upon the strength of the commons

29. SMS Could Be Better…
Copyright Melina Sampaio Manfrinatti
https://www.flickr.com/photos/melinamanfrinatti/8391988575
https://creativecommons.org/licenses/by-sa/2.0/

30. Sold on Open APIs
•Easy to compare
•Easy to try
•Can be combined, changed, or used in tandem
•Integration is rapid
•Patterns are repeatable/reusable
•Interface is (variably) standardized

31. Our (Evolving) API Strategy
● Discovery
● Analysis
● Architecture
● Resolution?

32. Discovery (finding an external service)
•Kin built a thing:
•http://discovery.apievangelist.com/
•Marketplaces, Repos, search engines, directories
•Talk to vendors
•Talk to your community
•Set a deadline
•Compile your final list

33. Discovery (pruning)
•Filter 1: Matrix
•Requirements against features
•Use vendor docs, OAI specs, or SDK
•Filter 2: Docs
•Completeness
•Accessibility

34. Analysis
•Confidence level
•Team experience?
•Community experience?
•Build something
•Simple and standalone
•Focused on requirements
•Vendor sandbox?

35. Analysis
•API-based development
•Time-to-build
•Road-blocks
•Time-to-solution
•Performance
•Transaction speed
•SLA
•Error rate

36. Analysis
•Does the implementation pattern work for us?
•Are there any code smells?
•Are any requirements unmet?
•Will this work with budget?
•Does this vendor stay on the list?

37. Architecture
•Pick the top of the list and start
•Test through the integration
•Engage beta ready clients
•Early feedback closes the loop
•Trust your users

38. Resolution?
•Best case: Done
•Celebrate
•Archive the analysis
•Worst case: Incomplete or worse
•Post-mortem
•Review need
•Try Again?
•Leave legacy for now

39. Layers for API Consideration
•Telephony
•SMS
•E-mail
•Extract, Transform, Load (ETL)
•Networking (DNS, FW, router, etc.)
•API Management
•Content Delivery (CDN)
•System Replication (Tincup)

40. Questions?
Thank You