Your SlideShare is downloading. ×
Enterprise Architecture
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Enterprise Architecture


Published on

These are the lessons I learned engineering solutions in Wall St.

These are the lessons I learned engineering solutions in Wall St.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Engineering Enterprise Solutions Raman Kannanrk2153 AT gmail DOT com Design and Analysis 1
  • 2. Design• It is a creative process• There is no best design – wicked science• Important lessons learned – Architecture is the key for operational stability – Capturing the design intent is key – corporate memory – Building the right product is key for alignment • Building some product right is irrelevant – Simplicity always triumphs over complexityrk2153 AT gmail DOT com Design and Analysis 2
  • 3. Delay concrete descisions• Abstract – Architecture – Parts and their relationships – Their interactions with the environment (outside view)• Refine, elaborate independent parts• Design for abstract interaction – Substitutionality principle -- Liskov – Reduce rigid coupling between systemsrk2153 AT gmail DOT com Design and Analysis 3
  • 4. Evolving an Equity Trading Platform to other asset classesrk2153 AT gmail DOT com Design and Analysis 4
  • 5. Trading Platform Implementing business functions independently and integrating them fosters engineering efficiency and software reuse. Allows component wise replacement and incremental improvements.rk2153 AT gmail DOT com Design and Analysis 5
  • 6. Design for Change!• 1996/1997 predates SOA or JBOSS or SOAP• Should this system be migrated to newer frameworks? – The current solution is factored well but – without an administrative console » Stop/start, error/status monitor, recovery – Each component interacts with DB directly » Structure of data is not standardized » Duplication and multiple database connections – Not easy to combine/replace existing » introduce new (Position, Risk, Revenue,Breaks) » or external services (EMS, ALGO service, etc) SOA can offer relief.rk2153 AT gmail DOT com Design and Analysis 6
  • 7. New Platform• Get rid of application specific data structures – XML based Order, Trade, Position,Task, Confirm, Reports, Permissions, SecurityTypes – Platform NOW is a collection of • XML generators(sources) and processors(sinks) • Asset classes can be introduced – Each with their own events, analytics and lifecycles – Introducing SWAP novation need not and will not affect unrelated • New attributes may be added (taker/provider rebate for trade) • Persistent Store can be a special processor – All other components are db independent – DB can be replaced as needed • Sources and Sink may transform using XSL Platform is now data centric and SOAP/XML is ideal.rk2153 AT gmail DOT com Design and Analysis 7
  • 8. Implementation • Choose a bus architecture for IPC – avoid direct communication – Pick a messaging toolkit (cots or pd) • Implement service management – Service definition language (WSDL) – Service Catalog – dynamic – Discovery and routing services • Processing Standard – Choose Stateless protocol – Data transformation services DTS • Ship an Order DOM return OATS record DOM • Receiver should make it right using DTS – Avoid data couplingrk2153 AT gmail DOT com Design and Analysis 8
  • 9. Plausible State Blotters Analytic MarketData SvcCatalog Blotters Engines MiscSvc XML XML XML XML JBOSS/JMS/XML EBSXML XML XML XML XML2SQL XML2FIX TrdSupport PortalsSQL ExtSvcGwy Performance Compliance ExtSvcGwy Algo/Programs Customers DB Farmrk2153 AT gmail DOT com Design and Analysis 9
  • 10. Steps• Determine XML Schema• Persistence Process• Service Definition, Discovery, Routing• Transformation Services• Monitoring and Instrumentation• Error Recovery• Stress test for performance, throughput The initial state was already factored to evolve the design.rk2153 AT gmail DOT com Design and Analysis 10
  • 11. Extensible Blotter Server/OMS Execution Venue Fix Customers Risk Management Customer Svc Position Management Reporting Portfolio Trading Support System Decision Smart Router Support Firm DB Matching Engine MDF Algos Tick db Perf Trackers Transaction db Liquidity Detection History/ SecMasterrk2153 AT gmail DOT com Design and Analysis 11
  • 12. What if?• Applications are in use – Factor reusable methods and abstractions • Capture all the flows • Compile Data Dictionary • Define XML to capture all the data, given DD – Select one application • Recast using the SOA framework, DD and XML Schema • Test and validate for performance • Introduce other applications one by one • When satisfactory – retire old system • Requires an ops team and engineering teamrk2153 AT gmail DOT com Design and Analysis 12
  • 13. Factoring Application Suite • Select one assetclass – Categorize all the required business functions – Define generic application interface • Nav(runDate) • Var(runDate,VarPolicy) • Update(Old,current) • Evolve(from,to) – Define a comprehensive application framework – Define concrete implementing the application interface – Register concrete with the application framework – Test for all the business functions • Implement other applications and repeat – Architecture will evolve iterativelyrk2153 AT gmail DOT com Design and Analysis 13
  • 14. Abstraction Levels Highest ROI Interaction between Services Services Runtime management Service level error recovery Platform independent Components Unlimited extent Framework Interaction between classes Limited extent Patterns Classes Compilation/Library Deployment Programming Error Management Data Structures + Libraries Restricted extent (colocated libraries)Layering fosters engineering discipline and prevents hacking and kludges.rk2153 AT gmail DOT com Design and Analysis 14
  • 15. What follows • Separation of concerns – Illustration • Solving Complex Problems – Divide and conquer – Reuse at the highest level • Generalize to capture abstract patterns – Usable in similar contextsrk2153 AT gmail DOT com Design and Analysis 15
  • 16. Innovation through Integration AT gmail DOT com Design and Analysis 16
  • 17. Higher levels of abstraction See hidden patterns Strip problem specific roles See the parts at a higher level A solution to a particular problem Can now solve larger set of problems Recipe: Solve the problem Study the solution Refine by making your design more abstract Streamlining communication paths Ordering and restricting (layering)Any unsolvable problem can be solved at a different level of abstractionAndrew Konig – Solve by indirection.Einstein – A problem cannot be solved with the mindset that created the problem.Different mindset, open mindset, higher level issues, defer details as much rk2153 AT gmail DOT com Design and Analysis 17
  • 18. Design Intent• Capturing design intent in a durable medium is important• Engineered buildings have buckled, when – Purchasing manager saved a few $$$ buying smaller beams and soldering them to make a big beam – While the engineer designed it with a single long beam to distribute the load evenly across – No short cuts – pay up and do it right – When in doubt -- ask for the design rationale • Make no assumptionsDon’t run on assumptions – review, check and confirm – frequentlylearn from mistakes and experts – don’t repeatrk2153 AT gmail DOT com Design and Analysis 18
  • 19. Reduce Still Further A General Purpose Problem Solving Method. AT gmail DOT com Design and Analysis 19
  • 20. • Pondering the internals, an example • classical design methods are relevant – OOAD – Data centricrk2153 AT gmail DOT com Design and Analysis 20
  • 21. Simple Exercise:Class Design Assume you wish to build forms to collect information from users and store them in a relational database. One can decide to a build A form – one at a time Or you can solve the form building in total – for a wide variety of forms.There is a trade off here…if all we wanted to do is build ONE form..just do it.However, if there are an unknown number forms and subject to frequent changesthen solving for a form is inefficient.Ask what if questions:what if I can build one form, such that it will aid in the creation of all other forms -- resulted in widget librariesBut widget libraries do not become forms overnight…someone has to identify thewidget that most suitable for eliciting that piece of information andPosition those widgets in a logical manner to make up the formrk2153 AT gmail DOT com Design and Analysis 21
  • 22. Recast the problem statementa FORM is an ordered collection of suitable display widget, positioned on the form at particular location within the form.(a model – description of )Note there is no mention of Name, Age, Color – abstract not particularGiven the chosen widgets and their positions on the form, a FORM can be painted on the screen.(a generator)Separation of concerns – description of the form separated from rendering the form on a screenrk2153 AT gmail DOT com Design and Analysis 22
  • 23. Divide & Conquer There are forms (container) and there are fields (contained). Form Universe Maker Application Maker Operations (CRUD) Window Checker Application Checker operations (accept/reject) Window Browser Application Browser Operations (view only) Window Some forms allow users to create/read/update/delete data. (maker) Some forms allow users to verify (and accept) captured data. (checker) Some forms allow users to view data without the ability to modify. (Browser) A form at runtime is rendered in its own window.rk2153 AT gmail DOT com Design and Analysis 23
  • 24. Analysis by refinement:Content Universe• What is a form – Labels, aka names • constant values hint about the values to expected – Values, aka entryfield • User enters a value from an infinite set of values – Free form – Some may be numbers only, text, or combination • User selects from a finite set of values – One of two values – special case – One of a dozen values • User selects from a growing list of values – Related to a value already entered in the same form or another form – Position and order of these labels/values A form = one or more (labels, entryfields, position and order)rk2153 AT gmail DOT com Design and Analysis 24
  • 25. What all can the user enter?Item Domain Description CommentUserEntered TextEntry validate for alphabets, textField NameUserEntered Numerals validate for numbers only, textField Age, SalaryUserEntered Masked private not visible, textField passwordUserEntered AnyEntry Any alphabet or any number, textField FreeformProse TextBox Text with option to enter a file Freeform or a FileBrowserBoolean one of two values Close Domain RadioButton GenderImages,videos DialogBox To enter URL or select a file FileBrowser Shape,FamilyRelationship (mother/father, son,StaticList categories Closed Domain PopupMenu daughter) Customer Name (Open grows with time), DepartmentsDynamicList categories Closed or Open Domain PopupMenu closed Closed – Cannot make up a new countryReferential RestrictedCategories like in the case of customer name Countries, Currencies The original solution in 1992 did not include Prose/Image or videos. There were no URLS then. By adding new renderers and allowing more Item types, entire framework could be used without much effort. Solutions can evolve if engineered. rk2153 AT gmail DOT com Design and Analysis 25
  • 26. Analysis to Design• So far in the analysis we have identified only the what not how…• In the design phase how will these come together (collaborate and coordinate)• In the design phase ideas foreign to the domain have to be introduced ( interpretor, repository, libraries)Object Oriented approach maintains the continuity from requirement to solution.rk2153 AT gmail DOT com Design and Analysis 26
  • 27. It aint easy! Design for change, think long, think hard. We need: A repository An interpretor A widget class library A database library (two tier) or gateway (three tier) System Services – authentication, process etc AT gmail DOT com Design and Analysis 27
  • 28. Summary• Be Abstract initially Architecture – Understand the flow, minimize coupling, streamline flow – Design for change and diagnostics• Then, study what you are trying to solve -- analysis• Then, on how to do it -- design – Keep analysis separate from design• Object Oriented can help maintaining a simple language for the entire life cycle. – Eliminate translating between what was needed to how it was realized in the program – OO allows you to speak the same language for the SDLC duration. Internal Structure (OOAD), external Structure(SOA)rk2153 AT gmail DOT com Design and Analysis 28