sw architecture monolithic to soa
DESCRIPTION
Evolution of Software Architecture Service Oriented Architecture -- benefits and a model procedureTRANSCRIPT
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