Ibt Soa Babson Talk V8

Evolution of SOA Strategies & Practice at IBT Prashant Sarode Director SOA-Web Services Group Investors Bank & Trust Co. May 9, 2007

Brief Bio of Speaker Heads the SOA-Web Services Group @Investors Bank & Trust Co., and is responsible for SOA architecture, planning, and delivery of business services.He has been a key thought leader, architect and delivery manager in Investors Bank’s SOA journey, and has been successful in leading “visionary” technology initiatives to satisfy business needs. He has overall 11years of experience in IT, and has been serving on the Reader Advisory Board of Wall Street & Technology Magazine since 2003.Involved in ISDA, FpML & Swift activities around defining market practices for OTC Derivatives trading. Recent interests & focus around OTC Derivatives Straight-Through-Processing by SOA approaches (using FpML and WS-CDL.)‏ Has a Bachelors Degree in Engineering and an MBA in Finance.

Agenda Topics Company Overview Goals of SOA @IBT Guiding Principles SOA Evolution @IBT First Steps, Brisk walk, Ready for the SOA marathon. Case Studies Best Practices / Lessons learned. What’s next? This talk will cover how we at Investors Bank & Trust (IBT) view SOA, how we accomplished making SOA part of everyday business, what we learned in the course of that work, and what we expect our next challenges to be.

Company: Business Overview What is IBT? IBT is a ‘Back’ and ‘Middle Office’ service provider whose primary Client is financial asset managers. ( IBT is not a retail Bank and IBT doesn’t provide retail services like a Fidelity or a Schwab ). The most recognizable service is the calculation of the Net Asset Value (NAV) for a mutual fund but there are many others including fund accounting, fund administration, trade operations, transfer agency, securities lending, and foreign exchange. IBT services $2.2Trillion in assets invested in 92 countries for its Clients.* 4200 Employees based in US and Europe.* ‘ we target spending approximately 18-20% of our consolidated net operating revenue on technology.’** Important Fact: On February 5, 2007, State Street Corporation and Investors entered into a definitive agreement for State Street to acquire Investors. *- As of 12/31/06 ** - from 2006 Annual Report

Company: Technology Overview Typical large financial services company: Diverse platforms from different generations of technology Some third-party products which don’t fit the technology strategy We strive for standardization on skill-sets and organizational processes but pace of change coupled with legacy technology can make that a challenge Technology Stack Database: Oracle (majority), MSSQL Server & Sybase (minority), MS Access (tactical)‏ Application Environments: J2EE based application, .Net based applications, Power Builder 9, Cobol. Messaging: SeeBeyond, MQ, JMS (based on J2EE application server)‏ 3 rd party products – Mix of products for securities processing (SWIFT, Sungard, Thomson are example vendors). Open Source footprint: myFaces, Struts, Log4j, Spring and several others libraries from certified sources.

What’s a Service?: the Stereo view Services are active running code with a standardized interface (SOAP/WSDL/XML) that provide a business function . An analogy: Your Receiver is a provider of audio-video services. You don’t know or care what’s inside the box. You care that it can provide a service to you. You care that it has a standard interface. Google has search Services. Amazon has shopping Services. Do you know or care how they built them? No, you care that you can use them.

What’s a Service?: Evolution from Sub-Routine to Services Objects Piece of self-contained code with logic for a small part of the whole business area. Usually a module within a single language and single process space Example: A Pricing object knows about IBM price data. Components Code that gets re-used on application or system level. Usually modules that can be accessed in a distributed manner across languages but using proprietary protocols . Example: A logging library we use for all the Java applications. EJBs, CORBA objects, COM objects Services Active, running code that delivers business and system functions. Modules accessed in a distributed manner using standard protocols - SOAP, XML, HTTP Example: Content Management Service Sub-Routines Piece of self-contained code with logic for a small part of the whole business area. Usually a module within a single language and single process space. Typically free-form without object design patterns. 1958 – Invention of the subroutine for Fortran II 1960s on - Object Oriented Languages Smalltalk(1969)‏ 1970s – LANs 1980s – Network Objects 1998 – XML/ RPC submitted to W3C Key Driver of this evolution: How do we better encapsulate, share & maintain business logic?

Expectations/Goals from SOA @IBT Reduce business expenses and operational issues by providing a common point of processing and access for internal business processes. IBT’s business is data-driven so having common data is very, very important. Why provide the same data in two different ways only to have to reconcile the sources? Remove spending on silo integration so you can redeploy that money to other projects Deliver solutions with feasible economics through the use of industry standard integration technologies Pre-SOA (SOAP/WSDL) integration costs were higher and some projects wouldn’t be feasible Cross-company integration was difficult or impractical without technology standards Provide new service offerings more rapidly by: Leverage services for both internal applications as well as external Client-facing services Enabling real-time, event-based business use cases ( traditional protocols like FTP don’t work). Straight-through-Processing (STP) is the now/future of business. Reduce overall IT budget by: Accommodating a diverse set of technology platforms and skill-sets into a standards-based architecture. Decoupling the longer-lived logic/data tier from the presentation layer (which has changed every 3-5 years)‏ Taking advantage of horizontal scalability and the emerging economics of parallel processing

