SPlanzer
commented
7 years ago Below are the final points that required discussion and action prior to the proposal document sign off. As you see below, all points have either been actioned or deferred to the high level design.
@palmerj can you please review the doc? and when you are comfortable with it I will send the document out for review again.
JPs original feedback in black
+ My comments in green
- JPs further comments in redHi Simon,
I have reviewed the document and have the following comments:
- Please clearly define the current state problem. The issues are far as I see these are:
i. The operational maintenance role is not well defined or managed. E.g Jeremy and Chris do ad-hoc stuff to keep it going, not too many people know how the system was built or works.
+ I HAVE ADDED THIS CONCERN TO THE DOCUMENT. I have added a section “Production Support” it is
+ obviously important we do not over commit Data Services here – please review and comment. ii. ii) The server (Windows 2003) and PostgreSQL (8.4) are not well past end of life for vendor support. This cause can cause us both operational and security support issues.
+ ADDED TO DOCiii) We do not have a robust DR or BCP plan with the business owner, meaning we are at risk if a disaster occurs.
+ The proposal outlines that we will gather RTO and RPO requirements. What else is required as part of the proposal here?
- Didn’t see that it will gather those - I must have somehow skipped over that - great then.- For the avoidance of doubt I would specifically state that the DR business requirements should define a RTO (Recovery Time Objective) and RPO (Recover Point Objective).
+THE DOCUMENT HAS THE SETTING OF THESE TIME FRAMES AS A REQUIREMENT (Requirements + Section) I have spoken with Ivan. He is comfortable with the level of reference in the proposal + document to recovery. We will establish RTO and RPO as part of the high level design requirements. + This will be more straight forward in the high level design phases once data volumes are understood.
- Ok as long as DR is accounted as a business requirement in brief, of course happy that it is defined in the high level design.
- Do you think we might need some cash for the operation the new VM server and/or backup services? Unless Datacom somehow gives us a $$ credit on the decommission of the current infrastructure, then we should indicate that new on-going operating funding will be required. Maybe IS&D can help here -
+ Not sure about credit but surely money will be made available as we will no longer pay for the old
+ hardware and its support. Again is this not better suited to the high level design when we understand
+ what resources we require?
+ Does the NZGB currently contribute any costs to the database upkeep? Do I need to make them aware
+ at this stage there will be some cost to them?
- No there is no cost transfer from the SG to DS group. I would just put
- it as a risk, then it can be resolved during the HLD.-
Project Scope items. I would say the setup of backup and restore process would be another item.
+ ADDED TO DOC -
Out of scope - I would also add we will not be resolving the current IT security issue that allows the web database directly connect from the DMZ network to the production database within the Corporate network.
+ ADDED TO DOC -
In the likely R&R who will be the project management? Ivan or you?
+ IVAN – Can you please comment?
- Roles and Responsibilities. But again after talking to Ivan this should be defined after HLD, but before project initiation.
palmerj
imincik
As this project is considered extra small, it is not to be signed off by LILT as outlined in the Spatial Solution Lifecycle framework but a smaller group of key stake holders. Specifically: