1. Interoperability

2. Session Objectives and Takeaways This is a largely a non-technical discussion Session Objective(s): – Share my learning's from the delivery of an MCS Complex Project – Share approaches, techniques and things to watch out for – Understand what a Solution Architect actually does on these types of projects Key Takeaway 1: Learning's to help assist your current or future projects Key Takeaway 2: Understand the demands on a Solution Architect

3. PROJECT OVERVIEW

4. Project Overview Microsoft Consulting Services complex project Payments Platform for Financial Services organisation – One platform for all Payment Processing – Faster Payments (Low Latency) – Batch Payment Processing (Batch) Fixed Price and commitment around Non Functional Requirements

5. Faster Payments Consumer pressure to speed up payment processing Central Network Infrastructure created by the Industry – Gateway appliance used deployed in each organisation Payments must be posted onto the customers ledger within 3 seconds Payments are also sent via the gateway Fraud, HotScan and Repair Services

6. SAP Core Banking being adopted – Replacing mainframes that currently hold accounts Widespread industry use of Batch files for Payments – Slow move towards more real-time payment schemes ~5 million payments arrive each day through flat-files Payments need to be secured, validated and posted to the ledger grouped by account number – Every payment has to be signed for integrity reasons – Painful when you have 5 million payments Complex “unhappy path” processing Batch Payment Processing

9. Successful Faster Payments now in live operation delivering payments to customers – Design Load of around 75tps at peak Performance Targets were blown out of the water – Sub Second compared to a target of 2.5 (95%) – In the customer environment we have seen ~200ms within the solution! 3 BizTalk Servers (no resilience) could meet the performance targets Batch Solution handed over Project Results

10. DESIGN APPROACH

11. Key Design Principles Performance, Performance, Performance! Optimised Payment Processing Simplification Reliable SLA adherence – Mixing SLA traffic with Non SLA traffic? Security

12. Design Approach Understand all parts of the solution – Including aspects well out of your control Performance Assessment – Find problems in dependent systems ahead of time Strongly defend the core principles – Don’t be afraid to challenge strange requirements that compromise the design

13. To Batch or not to Batch? 5 Million Payments need to be.. – Pre-Processed in around 30 minutes – Processed in 4 hours (posting to SAP) Processing payments in batch form significantly reduces the “message/sec” pressure on Processing – And avoids a mountain of hardware and licenses Processing Window (Hours) Payments Processed/sec Processing Batches/sec (Batch Size of 30) Processing Batches/sec (Batch Size of 300) Processing Batches/sec (Batch Size of 1000) 4348.811.626666671.1626666670.3488 3465.215.506666671.5506666670.4652 2697.723.256666672.3256666670.6977 11395.546.516666674.6516666671.3955

14. SOLUTION ARCHITECT?

15. The “Technical Face” of the project Imperative that you understand the underlying technology – Credibility, End to end understanding “On the hook” Technical Leadership – Steer rather than dictate – Ensure adherence to requirements, think about the “ilities”“ilities” Solution Architect

16. Stakeholder Management Team Member “management” Set the Vision Don’t be afraid to take a bet on individuals for key team roles Protect the team from “noise” / risks / unknowns Solution Architect..

17. Solution Architect: Extreme Ambiguity

18. LEARNINGS

19. Performance Assessment of dependent systems is key Get an End To End Path working in the first iteration Operational Monitoring – If it moves… Clear Assumptions up front Learning's

20. All servers are not alike with regard to performance – Even if you match sockets, cores and comparable Ghz Consider extreme failure scenarios – Loss of AD and therefore authentication – e.g. Rollback idempotency records

21. Building The Team – Who is available may not be the best option – What do they want out of the project? Communication – Don’t protect the team too much from programme decisions Estimation – Involvement of the potential delivery team is key to their buy-in – Track the real cost in terms of hours Learning's

22. Happy to dig into more technical detail after the session – Microsoft Services Booth Q&A

23. © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.