Guiding Principles for SOA Initiatives Deliver demonstrable business value: Delivery value with every project. No technology for technology sake. Adhere to core Technology Strategy: “Common Data, Common Business Logic, Multi-Channel Secure Distributed Access” Be “Stratactical”: Execute tactical projects with a strategic framework. Don’t budget separately. Be Iterative: Do not boil the ocean. Its impossible to deliver the final service on the first try but you can take advantage of the fact they are easy to extend. Be Viral : Make SOA delivery part of your standard project delivery and all of your development resources can and will participate. Govern centrally, develop locally. Use core vendor products for platform but use your own thought leadership: Its business problems you are solving. You know that better than anyone. Realize that services are an evolution of what you have today and that all the key ‘stacks’ have SOA capability. Services start with Business Use-Case first not Code first: Code first services are extensions of existing silos. Test basic operations with multiple service consumer technologies so you don’t have to redevelop service due to interoperability issues.

Stages of SOA Evolution @IBT Q2’04-Q2’05 First Steps (bottom-up)‏ Q2’05 to Q2’06 Brisk Walk (bottom-up & top-down)‏ Q2’06 on Ready for the SOA Marathon (top-down)‏ Industry IBT First external service deployed. Major re-engineering programs aligned around SOA – adding elements like Rules Engines, BPM, BAM, Working to understand issues of SOA around STP/real-time processing. Deployment of business services as well as technical services. Service adoption across core development groups. Education/Evangelizing. Services being deployed across multiple areas achieving better STP. Moving SOA into standard SDLC governance. XML-based services exist with presentation/logic tier separation. SOA in core Technology Strategy IBT Clients discussing service delivery via Web Services and enquiring our capabilities. First service internal Web Service (into Production by mid-2005). Development largely centralized in core architecture group. BPM & BAM tools available Integration of RIA/Services models emerging. Security/Reliability start to move into the ‘stack’ (WS 6.2/WLS 9/Vista)‏ Emergence of WS-* standards for Process Emergence of Governance, QoS, Security, Management products for SOA. Security/XML appliances available ESB thinking emerging (JBI specs development). Key Vendors standardizing on offerings WS-* standards –convergence emerging WS-I agreement around interoperability.

Case Study : Content Management Service [First-Steps] Solution Overview J2EE/WebLogic-based service front ending the Documentum repository Simple set of operations in WSDL: Get, Add, Update, Search Tested with Powerbuilder, Java, and .NET service consumers. Business Value Allows centralized access to document management system with common security. Reduces development costs since interface is stripped down to core business functions for Bank Reduces training costs since only the service developers needed to learn the Documentum APIs/life-cycle Provides standard technical method with little to no integration costs. Hides upgrades of core document management engine from consumer applications. Business Context The Bank was in the process of standardizing on a document management system . Document management is important for compliance/regulatory reasons. We had multiple business groups which would use the document management system. Each group wanted access to the same repository but had different technologies (PowerBuilder, Java, .NET). We wanted centralized, simple access where the consuming groups didn’t have to know the complex document management system. We didn’t want every developer having to learn the 350-class Documentum API. We wanted to hide the implementation/upgrades of the core repository from the applications.

Learned and New Questions [First-Steps] Several issues with interoperability discovered and accommodated in WSDL designs. Tools ensuring WS-I interoperability limited in their help to service designer. Some platforms support only RPC-Lit while others support DOC-Lit, attachment issues etc. DNS not UDDI to hide service behind existing infrastructure. Value realized in the form of easy EAI for technical services like Content Management. But It really works. Need better testing products for next stages – ( IBT bought Mercury toolset )‏ Application Security Model needs to be evolved to support: Access to services from only authorized applications. User Credential carry-over from application-to-service model to services-to-service (nth level). How best to support more than one entry point into your web service? Some platforms support only RPC-Literal while others support DOC-Literal Lessons Learned Questions for Next Stage

Case Study : Security Service [Brisk Walk] Business Context We needed to provide a standard model for authorization and authentication in the face of SOA and the desire to supplement the existing proprietary security model/repository with a new Federated Identify platform. Need to decouple the identify repository from the applications so as to prevent future disruption of application projects. Need to be able to provide same security function across multiple technology platforms (including legacy technologies). Solution Overview J2EE/WebLogic-based service front ending the security repositories Applications make call to security service to get tokens which can then be passed with the service call. The called service then rechecks that token by calling the repositories. Token has an expiration period. Business Value Provides centralized authorization and authentication data Hides transition/melding of proprietary/vendor identity platforms. Enables reach of security services into legacy platforms. Reduces IT development costs by creating single standard pattern for authorization and authentication

