SW Architecture Monolithic to SOA
Upcoming SlideShare
Loading in...5
×
 

SW Architecture Monolithic to SOA

on

  • 2,601 views

Evolution of Software Architecture

Evolution of Software Architecture
Service Oriented Architecture -- benefits and a model procedure

Statistics

Views

Total Views
2,601
Views on SlideShare
2,579
Embed Views
22

Actions

Likes
0
Downloads
41
Comments
0

5 Embeds 22

http://www.slideshare.net 9
http://www.linkedin.com 5
http://www.assetcorporation.net 3
https://www.linkedin.com 3
http://assetcorporation.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SW Architecture Monolithic to SOA SW Architecture Monolithic to SOA Presentation Transcript

  • Role of Information Technology in achieving Competitive Differentiation Raman Kannan & Scott Burrill Rosenblatt 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
  • Software Architecture 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.
  • Reference 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.
  • 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-tier
    N-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
  • Web Services Architecture Stack http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#discovery_service
  • 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 time Short 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 CRUD Operators DBMS DB Vendor free Design for change capture all the info Transaction Services Relationship Constraint Managers Bus. Logic Workflow Objects Presentation Mediators Display Agents Composite Entity Transformations Selectors Rules/Filters Routing Agent Rich Semi/Structured Information Units Protocol Agents Proxy services change the manner in which information is presented without impact change the DB Schema without impact reroute/recombine processing elements, creating new workflows Provide information in any format as required using transforms and filters New display devices can be introduced
  • OpenTrade – FMCP -- Gary Clients Servlets AccountServlet FactorServlet TransxServlet PositionServlet SecMasterServlet AccountEngine FactorEngine TransactionEngine AssetEngine AssetService TransactionService Clients http J2EE FixService EJBs txml dbml
  • 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 ConsolidationService Source FixGwy T Direct transformation does not exist Kernel finds a transformation path Fills txml fix fix fix txml Intermediate format
  • Earned Value! TransactionSink post FixGwyAgent Source FixService Sink FixGwy T This configuration would work Just as fine by reconfiguring the service 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. fix txml fix txml
  • We done it! FixFillService TransactionSink post FixService ConsolidationService Sink Source FixGwy T T Fills fix FixGwyAgent Sink Source Fills sql txml fix fix txml
  • 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 technology
    Thank you