harmonised hub upgrade project – technical overview - · pdf fileharmonised hub upgrade...
TRANSCRIPT
Harmonised Hub Upgrade Project Technical Requirements for Market Participants – 1st October 2014
(Revised following Presentation)
2
Agenda
• Introduction
• Background
• Project Objectives
• Approach to date
• Options
• Technical Overview
• As-is
• To-be (Options 1, 2, & 3)
• Summary
• Evaluation
• Cost considerations
• Cutover approach
• Proposed timeline to project start
• Q&A’s
3
Introduction
• Robert Aherne – Project Manager (ESB)
• Eoghan Barrett – Project Executive (ESB)
• Paul Mallon – Networks IT (ESB Networks)
• Aileen Greaves – Networks IT (ESB Networks)
• Cenk Kuzucu – Lead Consultant (IBM)
• Finbarr O’Kane – Lead Solution Architect (IBM)
• Purpose of Today:
• To provide Market Participants with a more detailed understanding of the EMMA
technical requirements for each of the options evaluated to deliver a single, integrated
Harmonised Hub Upgrade Project
• This presentation is a follow on from September’s ReMCoWG meeting and the “Solution
Options Overview” document issued subsequently
4
Project Objectives
• To deliver a single, stable market messaging solution for both RoI & NI markets
to address the ongoing operational issues and independent audit
recommendations
• To ensure a fully supported solution aligned with vendor best practice
recommendations and technology roadmaps
• To deliver a solution to cater for any Smart Metering generated message
volumes and sizes (RoI and NI)
• To deliver a dual-site HA & DR solution capable of running on a 24*365 basis
• To improve the efficiency and reduce the risk of implementing MCRs
• To deliver the solution in a way that minimises impact on Market Participants
5
Approach to date
• 3 options identified
• Project approached in two stages:
• Stage 1: Scope & Design (8 weeks)
• Following competitive tender, IBM engaged to analyse and propose a solution for each option
• ESB Group objectively evaluate each proposal and put forward a recommendation for approval
• Stage 2: Build
• Implementation of recommended solution subject to acceptance and approval to proceed
6
Options Overview
1. Baseline (as-is) - required to address:
● TIBCO Audit Recommendations
● Required product upgrades (BC, BW, GI components and Oracle DB)
2. Address baseline requirements and cater for expected RoI Smart Metering
volumes and any additional growth as a result of an NI Smart Metering
programme
3. Address baseline requirements, Smart Metering volumes and consider an
alternative EMMA design
Notes:
• Scope & Design confirmed that a redesign and rebuild of the existing solution is required
to properly address audit findings, perform the necessary upgrades and ensure project
objectives can be met
• This implies a new Hub and new EMMAs for all 3 options
7
Options Overview (cont’d.)
• All three options will:
• use the same, more current and fully supported, TIBCO products designed, built and
configured to best practice
• ensure the underlying Webforms platform is replaced with a fully supported alternative
• include a number of enhancements and improvements to the current solution as a result
of lessons learned. These include:
• a single, centralised schema to:
• help simplify ongoing support and maintenance and
• improve the efficiency and reduce the risk of implementing MCRs
• the deployment of TIBCO Hawk on the Hub to pro-actively monitor, alert and automate corrective action on
core TIBCO components and
• a fully tested High-Availability and Disaster Recovery solution to maximise Hub availability and provide for
full service continuity in the event of a disaster affecting the production site
• incorporate MCR 1111 - Debt Flagging and MCR 1122 - Essential Plant
8
SAP IS-U
SAP IS-U
Market Participant
Backend System
Market Participant
Messaging Application
EMMA
Current Solution Overview
Message Validation
Market
Messaging
Hub
Message Validation
Webforms
9
Current EMMA Configs.
Large
Https 443
Corp. Proxy
Https 443
Inbound
Outbound
DMZ Server
Interior
Small
Inbound / Outbound
Https 443
1
2 3
1
Supplier EMMA Product Stack
Product Version
TIBCO BusinessConnect 5.3.3
TIBCO BusinessWorks 5.9.2
GI Enterprise Edition (Webforms) 3.9.1
TIBCO Runtime Agent 5.7.1
TIBCO Rendezvous 8.3.1
TIBCO Administrator 5.7.0
Database
10
SAP IS-U
SAP IS-U
Market Participant
Backend System
New
Market Participant
Messaging Application
EMMA
Proposal for Option 1
Centralised
Message Validation
New
Market
Messaging
Hub
Webforms
11
Small
Inbound / Outbound
Https 443
Large
Https 443
Corp. Proxy
Https 443
Inbound
Outbound
DMZ Server
Interior
Option 1 EMMA Configs.
1
2 3
1
Supplier EMMA Product Stack
Product Version
TIBCO BusinessConnect 6.2.0
TIBCO BusinessWorks 5.12.0
IBM Forms Experience (Webforms) 8.5.0
TIBCO Runtime Agent 5.9.0
TIBCO Rendezvous 8.4.2
TIBCO Administrator 5.9.0
Database
12
SAP IS-U
SAP IS-U
Market Participant
Backend System
New
Market Participant
Messaging Application
EMMA
Proposal for Option 2
Centralised
Message Validation
New
Market
Messaging
Hub
Webforms
Caters for Smart
Metering Volumes
Scalable for Smart
Metering Volumes
13
Option 2 EMMA Configs.
Large
Https 443
Corp. Proxy
Https 443
Inbound
Outbound
DMZ Server
Interior
Small
Inbound / Outbound
Https 443
1
2 3
1
Supplier EMMA TIBCO Product Stack
Product Version
TIBCO BusinessConnect 6.2.0
TIBCO BusinessWorks 5.12.0
IBM Forms Experience (Webforms) 8.5
TIBCO Runtime Agent 5.9.0
TIBCO Rendezvous 8.4.2
TIBCO Administrator 5.9.0
Database
Scalable to
14
SAP IS-U
SAP IS-U
Market Participant
Backend System
New
Market Participant
Messaging Application
EMMA
Proposal for Option 3
Centralised
Message Validation
New
Market
Messaging
Hub
Caters for Smart
Metering Volumes
Scalable for Smart
Metering Volumes
• Manually create, upload/download messages
through centralised Webforms portal using
secure internet connection
• No EMMA required
Centralised
Webforms
Webforms
Manual message
processing only
Manual or automated
message processing
15
Option 3 EMMA Configs.
Large
Https 443
Corp. Proxy
Https 443
Inbound
Outbound
DMZ Server
Interior
1
2 3
Supplier EMMA TIBCO Product Stack
Product Version
TIBCO BusinessConnect 6.2.0
TIBCO BusinessWorks 5.12.0
IBM Forms Experience (Webforms) 8.5
TIBCO Runtime Agent 5.9.0
TIBCO Rendezvous 8.4.2
TIBCO Administrator 5.9.0
Database
Small
Centralised EMMA
16
Summary
• All three options will incorporate the following core component upgrades:
• Option 2 proposes that Large EMMAs scale as required for Smart Metering – this includes
expected volumes for RoI and any additional volumes generated from an NI programme
• Vertically by adding more CPU, memory and/or disk space
• Horizontally by adding more servers
• Current comms infrastructure is expected to support all 3 options assuming a minimum
bandwidth allowance for Suppliers with larger volumes
• Full HA and DR capability can be incorporated into EMMA deployments for all 3 options
• Hard-coded IP address will be removed from EMMA configurations to simplify this
From To
Component Version Mainstream
Support
Version Mainstream
Support
Windows Server 2008 R2 Jan 2015 2012 R2 Jan 2018
Oracle DB 11g Jan 2015 12c July 2018
TIBCO BusinessConnect 5.3.3 Dec 2013 6.2.0 TBA
TIBCO BusinessWorks 5.9.2 Mar 2016 5.12.0 Mar 2018
GI Enterprise Edition (Webforms) 3.9.1 Out of Support -- --
IBM Forms Experience (Webforms) -- -- 8.5 TBA
17
Business Impact Overview
1For this option, messages cannot be created through Webforms, even with an EMMA, as Webforms will reside on the Hub
1. Moving Webforms from the EMMA to the Hub would mean a change to existing business processes for some.
2. Moving Webforms to the Hub would mean any business processes or services dependant on Webforms would be
unavailable by a loss of connectivity to the Hub for any reason.
3. Without an EMMA, messages cannot be created or retrieved automatically i.e. through backend systems and
processes. Suppliers would be required to create, upload and download all messages manually through a
centralised Webforms portal.
4. Not having an EMMA would mean messages cannot be created in the event of loss of connectivity to the Hub. For
Suppliers with an EMMA and a local instance of Webforms, messages could still be created and would be
processed once connectivity is re-established.
Option 1 Option 2 Option 3
Change to existing Supplier processes? Minimised Minimised Supplier to
Evaluate
Impact on Supplier processes/services if Hub is unavailable? Minimised Minimised Supplier to
Evaluate
Can automate message creation and retrieval? Yes Yes EMMA
Required
Can create messages if Hub unavailable or connectivity lost? Yes Yes EMMA1
Required
18
Cost considerations
Suppliers’ costs for the project will be made up of the following items:
• Hardware costs as per EMMA technical specs (Appendix A refers). Suppliers are
required to implement separate environments for live and test operations.
• 3rd party software costs for the EMMA database(s).
• Internal effort associated with EMMA setup and configuration.
• Internal effort associated with a 5 week IPT (Market Test) phase.
• Internal effort required for a weekend cutover.
Although overall costs will vary from one Supplier to another, it is expected that individual Supplier costs will be
approximately the same for all three options
19
Options Evaluation
20
Recommended approach
• Option 2 is recommended from an ESB Group perspective because:
• It meets all project objectives
• To deliver a single, stable market messaging solution for both RoI & NI markets to address the ongoing
operational issues and independent audit recommendations
• To ensure a fully supported solution aligned with vendor best practice recommendations and technology
roadmaps
• To deliver a solution to cater for any Smart Metering generated message volumes and sizes (RoI and NI)
• To deliver a dual-site HA & DR solution capable of running on a 24*365 basis
• To improve the efficiency and reduce the risk of implementing MCRs
• To deliver the solution in a way that minimises impact on Market Participants
• It is a less complex solution to deliver than Option 3
• It minimises impact on existing supplier processes
• It minimises impact on supplier processes in the event of an outage to the Hub
21
Cutover approach
Cutover is expected to include the following steps:
• The cutover will start with a freeze on all market messages
• A reconciliation report will be run at a specific point in time soon afterwards
• All Suppliers will confirm they have receipt of all messages and request resends as
required
• A reconciliation report will be run again as a final check
• When it is confirmed that all messages have been processed as expected, the existing
system will be shutdown – Hub and EMMAs
• Market systems will be pointed to the new Hub and Supplier backend systems will to the
new EMMAs as required
• The new Harmonised Market Messaging system will be brought online and begin
processing market operations subject to preliminary checks as required
Process that have started (e.g. CoS) in the current system but have not complete before cutover, will complete as
normal in the new system
22
Project Timeframe
• Because all three options require a rebuild of the Hub and all EMMA
components, as well as full market testing involving all market participants, the
timeline for each is largely the same:
• Current proposal is 43 - 45 weeks for project delivery
23
Proposed Timeline to Project Start
24
Q&A’s
• Can/will each of the proposed solutions cater for the use of hostnames/DNS aliases for configuration? Can
this be included as a requirement for the chosen solution as this would make the application much more
flexible in terms of a DR switch between sites, since no IP address updates would be required.
• Since schema validation is to be carried out “centrally” with the new proposals, how are validation errors to
be handled? The messages will have already left the suppliers EMMA. Will there be a new method of
informing the source/supplier that the message did not conform to the schema?
• On the Solution Options overview doc in section 3.2 it states that ‘a number of projections and
configuration scenarios for the anticipated volumes of data to be sent’ were the basis for the requirements
set out in this process. Can these scenarios be expanded upon? Is it just number of MPRN x 48 HH intervals
per day?
• Is Tibco the correct solution to implement?
• The recommendations, listed in the document, for the Operating System is Windows Server 2008 - is this
the version that is supported or are later versions also supported and if so what versions and has the
solution been tested on all supported o/s systems?
• What is the HUB Infrastructure?
• Can we have information on how the solution will be Stress Tested and Performance Tested to ensure it is
fit for purpose?
• What are contingency plans for Hub unavailability?
• What is the Handshake Protocol and SLA’s for Hub response to Supplier messages?
• What is the Tibco Roadmap?