- Mapping the current state architecture to the future state and aligning this future state to support the business vision
- Defining the architecture to a suitable level that allows for reasonable estimation precision
- Identifying the key architectural risks for the program
- Working through challenges with third party and legacy interfaces
- Defining services, service orchestration, principles for where and how transformation/truncation/compensation (as examples) should be applied
Often programs would like to wish that these thorny issues would disappear, but the clarity around these items is important to the program outcomes, and these are often multi-disciplinary activities that require several views. Some of the most interesting and challenging points in a core banking transformation are when these types of issues are highlighted and need to be resolved. So what is the best way to work through these issues? Typically, time is of the essence and resources are scarce and distracted but these types of items are too important to be handled through email and spare cycles.
The solution: Architecture Sprints.
I define an architecture sprint as a highly focused multi-disciplinary walkthrough, discussion, and design session. The concept is that good design doesn’t just happen: it requires insight, experience, communication and commitment.
When to Sprint?
If there is an urgent, material issue that needs to be assessed from several angles or a potentially contentious design issue that needs clarity a sprint may help avoid or remove a barrier. It’s important not to sprint too often as this will take significant energy and focus from the team.
How to Sprint? First of all, define the topic clearly and ensure that it is focused on an area that is at a suitable level of detail such that it’s possible to design with a room full of people. If you room spills over to another room, consider changing your topic boundaries so that it is more specific. It should also be something material in nature that is seen as critical to the outcome of the program — I have highlighted some common areas above but your program may differ. Ensure that all of the participants are engaged, informed and empowered to make design decisions and commit their teams to that design. Make sure that all interested parties are fully represented by people that understand their needs and can make suggestions and decisions. Establish a specific timeline for the discussion, announce the topic and send out the background information and materials beforehand — everyone should arrive familiar with the background and with a strong handle on the issue being addressed. Order pizza, coffee, salad or whatever is going to keep the group sequestered, focused, and fully energized. Assign a scribe, have plenty of whiteboards and markers and have a good facilitator. Have some ground rules about focus and priority. Also have people outside the room on call in case they need to be consulted or brought in to answer some questions. Document all decisions and commitments: agree to disagree at times, but commit to the design. Leave all titles, companies, any politics at the door: the goal is design clarity and creating the best outcome for the program. Now the hard part: work through the end to end design or issue and establish a consistent view or recommendation while documenting any objections, risks or alternate paths. Rationalize the merits of the suggested approach while fairly weighing the pros and cons of other methods. The goal is not consensus, the goal is clarity including any deficiencies of the recommended approach — consensus may or may not be achieved but it is good to capture and understand dissenting views and alternate suggestions.
The goal of the sprint is establishing full design clarity around a critical issue. A focused approach where multiple team members work through a critical issue together and leave with both clarity and commitment to the established design can help a program move forward both quickly and with precision.