Target IT Solution Delivery Model Strategy - Outstanding feedback

The Strategy: see here for the strategy that the feedback refers to.

This document will be updated throughout the elaboration of the above strategy.

Change Log

Table of Content

• 1. Document Purpose
• 2. Areas of concerns
  • 2.1. Proliferation of IT standards
  • 2.2. Managing this strategy initiative to completion
  • 2.3. Oversight on IT Product changes (PO, PM, discretionary, and technical debt)
  • 2.4. Alignment and Gap analysis with Policy and Directive (Investment & Project Management)
  • 2.5. Sustainability of skill sets
  • 2.6. Risk to enterprise reference data model and standard compliance
  • 2.7. Fit of the mainframe programme within the Strategy
  • 2.8. Legislative level and mandated deadlines
  • 2.9. How will an HR organization support the multi-skilled DevOps teams model?
• Appendix A - Archived

1. Document Purpose

To document outstanding feedback raised during the elaboration (peer reviewing) of the Target IT Solution Delivery Model Strategy.

Why?

With that many stakeholders involved in the elaboration and impacted by the strategy, two realities need to be managed:

1. Important feedback risk being lost during peer reviews; and
2. Consensus is unlikely.

During the strategy’s peer review process, important feedback that is unable to be addressed at that time needs to be tracked, so that the continuing elaboration of the strategy takes it into account. A strategy is words on a page. If stakeholders do not buy into it, things won’t change.

Consensus is unlikely as choices will have to be made in order to keep moving forward. Those choices may contradict a stakeholder’s position. To maintain transparency amongst stakeholders and to the authority of this strategy (expected to be the CIO), a list of those choices will be kept with sufficient justifications to explain them.

2. Areas of concerns

2.1. Proliferation of IT standards

2.1.1. Summary

Allowing DevOps teams to choose their technical stacks negates the principle of Standards and could proliferate technologies across the enterprise, making it more costly and risky for ESDC to sustain their long-term operations, maintenance, and sustainability.

2.1.2. Raised by stakeholder(s)

• Technical Architecture
• Solution Architecture
• Enterprise Architecture

2.1.3. What is being done about this concern

DevOps teams choosing their technical stacks are still expected to provide a level of assurance in terms of maintaining the technical stack over time, including addressing IT security and funding requirements. Existing processes are expected to be used to provide this assurance level. The strategy seeks to adjust them by bringing attention to the following:

1. Standards should be looked at with different scope: ESDC Employee and IT Personnel. As IT Personnel require the necessary tools to build/configure solutions for ESDC Employees and/or Canadians.


2. Technical stacks become obsolete much faster now (~2 years) and require revisiting standards much more often. This revisit warrants more engagement with DevOps teams.


3. Use empirical evidence to make decisions, by allowing DevOps team to experiment with technical stacks, trying them out up to, and including, in production. Monitoring their emerging adoption and giving room to scale to the enterprise level.


4. Favour Open Source Software libraries and public cloud service subscriptions, over proprietary software licences, to avoid lengthy procurement and funding battles.

IT-enabled Projects will still engage with Enterprise Architecture at the planning stage to identify existing and reusable investments (e.g., IT Solutions) to be in scope for the IT Project. What the strategy seeks is to provide more autonomy to DevOps teams in choosing technical stacks and making up these individual, reusable, investments.

2.2. Managing this strategy initiative to completion

2.2.1. Summary

Once the Strategy is approved, who will Project Manage the list of initiatives, coordinating and following up with the respective teams to drive the strategy toward completion?

2.2.2. Raised by stakeholder(s)

• CCoE
• IT Strategy
• BPMO

2.2.3. What is being done about this concern

Investigating hiring project managers from the IITB Resource Centre or transferring the change management aspect of the strategy to a new DevOps CoE.

2.3. Oversight on IT Product changes (PO, PM, discretionary, and technical debt)

2.3.1. Summary

The strategy looks at enabling IT Product changes without the burden of having lines of business go through a project lifecycle. It is currently expected that a Product Owner would be managing the priorities for an IT Product backlog that a DevOps team (with the Product Manager) executes.

However, if the Product Owner is from the line of business, it will make timely management of technical debt challenging due to its technical nature (that a line of business would not see or be expected to comprehend).

In addition, while some features are non-discretionary (e.g., legal requirements) others are (e.g., user interface changes). While there needs to be oversight to track effort allocation, it’s unclear how this oversight would not create a different but equal type of burden than that of creating a project.

