Technical Architect Java

Technical Architect for Java upgrade

Description

The Technical Architect will define the approach for the Java client upgrade project.

Responsibilities:

. Document the architecture aspects required to pass the "Go-for-Execution" project milestone
. Collect inputs
. Regarding security: from Security Governance as well as from Security Officers
. Regarding applications and user impact: Key Users, Application Owners and Data Managers of the different divisions
. Regarding IT: Packaging & distribution, Helpdesk,
. Consolidate the collected information into a coherent approach (communication/migration waves/exceptions, )/scope/schedule in collaboration with the project manager
. To be able to recommend the approach, the technical architect performs a study on the upgrade of JRE on the clients:
. Make an inventory of the blocking factors, preventing the company from simply removing the old JRE version from and installing the latest version for the full installed client computers base, like p.e.

Technical

. Critical 3rd party applications not compatible with the latest JRE version
. For custom development no general solution for application signing is currently available
. Organizational:
. Incomplete inventory of applications with application owners and key users
. Pinpoint out which are the incurred the security risks, related to JRE in the existing landscape, starting from a recent preliminary study
. Categorization of cases
. Native browser JRE (exposed to the Internet)
. Applications making use of the native browser
. Embedded JRE versions in applications and platforms
. Including the applications used by development and support teams
. Challenge the current viewpoint that JRE security risks incurred at the Server Side are relatively small
. Determine which generic cases are (not) compliant with the security policies in place at the company

Remark: The parameters for the categorization are not purely technical, p.e.: cost, user impact and size of the user base can also be considered

Define the project's impact on the community of a generic application: from development (package or custom) till end-users and support

To verify some assumptions, it might be needed to perform technical tests or contact vendors.

. Definition of the risk strategy and mitigation approach
. Investigate and validate alternative risk responses (avoidance/mitigation, )
. Recommend a risk approach per category
. Remark: the mitigations can go well beyond the pure JAVA context, like working out a solution for application signing through a certificate

Define the project approach for implementation and migration

Determine the technical deliverables like: required JRE packages, required mitigation infrastructure

Define the roles needed for the execution phase 

Define the distribution strategy:
. allow users/groups to test and self-enrol the new version
. forced installation (with possibility to delay)
. Schedule: Definition of the waves such that risks are minimized
. Define a roll-back strategy
. Catch and analyse the risks related with the project approach:
. Only limited testing is considered
. Define the solution for the reporting of project's progress
. Indicate what is out of scope of the solution
. Document the "incompliances", already encountered in this phase

Skills & Previous Experience

. The Security Architect should have a firm background on JRE, JRE evolution and versions
. JRE versions and the new and deprecated features in v1.7 and v1.8
. Previous experience of JRE upgrades in large environments
. Good view on security risks related to JRE and on the possible mitigating controls
. Can work independently: takes initiatives and is persistent in chasing results
. Good communication skills: ideally in English, Dutch and French are an asset