###### tags: `WebHack#41`

# App Modernization

## Lightning Talk 1: Apply App Modernization swiftly: an introduction to swift method by Guixin

by Guixin Zhu: Senior Solution Architect @ VMware Pivotal Labs

1. Why we need to modernizing apps
1. Sometimes modernization is for like make the system stronger to resist disasters, or get recovered from that
1. Like, to have a system can easily recover from disasters, no need costly checking for like data inconsistency
2. Legacy system in the past may not be designed to have such capacity
2. Modernizing apps need method: SWIFT is one of them. Some points:
1. Balanced team: Different roles from business to developer members in one team
1. So. it is not like some tranditional company organize teams by only one role. Balanced team asks to have different roles in one team
2. Shared understanding via event storming
1. Inside, outside doman events and external system are categoried on a board, by timeline
2. These events are organized "like" sequence diagram, but with different purposes
3. 2-4 days to make the event storming
4. Check capabilities to support all these events
1.Grouping event stickers by system/service to provide the capability to support some events
5. Anaylize interactions between service candidates and external systems, by adding edges to event tickets and systems/services
1. Mark "sync", "async" or "other" on edges
2. Add some descriptions in between two ends of one edge (and split the flow if necessary)
7. Organize tickets by different roles in the system, like by "risk, API, pub, sub" and so on
8. The final board will be a large diagram with lots of flow, events, groups, and as a real architecture map of the whole system
1. It is constructred gradully by this SWIFT method. So no need to make all things done by one architecture at once
2. And it is possible to split, and discuss again to clarify the system even after the diagram is made
3. "Milo" as the e-whiteboard to make such board

3. Developing after these sharing and discussion

### Q&A

#### Q1

"For legacy system, how this process helps to handle unexpected issues and unknown parts popped up during actual coding, refactoring and migrating?
"

#### A1

1. Need someone with deep knowledge about the system
2. That's the purpose of event storming
3. Release all at once will lead to disaster
4. SWIFT method allows to release one piece of the sytem at one time
5. Do what business need, not what a system "should have"
6. Unknown parts pops up: go back to the event storming stage, and maintain these things as living docs

#### Q2

"Could you please give some brief ideas about how long would each activity in the Swift method normally take?"

#### A2

1. 3-4 days for event storming; 2-3days for boris; then 1-2days
2. Maybe there will be some issues the team need to go back event storming to do some adjustments again
3. Quality of the event storming: depends on the persons know the system

## Lightning Talk 2: How to build a right team for your app modernization? by Saho

by Saho Hamahira: Senior Product Manager @ VMware Pivotal Labs

1. For the situation: what if the team went not well
2. Modernize not just apps, but also processes and teams
3. Identify how bad teams look like
1. Blaming, igoring others, and with issues like low deliverance
2. Chernobyl is a good example: people with knowledge, and as experts, with confidence, played the major role lead to the disaster
3. Team modernaization + application modernaization
1. Legacy issues from team went not well
2. Without modernaztion the team, modernazing app won't give any benefit
3. Feeling safe to discuss is necessary: this allows people give more feedback, and their ideas
1. So accumulating such knowledge can help the team to handle the similar issue next time
5. Knowledge sharing is necessary: team members join and leave at anytime, so there will be a cost of losing the knowledge of systems
1. Pair work is a way to prevent such issues
2. As a natural method to allow people sharing knowledge during working and solving problems together
6. Balanced team means the decision is made together by the *whole team*, not any single person
1. So this prevent "frustrated dictator" in a team
7. Project manager -> product manager: agile, not waterfall
1. Continuous improvement. Never end (so no waterfall mindset)
2. Just a feedback cycle. Not about Scrum, Kanban or any other method
8. Tech = solving real problems
1. (in a company) trade off > using tech because it is cool and new
2. Product is built and used to solve problems

### Q&A

#### Q1.

"How to balance the new tech adaption vs. using old tech to solve daily problems ?"

#### A1.

1. If it is possible and all the knowledge are well-known, this means risks can be isolated, so can do migration to new tech

2. Microservice become mainstream is (partly) to solve the problem here as monolithic service usual has. Plus SWITF method can be more helpful (help to identify an split the service via the board)