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