DBEA for Midterms PDF

🍉 Digital banking enterprise architecture week 1 - intro to banking technology & operations and architecture week 2 - digital banking channels week 3 - SOA in banking (enterprise platforms) week 4 - enterprise platforms: SOA - service...

🍉 Digital banking enterprise architecture week 1 - intro to banking technology & operations and architecture week 2 - digital banking channels week 3 - SOA in banking (enterprise platforms) week 4 - enterprise platforms: SOA - service mediation, ESB framework, SOA governance week 5 - migrating from monoliths to microservices week 6 - BPM in banking week 7 - BRMS in banking lab 5 (tested in mid terms) lab 4 project *Submit assignments/labs into the dropbox by start of class on the due date. due dates: project - (week 13) 13 nov, 35% midterm Midterm Exam, In-Class, Online, 20 questions, 40 mins Covers Week 1-7 Lecture, plus Lab 5 API key: 84fcb26d-5b89-414a-8e15-744c5a1c5770 module topics main focus 1. architecture roles in banking types of Architect roles, career paths 2. technology and operations functions in banking how do “back office” functions support the business “front office” digital banking channels 3. enterprise architecture platforms what are the common platforms that provide a flexible and agile architecture Digital banking enterprise architecture 1  week 1 - intro to banking technology & operations and architecture bank - general architecture and operations digital bank - does not have a physical server VS data bank - everything is on the cloud architecture - blueprint of the structure enterprise architect - developing an architecture, describes overview of a bank VS solution architect - gets assigned to one solution at a time, solution can be a business application, produces document inclusive of specifications (functional and non-functional) SMU unified banking process framework (UBPF) used to visualize how a bank meet customer needs and internal management needs through processes, data and technology customer types 1. Investment Banking & Capital Markets 2. Corporate & Institutional Banking 3. Private Banking & Wealth Management 4. Retail Banking transaction fulfillment enablers process, data, technology bank management needs Digital banking enterprise architecture 2  financial management risk management channel management operations & technology management business function framework split into 5 major departments Product, Party (customer), Operations, Channels, Corporate & Shared Services bank functions (important) front office: interact with customers 1. Customer Origination 2. Account Origination 3. Transaction Origination - making trades 4. Product Sales 5. Customer Services 6. Financial Advisory Digital banking enterprise architecture 3  middle office back office: technology sector split into 2 main components 1. run the bank - BAU (business as usual) data center data center outages affect bank’s reputation and incur regulatory penalties to achieve 24/7 uptime, there are built in redundancies at many levels, so there is no single point of failure load balanced, high availability servers, active-active backup networks, incoming high voltage power, air-conditioning compressors disaster recovery (backup) DC physical security 2FA authorized access change management any change to productin systems require prior approval by Change Management Committee (normally Data Centre head) changes are scheduled on weekends, avoiding regulatory reporting periods types of changes new application systems, OS patching, DB patching, network firewall rules, performance tuning, changing of cables application versioning is done by Change Team one of the few in the bank who have access to all network environments Development (DEV) Digital banking enterprise architecture 4  System Integration Testing (SIT) User Acceptance Testing (UAT) Production (PROD) incident management weekly meeting to follow up on production incidences emphasis on prevention KPIs to reduce incidences metrics are tracked and managed by platform - network/server by application/channel - e.g. internet banking by business unit - retail, corporate etc by location - ATM, branch, country, region root cause of incidences is 80-90% due to poorly managed changes command centre only authorized personnel Technology Call Centre Operators First-level Investigators metrics/trends/dashboards are displayed on large video screens First-level Investigators escalate to Second-level Specialists bank-wide outages are managed from command centre Infrastucture 1. Platforms - like in DC engineer redundant systems (no single point of failure) Active-active, load-balanced session replication, DB replication system maintenance OS patching/upgrades DB patching/upgrades OS and DB performance tuning 2. Networks engineer redundant networks (no single point of failure) Active-active switches/routers/firewalls Active-active WAN circuits from multiple providers Digital banking enterprise architecture 5  ISDN backup for lease circuits (e.g. branches, ATMs) network maintenance switch/router/firewall patching add/modify firewall rules setup MAC filtering on Wifi access points preventive maintenance of LAN switches/cables disaster recovery planning and testing DR site required to be at least 10km away from Production normal operation replication over to DR in near realtime - asynchronous testing regulator requires all banks to perform DR testing once a year over one night 1. swing the network from Production to DR (disable Production site) 2. staff makes live transactions which hit the DR site - verify transactions 3. swing the network back to Production 4. verify transaction from testing are replicated from DR to Production 2. grow the bank solution development lifecycle Digital banking enterprise architecture 6  1. business strategy 2. solution ideation 3. business case development 4. project funding 5. project implementation 6. deployment front, middle and back office enterprise platforms (main subject of the course) WHERE - within SOA layered architecture, in the middle layer and implements all of bank’s business logic, processing logic and business rules WHAT - includes ESB, BPM, BRMS, MDM, EDW (technically not middle layer) HOW - standards-based, GUI-driven designer tools enable rapid assembly of new solutios by reusing existing software components WHO - centrally managed by platform specialists (support bank’s solution requirements), includes Solution Architects, Business Analysts, Project Managers, Developers, Data Analysts WHY - flexible architecture can accelerate time-to-market of new innovative digital solutions and compete with non-bank FinTech alternatives operations centres (back office operations) - functions Loan Ops, Credit Card Ops, Payment Ops, Trade Finance Ops transaction fulfilment processes that include humans (not fully automated) e.g. corporate loan credit evaluation process review firm’s management structure and character and review firm’s industry outlook gather financial reports and compute financial ratios (e.g. working capital, debt to equity) analyze cash flow from operations, investments and financing project borrower’s financial condition based on sales, payable and notes payable to banks Digital banking enterprise architecture 7  classify risk level and submit loan proposal for approval supported by business process management (BPM) engines, which execute end-to-end wokflow of long running processes bank-wide tech & ops initiatives (back office) 1. Data centre consolidation no of bank’s DC increases over time due to merges & acquisitions operating many DC is costly - aim to consolidate and reduce most banks have ongoing initiative to reduce no of DC careful planning required to not disrupt banking operations steps assessment → strategy/planning → migration → post-migration 2. Regional operations hubs similar to DC, back-office operations also consolidated into “hubs” Trade Finance Ops e.g. might be set up in 1 location to provide cross-border support for entire region benefits 1. reduced operating cost due to better economies of scale and low-cost locations 2. standardized operation flows and procedures 3. Business process re-engineering (BPR) Digital banking enterprise architecture 8  focuses on reducing end-to-end cycle time, reducing error rates of a bank’s core business processes occurs before BPM BPR is an ongoing activity and collaboration between BPM specialists and operation specialists process data collected by the BPM engine is analyzed for inefficiencies and process is improved/re- engineered BPR can be applied to any area (front/middle/back office) 4. BASEL Compliance banks operatin in SG required to measure their risk exposure to counterparties and assets - in terms of Risk Weighted Assets (RWA) in order to satisfy Capital Adequancy Ratio (CAR) requirements lower RWA (risk weighted asset) means lower overall risks RWA must be reported to regulator every month BASEL requires bank-wide technology and operations involvement if minimum CAR met, banks will have more Eligible Capital for investments else they need to set aside for Reserve Capital note - to measure their overall credit risk → exposure to customers not paying off their loans 5. Internal Audit each function with Technology & Operations (back office) must pass a yearly internal audit internal auditors are dispatched from Middle Office compliance function each audit conducted over 4-6 weeks audit report up to 100 pages, and details exceptions only types of audits Tech audits - focus on Information Security and Standards compliane Digital banking enterprise architecture 9  Ops audits - focus on process compliance internal audits done in preparation for central bank audits 6. Central Bank Audit each bank’s tech and ops must pass a periodic external audit from central bank scope and frequency of audit depends on past audit performances poor audit = more frequent audits failed audit = penalties (include fines or a higher reserved capital requirement) note: for person in charge, failing one of the audits, can be a career limiting event enterprise architecture purpose align business goals and technology needed to support those processes to achieve goals best means of communication and connection across stakeholders and the technologists - drive consensus helps planning, building, modifying, deploying, maintaining IT assets improve competitive advantage EA does not sell purely on its own merits EA must have commercial impact - achieved by reducing costs and waste (resuse, risk reduction, optimization, improve security, improved compliance) increasing revenue (speed to market, product & service innovation, improved interoperability) EA in banking - why do banks need EA 1. roadmap for integrating and modernizing bank systems - making it more adaptable (banks have diverse range of systems and applications) 2. streamline processes through automation and standardization - reduce operational costs and increases efficiency 3. EA helps design banks infrastructure and systems that allows scalability and flexibility (help in adapting to changing customer and market conditions) 4. help manage complexity of organizational change - EA provides structured approach, helping to minimize disruptions result in increase revenue reduced expense EA responsible for ensuring best practices are in place for measuring and reporting success (financial benefits) EA’s value is quantified through benefits realization concepts architect’s sphere of influence Digital banking enterprise architecture 10  effective enterprise architect has a large sphere of influence and has direct impact on strategy outcomes 1. enterprise architect highest scope (organization) low detail (broad) high impact (strategic outcomes) large audience - all 2. segment architect medium scope (line of business) medium details medium impact (business outcomes) audience - business owners 3. solution architect lowest scope (function/process) high detail (specific solutions) low impact (operational outcomes) audience - users and developers architect’s varying degrees of depth/breadth across 4 architecture domains 1. application 2. technical 3. information 4. business enterprise architect skill set Digital banking enterprise architecture 11  architect’s role in product/IT lifecycle distinctly different from Solution Architect EA specialization typical EA group will have specialists covering a specific technology disciplines they set direction across the entire enterprise, for their discipline example engagement model, SOA what are enterprise platforms 1. SOA (ESB) Digital banking enterprise architecture 12  SOA, loan origination example 2. BPM process model defines business processes using BPMN models are stateful with the process state being persisted to the db at runtime specifies participants to assign work to (using organizational model) and services to interact with page flow model user interaction process that defines a sequenced set of screens that process participants interact with each screen is a form that is represented using form model lightweight, stateless (non-persistent), can execute very fast services can be invoked from within a page flow e.g. to validate information entered by a user against an application before continuing with page flow Digital banking enterprise architecture 13  form model employ design palette to graphically design, view and test forms to process participants forms can be generated from activity data to enable rapid development process participants interact with these forms when performing work is platform independent to support rendering in different presentation technologies data model (business object model) business data is modeled using UML, allowing users to define a vocabulary of core business objects abstracts business data from process models - encouraging data model reuse across processes can be generated from the WSDL of existing services or generate WSDL to drive service implementations organization model Digital banking enterprise architecture 14  enables model-driven work distribution by allowing processes to assign work based on an organizational model that defines organization structure and attributes structure of an organization is key in the behavior of business processes and how people perform work 3. BRMS - rules 4. MDM - master data management? reference data is USED by an organization supports lookup tables - map descriptions to codes e.g. Singapore = SG master data is PRODUCED by an organization static data (rarely changes) not transaction data MDM can support both realtime and batch modes 5. EDW - enterprise data warehouse Digital banking enterprise architecture 15  job roles in a bank job roles front office branch teller, relationship manager, financial advisor, call center middle office credit risk officer, compliance officer, internal auditor, market analysts, financial accountant, info security specialist back office operations operations officer enterprise platforms solution architect, project manager, business analyst, data analyst technology BAU data centre specialist, platform engineer, network engineer, incident and change management specialist, DR specialist technology solutions (systems) SA, PM, BA architect roles 1. enterprise architects - set bank-wide architecture direction & bridge gap between silos 2. segment/domain architects - provide architectural guidance and consulting within their business units Digital banking enterprise architecture 16  3. solution architects - develop a detailed solution architecture for a single system/application job ranks work environment week 2 - digital banking channels recap concerns with data center - security, availability (scale of entire data center, no single point of failure for entire infrastructure that keeps data running) infrastructures include: air-conditioning, network cables, input power network environment: development, testing, network etc why developers are not given access to production: they could change and give illegal code changes managed change: production systems, firewall rules, performance tuning, OS patching change team has access to all platforms high availability - application scope - e.g. application server, database how to ensure? horizontal scaling multiple instances of the application server - session replication between them, database servers - above is a load balancer if any side goes down, there are other servers running this vs DR DR scope - entire datacenter activate it when entire datacenter goes down, not when an application goes down Digital banking enterprise architecture 17  infrastructure specialists platform group and network group platform: takes care of infrastructure network: firewall, wireless router etc common objective - ensure no single point of failure enterprise platforms biggest - enterprise most detailed - solution questions What are the 4 different types of bank customers? retail, corporate and institutional, private banking and investment and capital What is meant by the terms: Front Office, Middle Office, and Back Office? front office - client facing middle office - handles risk and bank transactions, compliance back office - operations and technology What is meant be the terms: “Run the bank”, and “Grow the bank”? What are the objectives/concerns with operating a Data Centre? no downtime, operational efficiency What are the different Network Environments in a bank? How are changes managed? How are incidences managed? changes have to be approved by change management team - ensure minimal interruptions when implementing change incident management - more focus on prevention, restoring of service asap What are the main objectives of Infrastructure specialists? monitor infrastructure, do necessary patching What is Disaster Recovery? How does it work? Testing? What is the Solution Development Lifecycle? Who does what? solution development lifecycle 1. business strategy - CXO & EA 2. solution ideation - Business head & segment architect, business analyst 3. business case development - business analyst & SA 4. project funding - management committee & business head, CFO CEO Digital banking enterprise architecture 18  5. project implementation - project manager, SA, tech and solutions specialist 6. deployment - change management team, tech, infra, specialists What are Operations Centres? What do they do? transaction fulfilment processes that include humans (not fully automated) What is Data Centre Consolidation? Regional Operations Hubs? DC consolidation - when there are too many DCs by mergers and acquisitions for e.g., reduce redundant DC and lower costs regional operations hub - back-office operations also consolidated into “hubs” - e.g. set up in 1 location to provide cross-border support for entire region reduced operating cost due to better economies of scale and low-cost locations standardized operation What are the different Architect roles? What do they do? solution architect, enterprise architect, segment architect What is a “Spaghetti Architecture”? What problems arise? SOA architecture too many channels, hard to integrate, identify etc What are the 3 main layers in an SOA Layered Architecture? presentation, business and data layer? What are the 5 Enterprise Platforms that we covered? BRMS, EDW, BPM, SOA, MDM How do Enterprise Platforms help banks? integrating bank systems - make it more adaptable streamline processes through automation and standardization allows scalability and flexibility help manage complexity of organizational change reduce cost, increase revenue competitive advantage - don’t need to buy solutions can reuse certain platforms core banking system contains customer banking information, accounts etc can become legacy system easily as more new tech is evolving and more high-tech solutions are being created Finacle - universal banking solution Digital banking enterprise architecture 19  credit bureau - there will be a time for all banks to send in their customer loans details, to see which other banks they are loaning from and checking if they are making their payments on time ACH - handles settlement - central bank Flexcube - core banking solution Polaris encore solutions - universal banking review - core banking systems what features they have in common what are unique why would a bank include core banking system as part of its architecture legacy systems - know it is always working Digital banking enterprise architecture 20  why would a bank decide not to include a core banking system as part of its architecture what features of core banking system can be implemented separately legacy - not updated to the latest technology digital banking - open banking ecosystem want things automated, on cloud but there are a lot of integration with third parties why is it useful to integrate with fintech - functionality, capability, services integrate with nonbank entrants - they provide data channels technology channel - enables banks to deliver products and services can be self assisted or self service branch, ATM, Fax, Internet, call centre, email etc enterprse evolution 1. enterprise 1.0 data processing - in batches transaction over the counter 2. enterprise 2.0 client server - database transaction over online channels - 24/7 3. enterprise 3.0 predictive - ESB event driven - realtime - opportunities and threats preferred banking channels growing preference to mobile apps Digital banking enterprise architecture 21  cost of operating banking channels transition towards electronic self service channels is driven by lower operating costs greater geographic diversification improved or sustained competitive position increased customer demand new revenue opportunities transaction cost increasing for call centres - low online costs channel implementation considerations 1. basic cost of operation considerations technology, communications, personnel integration cost with legacy systems cost of migrating customers over - not a bigbang approach 2. skill sets for implementing new architecture 3. higher level of IT compliance and audit for newer technology 4. enhanced security requirements, 2FA - biometric 5. expansion of time and geography also needs backup staffing - e.g. 24x7 banking, remotely used services 6. continuous monitoring of costs and effort in evaluating channels 7. has to be part of a competitive strategy potential increase in revenue, and losses from fraud opportunity costs of investing in channels vs other business initiatives appropriateness of channels for product/service suit realtime event-driven (more agile in service delivery, more predictive) key is to make informed decisions faster Digital banking enterprise architecture 22  opportunities & threats competitive forces drive better event processing enterprise platforms which enable real-time marketing 1. enterprise service bus (type of SOA pattern) Digital banking enterprise architecture 23  ESB is an SOA design pattern - represents a collection of reusable services technology vendor tools include a GUI-driven designer for development and testing services services must be designed and deployed managed by one central team 2. BPM/channel integration (layer) Digital banking enterprise architecture 24  3. operational data store (ODS) Digital banking enterprise architecture 25  4. business rules management system (BRMS) Digital banking enterprise architecture 26  layered architecture for real-time marketing channel layer/BPM BRMS ODS - in-memory data grid ESB how can banks differentiate from each other its on service - fast key is to make informed decisions faster avoid threats and fulfil needs - happen in real time CRM Digital banking enterprise architecture 27  CRM cycle steps development & offering sales superior experience retention & win-back targeting and marketing positioning CRM tools Targeting & Marketing → Client Serving information Development of Offering → Sales Management Sales → marketing models Superior Experience → client centric document repository Retention & Winback → client centric business intelligence business silo-oriented channel architecture Digital banking enterprise architecture 28  multi-channel architecture channels, CRM and BI inter-relationships yes → BRMS (includes customer next best offer) BRMS provides centrally managed business rules ”externalized” from the processing logic within channel applications Digital banking enterprise architecture 29  exposed via the ESB as Decision Services examples customer next best offer truths about CRM banks traditionally product centric, but competition drove them to be customer centric main function of CRM is marketing - revenue oriented all banks have CRM discipline - even if they dont use CRM tool advantage of CRM discipline - visibility of a customer across the bank CRM tools have good retail banking verticals, but not for corporate/institutional segments As a solution architect, what would you recommend for a CRM solution case study (payments channel) account switching for inward remittance Digital banking enterprise architecture 30  CRM - customer relationship management purpose: to sell things to customer assemble the CRM solutions using enterprise platforms enterprise service bus - collection of services is a way to capture the event to sell to customers CRM is not an enterprise platform week 3 - SOA in banking (enterprise platforms) recap questions What is a channel? What channels are used by banks? used to deliver service and interact with customers channel (for banks to reach out to others) call centres, branch - assisted channel selfservice channel What are the Enterprise 1.0, 2.0, and 3.0 eras? Impact on channels? enterprise 1.0, 2.0 (24/7 banking, internet access, 24/7 uptime information security, 3.0 (predictive, offer personalized services, capture realtime events) era effect on channels - call centres → decreasing presence due to increasing online presence Which channels are increasing in presence? Which are decreasing? online channels like mobile banking, social media is increasing, branch banking and telebanking is decreasing What are some challenges/implications of implementing channels? challenges - diff skillsets → info security, bank needs to worry abt security, banks business perspective → consider which products to focus on? What are some actionable business events? Opportunities? Threats? opportunities - visit website, making purchase, any interaction with customer threats - competition, event needs to trigger some action, banks need to know the realtime event → late payment, alert the bank, increased risk, unusual transactions, trade that does not make sense - could be fraud, could indicate money laundering What are some enterprise platforms which enable realtime marketing? realtime marketing - sending personalized marketing → enterprise platform: ESB, BPM, business rules?? enterprise platform - tool that you buy from a vendor that allows u to develop solutions → leverages reusable assets → services/processes/business rules that are alr running in production can be multi-purposed → build any solution in the bank not CRM → it is a solution you assemble using enterprise platforms solution is never multi-purpose (for a specific problem) CRM is targeted What is CRM? Is it a system or a discipline? How is CRM used in banks? Digital banking enterprise architecture 31  can be both? provide personalized service to customers cross sell to customers What are the implications of buying a CRM system off the shelf? implication of CRM off the shelf vs using enterprise platforms (EP) limited customisation CRM has to be integrated to system where customer data exists → huge architectural challenge Is a commercial off-the-shelf CRM system an enterprise platform? no it is not - it is part of an enterprise platform? Which enterprise platform could execute the business logic of CRM? BRMS Which banking channels did you use in Lab 1? internet banking and bank teller In SMU tBank, which layer of the architecture contains the business logic? contains business logic → middle layer → contains the enterprise platforms bottom is data layer top is channels? After your lab session, which statistics of service usage were shown using the SOA Governance tool? Understand the value of Service-Oriented Architecture (SOA) in Banking evolution of banking architecture DBS (centralized) still using IBMA frame? - regulated - use industry standards transfer old to new system - huge risk, replacing core banking system → most important system, cant have any unscheduled downtime migrate and replace legacy system SOA comes into play → to wrap over their core banking systems set of services to wrap the core functions using legacy protocols below wrapper above wrapper - channels using web services easy to integrate services → using web services channel does not know core banking system exists, all u need is the wrapper service evolution of SOA in banking before Digital banking enterprise architecture 32  each line represents an integration - spaghetti architecture point solutions if alot becomes unmanageable if one breaks, other integrations may be affected - hard to find out root cause to fix it if engineer leaves, if documentation not done properly, hard to fix it engineer from different teams exchange protocol, suggest how data can be exchanged, core systems, formats needed, document create new interfaces to link them up core banking systems - hard for banks to implement SOA, high risk after SOA wrapper service documented → can search up and just call the single wrapper service centralize team that manages ESB all the domain knowledge about the integration managed only by one team Digital banking enterprise architecture 33  able to identify issues quicker vs before managed by one team only easy to isolate problems and fix them assemble service for many applications e.g. account balance → is one end point, reusabe for other applications teller, ATM machines, call centre, mobile banking → resuing the same service, dont need to build it again just assemble that endpoint into ur application can just assemble it dont need to buy off shelf note: CANNOT buy ESB off the shelf, collection of services that u build n deploy collection of reusable services SOA motivation 1. reducing costs consolidate redundant application functionality and decouple functionality from obsolete and increasingly costly applications while leveraging existing investments 2. agility structure business solutions based on a set of business and IT services - to facilitate the rapid restructuring and reconfiguration of the business processes and solutions that consume them 3. increasing competitive advantage provide opprotunity to enter new markets and leverage exisiting business capabilities in new and innovate ways - using a set of loosely coupled IT services potentially increase market share and business value by offering new and better business services 4. time to market deliver business-aligned solutions faster by allowing the business to decide on key drivers of a solution and allowing IT to rapidly support and implement that direction 5. consolidation integrate across silo-ed solutions and organizations, reduce the physical number of systems and enable condolidation of platforms under a program of “graceful transition” from legacy spaghetti dependencies to a more organized and integrated set of coexisting systems Understand the role of the Enterprise Service Bus (ESB) - is an SOA pattern ESB Digital banking enterprise architecture 34  architectural approach to exposing business functionality as reusable services services exposed via an ESB - not point-to-point ESB - collection of reusable services SOA as an enterprise platform independent construction of services which can be combined into meaningful, higher level business processes within the context of the enterprise describes several aspects of services within an enterprise granularity and types of services how services are constucted how services communicate at technical level how they are combined tgt - orchestrated how services interoperate at a semantic level - share common meanings how services contribute to IT and business strategy SOA benefits 1. integrate once, connect many Digital banking enterprise architecture 35  2. adaptability to change 3. incremental approach SOA design considerations key to effective design, usage and evolution of SOA correct design solution element selection and combination modelling of services governance interoperability ability to identify different components architect needs to answer questions such as how can SOA solution be organized as an architectural framework with inter-connect architectures and transformation capabilities SOA to be designed - maximizes asset reuse automated tools take the guess work out of architecture validation and capability planning underlying requirements - determine the capabilities that SOA supports are determined by 1. set of service requirements 2. service requirements result in the documented capability that a service needs to deliver or is expected to deliver 3. provider view of a service requirement is business and technical capability that service is expected to deliver in the context of all of its consumers 4. consumer view of a service requirement is the business and technical capability that the service is expected to deliver in the context of that consumer alone fulfillment of any service requirement may be achieved through the capabilities of a combination of layers in the SOA reference architecture SOA reference architecture (TOGAF) Digital banking enterprise architecture 36  viewed as 5 horizontal layers 1. consumer layer potral to loan processing application 2. business process layer intiation of loan processing application 3. services layer services required to support the loan processing application 4. component layer software componenets that need to be built that support the realization and implementation of the services 5. operational systems layer actual runtime environment in which the components, legacy systems, all back-end applications and packaged applications reside and run 4 cross-cutting vertical layers (applied to and supported by each of the horizontal layers) 1. integration layer platform integration (protocols support), data integration, service integration, application integration, leading to enterprise application integration supporting B2B and B2C 2. quality of service security, availability, performance constitute the quality of service parameters which are configured based on required SLAs, OLAs 3. informational provide business information 4. governance IT strategy is government to each horizontal layer to achieve required operating and capability model Digital banking enterprise architecture 37  TOGAF - The Open Group Architecture Framework SOA, loan origination example SOA layers - operational systems 1. operational systems layer (most bottom) layer captures the new and existing organization infrastructure, including those involving actors, needed to support the SOA solution, includes all infrastructures to run the SOA and its components all operational and runtime hosting of underlying systems components, both physical and infrastructural all assets required to support the functionality of the service in the SOA, including custom of packaged application assets, new services, services created through composition or orchestration, infrastructure services etc softwre systems are part of this layer existing monolithic custom applications legacy applications and systems existing transaction processing systems, databases, package applications and soluions including ERP and CRM core banking systems 2. service component layer contains software components - provide implementation or “realization” for a service, or operation on a service provides an enforcement point for ”faithful” service realization (quality and SLA) enables business flexibility by supporting the functional implementation of IT flexible services, their composition and layering IT flexiblity by strengthening the decoupling in the system - decoupling achieved by hiding volatile implementation details from consumers note: what defines a REST service - not WSDL→ but a schema that defines R&R details defines service schema for REST service - Swagger 3. service layer (atomic and composite) Digital banking enterprise architecture 38  consists all services within SOA - contains service descriptions, runtime and container for implementing the services service components bind the service contract to the implementation of the servce in the operational systems layer Service components are hosted in containers which support a service specification service specification includes service interface specification defined by a WSDL gurantees the alignment of IT implementation with service description 4. business process layer include service orchestrations and compositions, and the ability to insert “human intervention” and support long-lived transactions data flow and control flow - enable interactions information exchange flow between paticipants, resources and processes business logic used to form service flow as parallel or sequential tasks lifecycle management for business process orchestration and choreography all aspects of composition, collaboration, compliance, process library, process service and invocation elements 5. consumer layer provides capabilities required to deliver IT functions and data to end-users that meet specific usage preferences interface for application to application communication provides the capability to quickly create the front end of the business processes and composite applications to response to changes enables channel independent access Enterprise Service Bus and Benefits of service reuse SOA - ESB (SOA pattern) Digital banking enterprise architecture 39  MDM - underpin the ESB SOA - ESB conceptual architecture customer facing endpoints - SOAP/REST JMS to transport messages between service components adapters provide transport protocol bridging at consumer side or provider side provider-facing endpoints conform to provier system’s API, message format BIAN service landscape Banking Industry Architecture Network (BIAN) smu tbank service design is guided by BIAN service definitions Digital banking enterprise architecture 40  BIAN & ESB BIAN service operations as a canonical (conforming to a general rule) service directory BIAN service domains - define a discrete, non-overlapping business capability BIAN service operations - define unique non-overlapping business services the complete collection of service domains and their service operations can be used to define a comprehensive, canonical business service directory with discrete/non-overlapping services for the ESB note: service operations do not include message-level details unplug these systems → all you have left is reusable services that contain data defines a finite set of service domains logical business applications are assembled from collections of Service Domains steps 1. BIAN defines collection of Service Domains that may be used in any bank 2. the collection of Service Domains and their associated Service Operations define the ESB service directory 3. the ESB services are mapped to the core host systems Microservices SOA and microservices architecture Digital banking enterprise architecture 41  if banks implement these collection of microservices - time to market will increase, will become more adaptable microservice - smu tbank journey steps 1. migrate business logic and data 2. unplug core banking system 3. map channels to microservices web services - SOAP vs REST SOAP (Simple Object Access Protocol) REST (Representational State Transfer) is a standard is an architectural style can use any transport protol like HTTP, FTP can only use HTTP transport protocol Digital banking enterprise architecture 42  uses service interfaces to expose business logic uses URI to expose business logic standards to be strictly followed does not define much standards requires more bandwidth and resource than REST requires less bandwidth and resource than SOAP REST web services inherits security measures from the underlying defines its own security transport permits XML data format only permits different data formats e.g. XML, JSON more appropriate for ESB implementation within an more appropriate for external uses betwee different enterprises enterprise REST - http - data format can be XML, JSON SOAP schema- wisdol - defines schema of a SOAP message SOAP can be under a messaging protocol - AMQP when use message queues, they gurantee deliver - banks like this SOAP appropriate for within banks REST appriopriate use between banks and external parties week 4 - enterprise platforms: SOA - service mediation, ESB framework, SOA governance recap What role did SOA play in the evolution of banking architecture? Before SOA? After SOA? before - hard to integrate, deploying is easy but hard to isolate problem after - easy to integrate, can identify source of problem, service modularity - expose services independently Why is transitioning to SOA so difficult for banks? hard to migrate services, takes a long time to fully implement - significant organizational changes and reengineering legacy systems have been in place forever migrating might disrupt services What are the benefits of SOA which banks hope to achieve? efficiency, cost savings, easier to integrate and reduce redundancy faster time to market interopeability - enables different services to communicate easily even if using different systems reuse set of services for different business applications What is an Enterprise Service Bus? is an SOA pattern - acts as a hub which services can communicate and route messages help in service orchestration How does it benefit banks to follow a standard SOA reference architecture? Which organization published a popular SOA reference architecture? TOGAF What are some of the layers in this standard SOA reference architecture? operations, service layer, service component, business layer and consumer Digital banking enterprise architecture 43  integration, governance, quality of service, informational How might a bank benefit from adopting the BIAN Service Landscape? standardization - helps banks to get the basic services down What is a microservice? a single service that performs a specific business function independently What is a collection of microservices? work together to perform a functionality of the application If all a bank’s functionality can be implemented by a collection of microservices, then what can the bank do? What would be the benefit? independent scaling faster developments flexibility Why is SOAP appropriate to use within the bank? highly secure always AMQP - messaging Why is REST appropriate to use between the bank and external parties? uses HTTP which is widely supported easy to implement and suitbale for communication with external parties Understand Service Mediation and ESB Framework SOA layered architecture ESB without service mediation how to control which consumer (channel) should invoke which service ESB with service mediation Digital banking enterprise architecture 44  service mediation - provides run time control of service usage helps you transition from an older monolithic core to a more modern core system (make changes in backend systems without touching the frontend systems) service mediation - exposes a single RR web service load balanced across 3 instances each instance supports 8 threads DB contains mediation mapping invokes the desired service according to the mapping service mediation mapping logic service consumers → service mediation → service endpoints service mediation design trade-offs Digital banking enterprise architecture 45  with service mediation apps connect to single endpoint access controls centralized service deployment more complex single point of failure without service mediation apps connect to multiple endpoints access controls implemented in each service service design more complex failure isolated to specific services service mediation all services support both SOAP/JMS and SOAP/HTTP endpoints services can be SOAP 1.1 or 1.2 compliant logging points 1 and 8 capture requestand response service mediation - channel mapping SMU tbank governance tool design-time governance - for sharing service specs among developers run-time governance - for controlling and monitoring service invocation message logging Digital banking enterprise architecture 46  message logging - enables reporting of runtime service usage log report buckets on the fly support snapshots: HOURLY, DAILY, MONTHLY, YEARLY captures: service operation, consumer ID, timestamp computes response time on the fly sample of reports derived from messsage logs Understand API Gateways SOA layered architecture API gateway - enables cloud-based access from channels and non-bank FinTechs layer of security to protect from the outside access, can also be used internally for the banks channels - external customer facing channels and bank’s internal channels Digital banking enterprise architecture 47  supports Open API Open API architecture - API gateway Account Info and Payment Intiation services are exposed to TPP via an API gateway many banks are following the Open Banking Standard SMU tbank API architecture (legacy) port 443 and 80? - is the API gateway one that you use to talk to the outside world SMU tbank architecture (outsystems) no need for load balancer as Outsystems instance has enough capacity service mediation - outsystems proxy service SMU tbank API documentation & demo - should i learn more Digital banking enterprise architecture 48  LGB Case Study LGB Bank is large global bank headquartered in New York, with a large regional presence in Asia. Over the years, LGB has been aggressive with their business and now have grown to a leading bank which provides the following banking services: Retail Banking Checking and savings accounts, Fixed deposit accounts, Mortgages for residential and investment properties, Auto financing, Credit cards, Foreign currency and remittance services Corporate Banking Loans products, Treasury and cash management services which provide services for businesses to manage their working capital and currency conversion requirements, Commercial real estate, Trade finance Private Banking Institutional Banking LGB current IT architecture spaghetti architecture in the middle - whats wrong with it Examine LGB’s current IT architecture, and 1. Identify the key issues with the initial architecture 2. Suggest how this architecture can be improved using SOA. 3. Going forward, LGB must add additional channels such as Retail Internet Banking, Corporate Internet Banking, Mobile Banking, etc. Draw the diagram of a proposed architecture using an ESB, applying a layered SOA architecture as illustrated on the next slide. For simplicity, you can combine the Long Running Process, Straight Through Process (Composite Services), and the Atomic Services on ESB into one layer. 4. Justify how it is flexible to accommodate new back-end applications and front-end channels. enterprise service bus (ESB) - SOA pattern Digital banking enterprise architecture 49  Bottom – systems (legacy) > wrapper service > atomic microservice (owns its own data – its an end pt doesn’t link to anyth else) > composite microservice (strings tgt in a sequence, calls atomic and wrapper services in realtime ) > LGB bank case study - release part 2 Digital banking enterprise architecture 50  To allow authorization for some channels to have access to endpoints and others not. Have to build logic in all different services in the ESB area to allow channels to have this authorization logic. A lot of systems will be impacted and have to be managed to implement this service. Examine the Phase 1 architecture and answer the following: Digital banking enterprise architecture 51  1. How do you control which consumer should invoke which provider service? 2. What would be the impact of changing a service’s interface? 3. Where do you log service invocation? 4. How do you control the loading on a highly reused service? LGB bank case study - release part 3 mapping - controls routing SOAP/JMS - messaging broker → guarantees delivery routing controlled by service mediation → channel POV doesn’t know if its calling service 1 or not, but doesn’t need to know service mediation will return some errors - if channel is not mapped LGB bank case study - release part 4 Digital banking enterprise architecture 52  Short term solution: Add more instances Auto scale according to demand – put logic in HLB -> but its by vendor just plug it in (but this takes time to come up with autoscaling thing) LGB bank case study - release part 5 Digital banking enterprise architecture 53  analysis 1. What are the shortcomings of LGB Bank’s short-term fix? 2. What would happen if Mobile Banking volume increased? 3. What would be a good long-term solution? long term fix implement SOA governance - runtime policy management product configure SLA’s and prioritization of services, enforced at runtime quiz D - prioritization Composite Services: Assembling higher level business logic?? SMU tbank transition to microservices Digital banking enterprise architecture 54  SOA governance enables organizations to provide guidance and control of the SOA initiatives Digital banking enterprise architecture 55  how does this relate to IT governance 1. technical mechanisms - SOA technology management a. design time management - help manage the service from design to deployment policy management - create and manage policies with respect to SOA artifacts (access control, performance, service levels) registry/repository - manage metedata related to SOA artifacts design, testing and deployment - service modeling, dependency tracking, deployment etc for the SOA artifacts b. run time issues more no. of moving parts in the IT environment different business applications are dependent on one or more of the services different services have one or more dependent clients business applications might interact with services that you organization don’t directly own or control business executives are now directly concerned with the day-to-day functioning of the services operational problems will immediately translate into business loses critical to measure the business health of the system and ensure that IT objectives are aligned with business goals SOA management system must help address solutions ensure service-based application performs as established by development teams measures to boost performance and availability upfront receive alerts when problems measures to resolve mitigate known problems automatically collect data to pinpoint the problem and enable fastest resolution and help plan resource allocation 2. organizational considerations SOA - Centre of Excellence (CoE) Digital banking enterprise architecture 56  benefits from reuse shortened time to market for new major business intiatives through reuse of existing services reduced development costs by writing less code reusability challenge 1. how to design for future usages 2. insight is required when conceptualizing a service evolutionary changes (organic growth), revolutionary changes (new markets, buying you competitor) these changes challenge existing functionality 3. not every interface should be a service must demonstrate potential for reusability services identified by projects functionaity in a business process is identified by the project team as being potentially reusable project team does not generally have the breadth of experience or charter to evaluate the proposed service scope and feasibility of reusability needs to be determined if project team is narrowly focused on project needs where does this broader perspective come from who funds the effort to broaden the functionality into a service SOA COE - evaluates service proposals formation of SOA centre of excellence is key to the success of SOA initiatives SOA CoE objectives 1. achieve cost avoidance - reuse of existing assets, business services 2. ensure new business service designed for optimal reuse 3. manage all engagements between projects and delivery centres - to ensure optimal reuse of assets 4. achieve faster turn around and more accurate project cost estimations - leveraging SOA CoE resources 5. ensure alignment to policies, principles, design patterns and technology standards SOA CoE functions SOA CoE oles Digital banking enterprise architecture 57  example - engagement model, mapped to SDLC standards, guidelines and processes service life cycle SOA CoE enforces the service life cycle service catalogue Digital banking enterprise architecture 58  service dashboard production support runtime log viewer support testing problem investigation support website infrastructure setups login ids https ports deployment EAR map S/W configuration service testing Digital banking enterprise architecture 59  decide how to measure reuse no industry standard metrics for reuse - each organization must decide how to calculate reuse up front, then stick with it and report against it typically 2 types of metrics are used 1. reuse rate reuse rate = # of services with > 1 interface / # service 2. reuse ratio reuse ratio = # interfaces / # of services how to succeed with SOA reuse everything - cost avoidance (quantifiable benefit to demonstrate value to business and IT) measures + reports success 3 steps to measurement culture 1. service delivery cost estimations provided to PM’s to include cost avoidance due to reuse of existing services 2. business case papers include cost avoidance due to reuse of existing services 3. governance is in plance that will reject any business case paper that is missing cost avoidance figures will cause a measurement culture to be created overnight reporting success Digital banking enterprise architecture 60  SOA COE tracks and publishes statistics onto a dashboard available to all - includes 1. year-to-date cost avoidance total 2. year-on-year trend 3. ROI for any selected individual service 4. statistics on service reuse with success reported on a regular basis, business and IT see the benefits of integration middleware week 5 - migrating from monoliths to microservices recap What are the different components of an ESB Framework? service registry services servuce providers mapping db logging db service orchestration service bus service meditaion cahnnels What does Service Mediation do? handle communication between services in a lossely coupled manner - provides runtime control What problems does it solve? routing, service decoupling, protocol mismatch (http, soap), message formatting What are some of the features? What capability is possible? security mediation, routing, message transformation, protocol bridging What are some of the trade-offs with and without Service Mediation? with - flexibility, scalability - performance overhead and complexity without - services tightly couples, reduce flexibility - increase integration costs Digital banking enterprise architecture 61  What details about a service invocation should be in the Message Log? service name, timestamp, request and respone, status code, error, latency and processing times What type of dashboard style reports and graphs are possible? throughput, error rate reports, latency graphs, service invocation count, service health What is an API Gateway? What is its purpose? api management, routing, load balancing, rate limitng, security Where would you deploy it? What port would you use? in front of microservices port 80 (http) and 443 (hhtps) What is a Microservice? In Lab 2, what were the names of the Microservices you built? In Lab 3, what type of service did you build? What services did it invoke? How? Regarding SOA implementation What are some Organizational Challenge? Technical Challenges? cultural resistance to change, increased compelxity, alignment with busienss goals integration complexity, performnce overhead, compatibility What is Design-Time Governance? Runtime Governance? design - services designed in alignment with architectural standards and business requirements before deployment run - management of service interaction and performance during operational phase What are the objectives of an SOA Centre of Excellence? governance, standaridation, best practices, training Understand the differences between Monoliths and Microservices microservices architecture aims to decompose monolithic applications to a set of independent services → greater agility, faster development and deployment cycles, and scalability of selected functionality monoliths → cloud-based microservices monolith vs microservices Digital banking enterprise architecture 62  horizontal scaling of monolithic application scaling is expensive not suitable for cloud deployment microservices orchestration atomic microservices are building blocks - highly reusable composite microservices orchestrate multiple atomic microservices to perform a business process - less reusable Understand Microservice design considerations microservice design principles do one thing well highly cohesive, Domain-Driven Design no bigger than a squad small that it can be built and maintained by a squad working independently don’t share data stores own its own underlying data, share only via API interaction or event-based interation Digital banking enterprise architecture 63  independent release cadence loosely coupled, deploy independently design challenges process visibility ESB provides a centralized view of application process flows vs microservices-based architecture sacrifices this centralized view - distributed across services collaboration common challenge of SOA implementation - collaboration of multiple services to fulfill a larger application process documentation microservices are modular and independent - visibility of application process becomes challenging in terms of process documentation container orchestration microservices container orchestration tools e.g. Kubernetes - simplify management of container-based systems using features suchas deployment automation, auto-scaling microservice choreography publishing it through message broker - no reply back - have have the number of message being transmitted vs microservice orchestration Digital banking enterprise architecture 64  if designing a system using one network - orchestration - chattiness, more reusable because one service is talking to another at a time - no overlaps if designing a system using global networks - multiple countries - choreography - becomes less reusable, due to a lot of communication between microservices, will overlap microservices orchestration decision framework 6 collaboration factors 1. distribution across networks 2. predictability of response time 3. loose coupling (hot deployments) 4. service reusability (atomicity) Digital banking enterprise architecture 65  5. design complexity 6. runtime process visibility assessment of ability assessment of busisness needs - Danske Bank Case assessment of business needs - LGB BankCase management implications Generally, the choreography pattern is preferred when there are a few microservices involved, the microservices are deployed across the WAN, and deployment must be done without interruption. Generally, the orchestration pattern is preferred when there are many microservices involved, the microservices are deployed on a single LAN, and an immediate response is needed from the process. Both patterns can claim ‘agility’ as a benefit, although through different means. Choreography pattern enables agility because the reuse of existing microservices is not considered, due to poor atomicity; meaning agility is not hampered from having to design for and manage service reuse. Conversely, the orchestration pattern enables agility precisely due to the reuse of existing microservices. Reuse of software assets is typically an organizational challenge, rather than a technical challenge. It is our observation that organizations that are ineffective in managing software re