TANGENT: Raffi Krikorian’s "Rearchitecting On the Fly"

As part of the first O’Reilly Software Architecture conference, Raffi Krikorian (LinkedIn, Twitter), currently at Uber, formerly VP of Twitter Engineering, talked about strategies and tactics of undertaking a change in architecture with an application is production.  As our team at Altisource Labs contemplates major changes to the architecture, this slideshare really helped to put into perspective some of the major pitfalls that a team will hit, some inside the code, but a lot outside the code, too- meaning, politics, feature creep, and tension+frustration.



Overall, the twelve points to consider are:

1. Hold the line [against the business]
2. Define “done”
3. Incrementalism
4. Find the starting line
5. Don’t ignore the data
6. Manage tech debt better
7. Stay away from vanity stuff [such as ‘hot’ new technical stacks]
8. Prepare for mounting tensions
9. Know the business
10. Get ready for politics
11. Keep an eye on code quality
12. Get the team ready

To summarize:

Hold the Line- the product managers are going to become anxious that you are taking too long to deliver the grand vision you sold them.  You will have to manage their anxiety and frustration as the process moves along.

Define "done"- It is important for all sides to agree on what the goal is and when all the re-architecture work is completed.  Sometimes, 100% parity with the existing system is not only impossible, it is fruitless.  Many workarounds are added to a system in order to deal with architectural limitations; those should be discarded as those limitations are removed.

Incrementalism- Changing everything at the same time almost never works.  You built the code incrementally, you should change it the same way.  Always have a deliverable system at the end of every increment.

Find the starting line- Instrument the existing system so you know what it is you are replacing.  Look to start with the biggest bang first, the place where you have the greatest limitation, the biggest problem to solve.

Don't ignore the data- The implementation may change quickly, but the underlying data will change slowly.  Test with real data as soon and as often as possible, to insure you are fixing the right problem.  Synthetic data almost always leads you astray.

Manage tech debt better- Establish a culture of design quality.  Begin with the end in mind, keep your efforts moving towards your long-term goal.  Don't cut corners- those compromises may have been what lead you to your need to re-architect in the first place!

Shy away from vanity stuff- It is always tempting to incorporate that new technology, the buzzword of the day.  If you are lucky enough to be able to re-architect all the time, you can experiment, but most of us have to deliver running systems that will be stable for years to come.  Stick to technologies you know how to manage or that you are certain the team can master in a short period of time.

Prepare for mounting tensions- Fixing bugs and fighting fires is stressful on any team.  Imagine two teams, one fighting fires and the other never worrying about it?  Don't let the re-architecture cause a divide in your team.  Make friends, communicate, be transparent.

Know the business- Figure out who the stakeholders are- they are often not the people complaining the most, but those above them.  Understand all the different business motivations, and insure your efforts are in line.  You will have to be a salesperson to get everyone on board!

Get ready for politics- You are exposed- using the company's efforts to change technology instead of delivering business value.  Keep in-flight work small and well-defined.

Keep an eye on code quality- Remember: getting feature parity is very hard!  Developers will be tempted to cut/paste code from the old system.  Keep an eye on your quality with constant code reviews.  Use tools like Sonar to measure, and insure the quality metrics stay in line with expectations.

Get the team ready- Remember Conway's Law- "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations".  Create the right team structures in order to generate the right code.

If you have a little while, flip through the slide share.