SNAP is a technique we employ extensively in Pivotal App Transformation to triage an application and determine technical feasibility. SNAP can be done for an individual application as well as for a bucket of applications that groups like apps. We typically grade each answer along S, M, L, XL t-shirt sizes and determine an overall technical feasibility of the application aka its cloud readiness score.
SNAP Analysis of Apps :½ hour per app:
Questions to ask:
0. Versions and APIs in-use of Java, JavaEE, J2EE & Spring Framework
1. External Integrations - Databases, Caching, Messaging Queues
4. In-house frameworks
5. Logging
6. Configuration
7. SLAs
8. Packaging and Build (ear/war/jar)
9. CI/CD in place ?
10. Use of Distributed 2PC XA Transactions
11. Persistent File System Access like NFS or SMB/CIFS... ?
12. People location
13. non-HTTP inbound networking protocols like RMI-IIOP, etc ..
14. Total LOC
15. App Server ? and appserver specific code
15. Security Requirements (Siteminder, Ping, SSO)
16. Batch/ETL
17. Front-end tech
18. Runs on PCF
19. Statefulness - session state
20. Data Access - JDBC, ORM, JMS
21. Startup/shudown times
22. 3rd party frameworks/libraries- 32/64 bit References - bit.ly/app-replat & bit.ly/migrate-jee
Typical Outcomes of a SNAP include: (0. Characteristics, 1. User Stories, 2. Metrics, 3. Risks, 4. Score aka Summary))
Outcome for each app is a list of stories to get the app to the degree of cloud nativeness desired by customer. Each App maps to multiple MVPs. The first MVP is always getting the app running on PCF. Thereafter there can be multiple MVPs gradually moving the app on the modernization scale. The scorecard of each app is used to map all the apps on a quadrant of Business Value/ Technical Risk. Apps of low tech. Risk and high business value are chosen first
