Interoperability

Welcome to Architect Insight 2010Learning's from delivering a large, complex and highly visible project

Darren JeffordSolutions Architect, Microsoft UK

darrenj@microsoft.com

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

PROJECT OVERVIEW

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

Faster Payments

CI

HSBC

Barclays

Halifax

First DirectAbbey

…

Lloyds

• 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

• 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

• 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

DESIGN APPROACH

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

• Security

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

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)

4 348.8 11.62666667 1.162666667 0.34883 465.2 15.50666667 1.550666667 0.46522 697.7 23.25666667 2.325666667 0.69771 1395.5 46.51666667 4.651666667 1.3955

SOLUTION ARCHITECT?

• 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”

Solution Architect

• 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..

Solution Architect: Extreme Ambiguity

LEARNINGS

• 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

Learning's• 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

• 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

• Happy to dig into more technical detail after the session– Microsoft Services Booth

Q&A

© 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.