Role of Information Technologyin achievingCompetitive Differentiation

Raman Kannan & Scott BurrillRosenblatt Securities Inc.

Agenda

Software Architecture Evolution N-tier,3-Tier, 2-Tier – what is all this? What is SOA?

How does it relate to N-tier, 3-tier etc What is in it for me, I am an Asset Manager How can it benefit MultiAsset Manager

History: Software Evolution

Before networks and enterprise Internal structure of Software was the focus

Modular design OO Design – class hierarchy, patterns etc Related ideas of

inheritance,polymorphism,abstraction, information hiding coupling, cohesion etc

With the advent of networks Internal structural merits are not sufficient What matters is how well a software unit adopts

and reacts/interacts with the external world Other systems, data sources etc Software Architecture is now the focus.

Internal structure still matters

Common Issues

Integration is the challenge Semantically and structurally

Maintenance accounts for majority of the Life Cycle cost

Design for Integration and Maintenance Static integration lead to frameworks Dynamic integration is the driver for components

and now the service oriented architecture. Architecture – focus is upon

external structure Interaction(synchronous/asynchronous)

RPC,Messaging,and object migration connectivity

P2P,Broadcast and multicast etc

Newer Issues Discovery

Requirements change Successful Business – constantly evolving All the components cannot be anticipated at the

get go Security

DoD IP Stack is weak on security IP 6 may offer relief – 15+ years away

Fault Tolerance Parts of the system can and will fail Rest should continue to function -proportionately

Load Balancing – Scalability if successful huge volume Otherwise no volume

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

The software architecture represents the earliest software design decisions. These design decisions are the most critical to get right and the most difficult to change downstream in the system development life cycle. The software architecture is the first design artifact addressing reliability, modifiability, security, real-time performance, and interoperability goals and requirements.

structural units and different structural relationships

Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Reading, Mass.: Addison Wesley, 1998.

Software Architecture

A reference architecture is the generalized architecture of several end systems that share one or more common domains. The reference architecture defines the infrastructure common to the end systems and the interfaces of components that will be included in the end systems. The reference architecture is then instantiated to create a software architecture of a specific system. The definition of the reference architecture facilitates deriving and extending new software architectures for classes of systems. A reference architecture, therefore, plays a dual role with regard to specific target software architectures.

First, it generalizes and extracts common functions and configurations.

Second, it provides a base for instantiating target systems that use that common base more reliably and cost effectively.

Reference Architecture

Illustration

Tyler has integrated and customized OMS and EMS

At RIM – consciously or otherwise will draw upon past experience The RIM implementation will not be identical Particular OMS may vary, EMS may change Underlying structure and information pathway

will remain the same. Simpler examples

Client/server 3 tier architecture

Software Design and Architecture is a wicked science and NOT an exact science

Considerations of the day

Computers are faster and cheaper Networks are faster and cheaper Storage is faster and cheaper Human effort is expensive

optimizing for the engineer is the key clever programming is out simple/comprehensible is in reuse is a key factor

higher the level better the return All drivers toward reusable software

Reconfigurable and deployable in unforseen ways

Simple Architectures

Data + Logic

Presentation

Data

Presentation

Logic

3 Tier

2 Tier

monolithic

Source 1

Source n

Logical Step 1

Logical Step 2

EndUser Mgr

Conversion(s)

Need for N-Tier

Multiple Data Sources Logic can become too complex

Difficult to maintain – too large Decomposition Example: At a brokerage

Executions from basket trading Executions from single stock trades

Which are managed high touch Auto-routed low touch

Presentation can vary mobile/web/desktop push/pull, bcast modes of communication intranet/extranet – security schemes

Enterprise solution require n-tierN-Tier is components based

Scott's Layered Diagram

Component architecture

A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behaviour common to all components within an architecture.http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/

Limitations Components are written for a target architecture

Cannot be dropped into a different architecture Each component is aware of other components

Integration is still an effort No standard procedure to discover new components Lack of a standard description Management is not standardized

New Opportunities

I am an Asset Manager – introducing derivatives into my product mix I have valuation engines for TSY, MBS, equities

etc How can I introduce a Swap Pricing Engine I do not want to rewrite my tradeEntry or

PositionMonitor application suite What about CDS Engines or other new products

that will be introduced I want my traders desktop suite to evolve with

new products as and when we introduce I want the system to select appropriate

pricingEngine as needed

How can IT foster new business as it evolves

Enter SOA

Service Oriented Architecture Built on Standards

XML Recall processing speed is not a concern for many

applications except for analytical processes Information structure can change

Amorphous structural dependency Not as brittle as data structure requiring recompilation XML in combination of XSL or other transformation

Can provide for rich UI,logic and db management Service Definition Language -- wsdl/soap Discovery Standard -- http://uddi.org/taxonomies/ Management Reference and PD implementations

