1 / 52

BBL Service & Systems Management

BBL Service & Systems Management. Service Management Strategy. Background Operations (Centralised, Scalable, Automated) Service Management (ITIL Based) Manage Technology in Business Terms Investment IBM – Tivoli BMC CA. Service Management Strategy. ITIL Derived ITSM Strategy

liang
Download Presentation

BBL Service & Systems Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BBL Service & Systems Management

  2. Service Management Strategy • Background • Operations (Centralised, Scalable, Automated) • Service Management (ITIL Based) • Manage Technology in Business Terms • Investment • IBM – Tivoli • BMC • CA

  3. Service Management Strategy • ITIL Derived ITSM Strategy • Strategic Themes • Business Impact Management • Service Level Management • Capacity & Performance Management • Provisioning • Business Continuity

  4. Service Management Strategy Business Impact Management Presenting services in Business terms and not elements of technology eg Report on health/availability of FX, BPay view, LAPS, BDS etc…

  5. Service Management Strategy Service Level Management Reporting on quality and availability of SLA defined business services. e.g. the availability and user experience/response time of a business transaction

  6. Service Management Strategy Capacity & Performance Management Align the capacity of a service to meet the evolving business demands in a cost effective manner

  7. Service Management Strategy Provisioning Provide the capability to provision a given service to a customer on demand Software distribution on demand User provisioning Server provisioning

  8. Service Management Strategy Business Continuity Support the BCP process whereby we can build and manage a repository of services to support the provisioning of technology.

  9. The Mission Implement an Enterprise Systems Management Solution that delivers against the ITSM Strategy and enables a centralised, Business focussed, proactive operational support model contributing to service delivery excellence and competitive advantage.

  10. The 1st Target The HUB Enterprise Application Integration (EAI) based on a Service Orientated Architecture (SOA)

  11. EAI • Enterprise Application Integration • Addresses • the issue of “spaghetti” integration, monolithic applications with specific one to one integration paths to other applications and data sources • Information and data silos • Provides • A common interface to key applications and information sources, simplifying and consolidating application integration leading to reduced ongoing costs and the flexibility to address new requirements and gain competitive advantage

  12. SOA • A flexible, standardized architecture that enables the connection of various applications and the sharing of data. It unifies business processes by structuring large applications as an ad-hoc collection of smaller modules called services. These applications can be used by both internal and external consumers. • A paradigm for the linking of Businesses, applications, and data, in the form of services. • It provides a uniform means to offer, discover, interact with and use capabilities grouped into predefined services • Applications and data are loosely coupled, the focus is on awareness and reusability (as opposed to direct integration and specific depend ices) • The goal of SOA is to allow components of functionality to be grouped to form applications which are built almost entirely from existing software services.

  13. SOA • SOA Components • Service providerThe service provider creates a Web service and possibly publishes its interface and access information to the service registry. • The Service broker Acts as a service registry responsible for making the Web service interface and implementation access information available to any potential service requestor. (can be Private or Public) The Universal Description Discovery and Integration Specification (UDDI) specification defines a way to publish and discover information about Web services. • Service requestorThe service requestor or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services. • Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. • The services themselves are typically described by WSDL, and communications protocols by SOAP.

  14. PRE-HUB ARCHITECTURE • Each application was isolated from all other applications. • Functionality is duplicated across several applications (e.g. Funds Transfer). • Some functions require staff intervention to get data from one system into another. • Some information needs to be sent to 3rd party businesses outside the Bank.

  15. BBL HUB • A solution was required to start to rationalise this architecture and to allow BBL to fulfil certain criteria.The below enterprise architecture is described as a ‘Hub and Spoke’ architecture. All applications within that architecture (Spokes) communicate with one another through the central Bendigo Bank Hub. The benefits of this are: • Central administration, monitoring and control of messages that pass between applications. • Changes to Applications in the Spokes are minimized due to the central location of process logic • Addition of connecting applications requires that only the one connection is made to the Hub instead of connections between all applications that the new application requires connection to • The processes and their logic can be centrally monitored and controlled from within the Hub.

  16. The Method • Understand the Business Services that the HUB will facilitate • Define a high level BSV • Identify key instrumentation points • Infrastructure and Application Components • Logfile entries • Core Transactions • Compile a corresponding Systems Management Plan that leverages the Systems Management capability

  17. Systems Monitoring • OmegaMon • Operating System • MQ (Distributed and Zos) • WAS • WBI

  18. WBI MQ

  19. Hub Monitoring Situations

  20. HUB - Capacity Reports

  21. Application Performance Management • Tivoli Monitoring for Transaction Performance (TMTP) - monitors the availability and performance of Web-based services and Microsoft Windows applications from a customer’s perspective. • For HUB Services TMTP Agents are installed on the core servers and the HUB Developers have instrumented key transactions with ARM calls • Note some transactions for HUB FX are routed from existing applications (e.g. BDS) therefore the ARM correlation ID should have been invoked

  22. TMTP Architecture

  23. TMTP Listening Policies • Identification at transaction level • Ability to set performance thresholds • QoS, ARM, Synthetic Transaction and Generic Windows.

  24. TMTP Data Movement • Aggregated data (and instance data if specified) is transferred from agents to the TMTP database on the hour • TMTP data is exported, transformed and loaded (ETL) into the TDW daily • TDW data ETL into a reporting data mart and an SLA data mart daily • TDW data is aggregated and purged at various levels

  25. TMTP Console\Real-time Reports • Big Board • Dashboard • General Reports • Transactions with Sub-transactions • Overall Transaction • Topology • Page Analyzer Viewer • Slowest Transactions • Availability ** Other data mining tool (e.g. Hyperion)

  26. Historical\Trend Reporting • Tivoli Service Level Advisor (TSLA) • Other data mining tool (e.g. Hyperion)

  27. TMTP and HUB • Discovery policy identifies transaction names • Listening policies in BBLDTL for testing sign-off • Listening policies collecting production performance data, and real time events via defined thresholds • SLM – SMP reports from TDW via BRIO

  28. Event Management Tivoli Enterprise Console (TEC) • Technical core of event management Tivoli Business Systems Manager (TBSM) • Provides a simple view to the business as to the health of a Business System Unicenter ServicePlus ServiceDesk (USD) • Ticketing (Overview only in relation to integration) Automation Point (AP) • Paging and Emailing (Overview only in relation to integration)

  29. AP Reads Event Log on TEC Script run on TEC to Create USD Ticket Script run on TEC Server to forward Event to TBSM

  30. Tivoli Enterprise Console • Centralised Event Management • Rule based • Respond to events (i.e. Run Scripts) • Filter/De-duplication • Set Severities etc. • Assign appropriate CA AP group

  31. TEC Event Viewer • Received events • Attributes • Any actions that were taken • Mainly for development

  32. TEC Adapters • Monitors the Windows Event Log (Hub + AP) • Monitors log files (Hub) • Filter and forward appropriate events • Low profile • Moving towards ITM (Universal Agent) for ease of use and flexibility

  33. TEC Log file Adaptor Standards • . • Message and Field sizes • Maximum message size 1024 characters • Field sizes as prescribed in the table below and where necessary padded with zeros with a maximum of 255 characters. • Field Delimiter - Fields must be delimited by a single comma • Characters – In relation to the first five fields characters can be alphanumeric but symbols must not be used. • Required fields and field formats • LogFile Message Example • Date/Time Msg ID Summary Description • 2005/12/25 00:01:01:00,PR000001,MERRY CHRISTMAS,PRESENTS FOR EVERYONE,

  34. TEC USD • How it hooks in • TEC → USD • BB_Auto_Ticket.sh • BB_Auto_Direct.sh • USD → TEC • Notification Methods (internal USD configurations and scripting) • postzmsg • Integration related plans • Comment Logging (for when a situation has become false)

  35. TEC AP • How it hooks in • TEC → AP • Windows Event Log (Application) on TEC server (monitored from Automation Point) • AP → TEC • Windows Event Log (Application) on AP server (monitored from TEC via a TEC adapter)

  36. General Ticketing/Paging • BB_Auto_Ticket.sh • Two Events • Events are Unrelated • No USD tickets if AP is down. • Manual creation of tickets if USD was down.

  37. BIM Ticketing/Paging • BB_Auto_Direct.sh • Two Events • Events are Related • More resilient (creates tickets even if AP is down). • Logs if ticket creation was unsuccessful. • Scripted ticket creation if USD was down.

  38. TEC TBSM • Event Enablement • Event information passes both ways

  39. TBSM • What it is • Tivoli Business Systems Manager • What it can do • Model Business systems to allow for easier event management. • Business Impact

  40. Top Level View • General ‘Is it working?’

  41. Drill Down • Which parts are working

  42. TBSM – HUB FX (Components)

  43. TBSM – HUB FX (Infrastructure)

  44. TBSM – HUB FX (BSV)

  45. TBSM – HUB FX (Production)

More Related