Case Study : Cash Availability Service [Brisk Walk] Business Context Fund Managers need to know how much cash they have to trade with by mid-morning EST. They want that data emailed to them in a spreadsheet with a custom format. The spreadsheet was frequently changing and locally customized. The data for that spreadsheet was spread across several databases and applications. In existing process, the end users would copy that data from each source into the sheet, doing validations/transformations along the way. The process was time consuming, error prone, and difficult to audit. The business wanted to meet business SLAs with higher quality by automating process. Solution Overview J2EE/WebLogic-based service front ending the data sources. Single XML returned from service to service consumer in synchronous call. Excel service consumer – same user interface but data acquisition was done through native VBA generated from WSDL. Business Value Eliminated existing Client-SLA issues very rapidly. Eliminated errors created by existing manual process. Retained local user interface and local ability to customize tool (Excel)‏ Established delivery platform of the future: Provided a tactical platform to expand Cash processing across other business groups and add new data/operations to.

Lessons Learned and New Questions [Brisk Walk] Emergence of Business Partner involvement & confidence in approach. Business problems with data integration can be solved fairly easily . Separation of central data from local consumption is important. Microsoft Office is a very useful service consumer for your business (but not technically perfect, code generation has some quirks). Realize that you’ll make a few mistakes on the granularity of the service but don’t let that stop you. Govern that Web Services are not made for everything . Be Service Ready. Realize that sometimes you will have multiple protocols to the same logic/data for performance reasons (Example: RMI in addition to SOAP). But it really works. Need to start thinking about organizational issues as services proliferate – Need to think about what area owns a service. IBT was setting ownership guidelines on who owned a technical service and who owned a business service. Governance/training has to be expanded to keep pace with deployments – standards are key to value and reuse so service models have to be controlled. Lessons Learned New Questions

Case Study : External Trading Service [Ready for Marathon] Solution Overview J2EE/WebLogic-based service front ending the core IBT trading processes. HTTPS-level security on service link, Client handles identity of Trader. Existing PKI infrastructure was leveraged. Service consumer is third-party .NET-based platform Business Value Allows Client to use third-party ‘white label’ portal Creates STP for trading use case Is low cost solution and meets ROI challenges Provides for quicker time-to-market given simplicity of technical integration. Business Context IBT’s Client wanted to use a third-party portal platform for acting as a front-end for trading money market funds. The business use case was a real-time synchronous transaction (STP). The cost of development needed to be low in order for the ROI to be correct. The third-party chosen was based on .NET and any development done there would be done by that team. The existing internal systems were never designed to be extended outside the local business environment. The solution needed to adhere to proper security standards given the trading context.

Lessons learned/Best Practices But It works. Be opportunistic, take calculated risks and embed incremental R&D into a delivery project. Provide for impact of Service Orientation on organization: IT Organization – service ownership rather than app ownership. Product management-style planning Federated control model more appropriate then a centralized control model. Embed SOA champions into business IT delivery organizations. Create expandable SOA architecture from existing web infrastructure. Most companies (with client facing web applications) already will have plethora of web infrastructure (Load Balancers, PKI Application Servers). Exploit that infrastructure and experience before buying new infrastructure. Net new infrastructure cost for SOA @IBT= $0.

What’s Next? Integrate Services using Business Process Management (BPM)‏ Need to understand standards evolution and how standards tie together - (BPMN, Choreography (WS-CDL), BPEL)‏ Need to understand what exceptions pass through a BPM tool (not all since that creates bottlenecks). Need to understand service choreography practices between businesses Add monitoring of business process through the use of a Business Activity Monitoring (BAM) toolset Ability to report easily on core business processes/transactions is there. What’s best way to use it? Evolve messaging for rich stateful application models Need to understand application state-fullness for STP as we move from User App-to-Service Call model to Service/Service messaging. What’s the right use of an ESB? Need to understand how key vendor products/standards integrate (WS-ReliableMessaging, PubSub, IPv6). Create common data and metadata – SOA doesn’t work without common definitions. Business value of SOA isn’t realized unless you can provide common data. Using RIA technologies, like Abobe’s Flex, that are natively designed as service consumers. Develop/deploy RIA model with reliability, push model for event-based RIA apps

Ibt Soa Babson Talk V8

More Related Content

What's hot (20)

Similar to Ibt Soa Babson Talk V8 (20)

Recently uploaded (20)

Ibt Soa Babson Talk V8