New Developments

Stage was set for a new paradigm

XML + XML processing?XSL flexible structures/incremental compiling dynamic loading + new integration techniques web centric language like java Directory Service/Discovery WWW Infrastructures/J2EE Containers/proxy/JMS SOAP, W3C Standards data driven becomes content driven Speed/Performance improvements many dissatisfied brains around the world several cottage industry solution

http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#discovery_service

Web Services Architecture Stack

SOA is still a TLA - why?

good decisions but numerous bad outcomes Excitement without conviction

Impatient management SOA is not a 6 month effort

SOA without talent is lot harder numerous flavors of resistance

age old Not My Idea Comfort zone – I know C++ Do not like MSFT – hate dot net

Still evolving Many debates going on Many candidate and competing implementations

Axis and Axis2 – apache project

Broad Guidelines

First understand and define the data architecture

Do not design the data -- based on a particular application Capture what is essential for the business -- firm

level – design for change Example

Do not capture just basket trading data What information is important for your business Capture all of that

Commission structure Liquidity information provider/taker

Implement CRUD service for all the business objects Without regard to any particular application

Incremental periodic deliverables – data, presentation,business process one at a timeShort term goals with long term objectives aligned with business goals

Security and Presentation

Define security architecture Security can never be after thought

Understand and over build for flexible presentation New interaction paradigm is just around the

corner develop a team – team buy in

Train the team, be patient Not by decree again seek conviction Final consensus matters, not initial resistance

Stakeholder – must own and 100% involved Go for it!

Reference Architecture

CRUDOperators DBMS

DB Vendor freeDesign for changecapture all the infoTransaction ServicesRelationshipConstraint Managers

Bus. LogicWorkflowObjects

PresentationMediators

Display Agents

Composite EntityTransformationsSelectorsRules/FiltersRouting Agent

RichSemi/Structured Information UnitsProtocol AgentsProxy services

change the manner in which information is presented without impactchange the DB Schema without impactreroute/recombine processing elements, creating new workflowsProvide information in any format as required using transforms and filtersNew display devices can be introduced

OpenTrade – FMCP -- Gary

Clients

Servlets

AccountServlet

FactorServlet

TransxServlet

PositionServlet

SecMasterServlet

AccountEngine

FactorEngine

TransactionEngine

AssetEngine

txml

dbml

AssetS

ervice

Transa

ctionServi

ce

Clients

http

J2EE

FixServi

ce

EJBs

OT Lessons Learned

Defer integration -- just-in-time integration Anticipate newer forms of transport Do not dictate rigid data formats

Employ contemporary transformation techniques Allow entities to discover through directory service Dont stuff IT conventions down business throats

Allow multiple naming and format conventions Use proven design techniques –

OO, polymorphism and inheritance, Programming by contract – interface driven

OT Lessons Learned - 2

Capture all the data into a database Transactions Market data Reference data Representational data – reports MIS data – accounts, users, entitlements

Keep the application independent of the database

Do not tie the logic with database using 2 tier in any shape or form

Keep it User centric from day 1 Highly customizable Interactive and ultra real time

SOA works – OT is not vaporware

TransactionSink

FixGwyAgent

Fills

ConsolidationService Source

txml

FixGwy

fix

fix T

fix txml

Intermediate format

Direct transformation does not exist

Kernel finds a transformation path

Earned Value!

fix

TransactionSink

post

FixGwyAgent Source

FixServiceSink

txml

FixGwy

T

fix

txml

This configuration would workJust as fine by reconfiguring theservice definition.Architectural Stability.

Independently developed systems interact and exchange information as needed when needed.

The integration is facilitated by the catalinatech Kernel.

Enterprise System capabilities are reconfigurable/adaptive /reusable and very stable.

We done it!

Fills

fix

FixFillService

TransactionSink

post

FixGwyAgent SinkSource

Fills

FixServiceConsolidationService SinkSource

sql

txml

FixGwy

T

fix

fix

txml

T

Recap

Get the management/stakeholder on the same side Build a team, train the team – be an evangelist Charge the team

To develop enterprise data schema Independent of applications

To develop applications independent of data and presentation – adopt programming by contract

To develop presentations that are independent of applications and rich

Be patient, anticipate hickups Become CPR expert, do not bail out easy

Keep delivering value to business in small increments – no one can wait 3 years

SOA is a multi year commitment Foundation for many generations

What will you gain?

Accomplishment – euphoria IT that is service oriented

Nimble and responsive Business needs (changing and new needs)

IT becomes key enabler Deliver competitive differentiation and advantage to

business units Deliver new critical functionality faster At a fraction of the cost incurred using traditional

methods Watch your IT productivity soar However, it is not all about technology

It is about people, processes besides technologyThank you