2.3.2. Raised by stakeholder(s)

• Senior Advisors
• Innovation
• BPMO
• IT Strategy

2.3.3. What is being done about this concern

The following 3 main elements of the strategy strive to address this concern:

1. Adequate training for the Product Owner (PO) role, and its relationship with DevOps Teams, in addressing technical debt and requirements (discretionary and non-discretionary). While technical debt is an important consideration, on the other hand, if DevOps teams are able to create their own prioritization, they often fall victim to over engineering the IT Product. The PO will likely push back against technical debt to make room for features. It then becomes the DevOps teams’ role to sell the value add of paying down technical debt. The POs relentless focus on features is what will focus the teams, and the teams must sell the value add of reducing technical debt. All IT Products have some technical debt, it is a balance between delivering value to users and paying down technical debt which does exist. This is why continuous improvement is important, and should be built into each sprint, while ensuring a focus on delivering value to users. POs are also expected to differentiate between discretionary features (e.g., user interface changes) vs non-discretionary (e.g., changes in regulations) as they ultimately hold accountability for the IT Product’s compliance with the different regulations and policies.

2. Mandated Loose Coupling Architectures are meant to keep overall solutions more flexible to changes by breaking them down into smaller, more manageable, and independent IT Products (i.e., IT Products that can run in production without dependencies on others). See Adopt, Buy, and Build Strategy for more details. As a result, a non-discretionary change (e.g., regulation change) is not expected to impact a large number of IT Products. For example, User Interfaces IT Products (e.g., Web Portals) may not be impacted by regulation changes, but business rules engines and claim processing IT Products are.

3. Moving to Capability-based Planning and Product Management (i.e., putting conditions for IT-enabled project intake where outcomes and metrics need to be approved by the Chief Architect before work can start) is expected to influence where attention needs to be focused. This attention feeds in the different IT Product backlogs based on capabilities required to change or improved in order to fulfill the desired outcomes mentioned in the Business Case. Enterprise Architecture moves to a strategic position, guiding investment decisions and moving away from their execution.

2.4. Alignment and Gap analysis with Policy and Directive (Investment & Project Management)

2.4.1. Summary

An analysis needs to take place to highlight if this model is in alignment with:

• ESDC Directive on Project Management
• ESDC Directive on Programme Management
• ESDC Policy on Project and Programme Management (PPPM)
• TBS Directive on the Management of Projects and Programme
• TBS Policy on Planning and Management of Investments

2.4.2. Raised by stakeholder(s)

• IITB Governance
• BOSS
• Interoperability

2.4.3. What is being done about this concern

An analysis has started. Preliminary review of the financial policies and directives indicates that we are within their requirements. However the Project Management Standards would require changing.

The Strategy expects strong partnership with CFOB IPPM colleagues to resolve this concern.

2.5. Sustainability of skill sets

2.5.1. Summary

If DevOps teams are responsible to maintain their IT Products in production, have the authority to choose their technical stacks, and are expected to have cross-functional skill sets (e.g., UX, Security, and enough technical expertise to maintain their solutions in production), how do we mitigate the turnover risk that such expertise leaves a team?

2.5.2. Raised by stakeholder(s)

• BOSS

2.5.3. What is being done about this concern

The approach and intent in 3 points:

1. Expertise shared amongst members
   It is expected that DevOps teams do not have a single member responsible for a given function. It is always the team, as a whole, that is responsible. The strategy focuses on using champions where the team has a member who is particularly focused on a specific competency (e.g., accessibility). The champion’s role is not to be responsible for accessibility, the champion is responsible for upskilling the team regarding accessibility. The champion will, for example, document the toolsets and approaches the team is using, open tasks and issues in the IT Product’s backlog, and document findings. The champion will also address issues that are submitted. As a result of this approach, even if the champion is to leave the team, the team should have learned enough from the champion, and have enough work documented, that it is able to address the issues created by the champion. The focus is always to upskill the team, and build upon and improve, its skill set.

2. Meritocracy and maturity levels
   Different DevOps teams will have different expertise level. The meritocracy approach recognizes the different levels of maturity between teams and, with this level of maturity, the level of trust the organization should allocate. We are currently looking at a meritocracy approach that favours and incentivize continuous learning for DevOps teams.

3. Management of personnel
   Details on this piece has not yet been figured out and will need to be looked at closely. In the beginning, it is foreseen that we will have cross-functional teams (i.e., members from different functional specifications assembled as a single team), but the target state looks at embedded members with a shared skill set (skill set at the team level, not individually assigned to members). This target state is different than our current functional organization setting.

2.6. Risk to enterprise reference data model and standard compliance

2.6.1. Summary

Moving towards a more decentralized and distributed means of decision-making presents a risk that incorrect decisions may occur, affecting data management across the enterprise. The risk involves duplication of data, incoherence to data consumers, and degradation of data quality. Over the years, IITB has spent efforts centralizing certain functions to achieve efficiencies and be able to do more with less.

In the case of the Data Analytics team, direct access to a database as opposed to an API (exposing data meant for consumption by a User Interface or another functional API) is necessary due to the broad nature of analytics and its need for vast amount of data. An API may be built, per product, for the sole purpose of accessing the database content but:

1. It’s unlikely a Product will have it built, as it will require more costs to do so
2. Performance hits are expected
3. The number of APIs to consume and reconstruct data will increase complexity of Data Analytics solutions

2.6.2. Raised by stakeholder(s)

• DAS

2.6.3. What is being done about this concern

This concern is not addressed at the strategy level (guiding policy) but needs to be reminded during its implementation. The following two careful considerations are necessary:

1. Data Architecture may be too much of a specialized expertise to realistically be embedded within all DevOps team members (like coding, testing, and securing). As such, Data Architects would be individuals with membership on multiple DevOps teams and retain this specialized skill, especially for modelling API schemas and relational databases. This consideration regards the DevOps teams standard definition (one action in the section 3. Coherent set of actions).

2. IT Products must be architected with the notion that large amount of certain data may be required to be consumed by a specialized function (Data Analytics). Restful APIs do not provide the necessary performance requirement to transfer large amount of data. Options may be to export the database in the cloud environment, and analyze its content using cloud tools. Or to analyze locally, we can download the export through electronic transfer, or even actual physical transport of storage devices for very large amount of data (e.g., example of service from AWS.

2.7. Fit of the mainframe programme within the Strategy

2.7.1. Summary

EI and mainframe worlds are not currently setup for agile and DevOps means of practice. How can the mainframe program realistically implement these practices?

2.7.2. Raised by stakeholder(s)

• Benefits and Case Management Solutions

2.7.3. What is being done about this concern

Current thoughts are on:

• Defining a Target Architecture Vision for legacy transitioning environments. This to provide direction and set reasonable expectations for DevOps teams working on non-cloud environments. This Target Architecture vision is meant to provide with reference architectures and baked-in requirements in the scope of IT-enabled Projects that touch mainframe programs. e.g., an integration layer to expose certain functions and data via publicly available APIs that other IT solutions can consume (i.e., the “strangler pattern” that you may have heard about).

• Identify a pilot project during the implementation of the strategy to test its feasibility.

2.8. Legislative level and mandated deadlines

2.8.1. Summary

The EI world deals with large legislative projects where, in alignment with the spirit of the strategy, the work typically starts before gaining official approvals to meet the mandated deadlines. Still, how will this strategy address the legislative context as a whole?

2.8.2. Raised by stakeholder(s)

• Benefits and Case Management Solutions

2.8.3. What is being done about this concern

Current thoughts are on:

• The strategy seeks to move away from advance planning and rigid plan execution; instead moving towards an empirical cycle of trying, observing, and course correcting. We do not mean to improvise our way to delivery. But the gating process in the PMLC that requires us to seek permission to work needs to change towards allowing starting the work, evaluating our progress through actual technical changes, and adjusting our planning efforts with this empirical evidence. So planning and setting expectations to senior management is used with tangible progression of software changes (through changes that do not necessarily reach production yet).

• The ability to deploy software changes faster makes it possible for legislation changes to be felt by end users faster (BDM objective #2: Policy Agility). This is the feedback loop between Canadians and Policy Makers (or legislators) that can be shortened.

2.9. How will an HR organization support the multi-skilled DevOps teams model?

2.9.1. Summary

The Strategy calls for multi-skilled, small (max 9 members), DevOps teams. Being multi-skilled, this means the team members do not perform one specific function like coding, testing, or architecting. All members are expected to have those skills and keep them up to date. This differs from the functional matrix-style team composition we have right now (supporting functional divisions that assign personnel to cross-functional teams).

2.9.2. Raised by stakeholder(s)

• IITB HR

2.9.3. What is being done about this concern

TBD

Appendix A - Archived

This appendix lists the concerns that have been addressed and removed from this document