Skip to main content

Information Technology Strategy Team

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

Version Date of Change Change Description
0.1 2020-04-20 First draft, based on strategy version 0.2 peer review comments
0.2 2020-05-04 Updated from 2nd SABR team peer review
0.3 2020-05-11 Removed Bimodal overhead as the strategy has been renamed to Target Model
0.4 2020-05-22 Added concerns raised during presentations to IITB districts (BOSS, BSIM, Enterprise Ops)
0.5 2020-06-12 Moved clarity of “IT Product” concern to RESOLVED
0.6 2020-06-18 Moved “ERP Solutions” concerned to RESOLVED
0.7 2020-06-23 Added “Development Value Stream” vs Business Architecture’s “Value Stream”
0.8 2020-11-04 Moved to resolved: 2.1 IT Solutions that spans more than one project
Updated 2.2 Proliferation of IT Standards (now 2.1)
Moved to resolved: 2.3 Financials for IT Product’s evolution
Updated 2.5 Oversight on IT Product changes (now 2.X)
Moved to resolved: 2.6 Approach to IT Capacity planning
Moved to resolved: 2.9 Risk to Project Management Overhead
Moved to resolved: 2.10 Risk to capability-based planning ability and transformation
Moved to resolved: 2.11 Risk to Enterprise Reference Data Model and Standard compliance
Moved to resolved: 2.12 Confusion between Development Value Stream and Business Architecture’s definition of Value Stream
Added new concern 2.7 fit with mainframes
Added new concern 2.8 legislation level

Table of Content

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:

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

</table>
Concern Description of what was done to address
Bimodal management overhead The original strategy's language called for a bimodal approach: using two different models in parallel to compare their performance before moving to a single one.

The strategy's language has been changed to define a Target Model and offer a path towards the Target Model. There is no intent in managing two modes of operation, only that there will be a transition period towards the Target State
Stage of the PMLC to choose this alternate model and under whose authority This area of concern regarded the original scope of the strategy: being an alternate model in parallel of the conventional one (i.e., see bimodal above).

The strategy has since then been modified to be the Target State. There is no option and, instead, we need to move towards this model.

As such, this concern no longer applies.
Clarity on the definition of “IT Product” Need to be clear on what we mean by “IT Product”. e.g., does MS Office constitute an IT Product? If taking the direction of the APM Program, an “IT Product” would not be a COTS, but rather a solution that can make use of one a more COTS

Raised by BSIM, BOSS, Senior Advisors

Adding in section "3. Coherent set of actions" the action "Governance / Produce standard definition of IT Product and IT Solutions”. This definition needs endorsements from more than one stakeholder.
Enterprise Resource Planning (ERP) solutions How are ERPs like SAP and PeopleSoft fit in this Target Model? Especially that Lines of Businesses are currently developing and testing the IT Solutions for ERP while the Strategy calls for DevOps teams to do those functions.

Raised by BOSS

After speaking with the ERP team, they are in fact well under way and aligned with the proposed Model. They are able to do same day software changes already, though it is rare. They do weekly or biweekly changes, have different teams responsible to assure segregation of duties and capabilities (e.g., platform team vs development team). They have worked, over the years, to obtain a level of autonomy and have demonstrated through their historical track records that this autonomy does not increases risk.
(2.1) IT Solutions that span more than one project 2.1.1 Summary

One IT solution may span more than one project and include work involved to satisfy multiple project objectives. For example, data management is a capability that crosses multiple project initiative and is required as part of the architecture, design, and implementation of an IT solutions. How to manage and keep track of such cross-project work?

2.1.2 Raised by stakeholder(s)
- Enterprise Architecture
- Chief Data Office

2.1.3 What is being done about this concern

3 main aspects the strategy strives to accomplish to address this concern:

1) Mandate Loose Coupling Architectures
2) Moving to capability-based planning
3) Measure progress by working software, not planning documents

(1) Loose Coupling Architectures are meant to keep overall solutions more flexible to change by breaking it down into smaller, more manageable, and independent components (individual pieces of software or cloud services). These independent components are expected to run in production without dependencies on others (as much as possible) and grant access to their functions and data via well-defined APIs. This is expected to increase a level of complexity in two parts:

A) Data Management: for as to run independently, solution components require to have the data they need to function. We therefore expect data to be copied (e.g., cached) throughout the ecosystem that makes up solutions.
B) Rapid Elasticity: independent components are expected to serve others and will need to scale automatically based on demand.

This increased complexity is warranted as it provides more autonomy to IT teams to make software changes.

(2) Moving to capability-based planning is enabled by moving to Product Management, adopting DevOps, and changing existing governance. Certain capabilities, such as user profile management, may serve multiple IT solutions. These foundational, and underlying, capabilities are not “owned” by a particular line of business or single solutions. Moving to Product Management enables the sustained evolution of those foundational capabilities without the need to seek permission to do so, reducing the lag in changes or battle to find which project is expected to fund a change. Adopting DevOps speeds up change release to production. Changes in governance move the Chief Architect upstream in the investment decision process to educate stakeholders on foundational capabilities serving them, and the need to evolve them to meet changing needs.

(3) It's more meaningful to measure progress through working software. It's also much easier to produce working software using Cloud technologies and DevOps methodologies. This way, working software in production can quickly react to changing conditions (such as increased load). Rapid Elasticity is part of the architecture of a solution component, especially one serving a foundational capability. Using the cloud, virtual instances of solution components can be spun up within milliseconds automatically based on increased demands. But to use the cloud properly, solution component must be architected properly.
(2.2) Financials for IT Products' evolution (lifecycle management) 2.2.1 Summary
We cannot tax financials to a project once it is closed. Yet, software maintenance is not just operational costs, it's managing the technical debt and its evolution from end-user feedback without the burden of creating projects.

2.2.2 Raised by stakeholder(s)
- BPMO
- IT Strategy
- Innovation

2.2.3 What is being done about this concern

The Financial element of the strategy was removed as its scope was misunderstood when drafting the strategy. Instead, the strategy focuses on the following 2 elements for sustaining an IT Product's lifecycle:

1) Move to Product Management
2) Moving to capability-based planning

(1) Moving to Product Management enables the sustained evolution of IT Products without the need to seek permission to do so, reducing the lag in changes or battle to find which project is expected to fund a change. IT Products backlogs are managed by both a clear IT Product owner and the enabling IT Teams existing capacity or by seeking additional ones (e.g., hire staff or consultants). Adopting DevOps practices expedite changes to production, reducing the lag and effort between a software change and its deployment to production.

(2) Moving to capability-based planning is enabled by changing existing governance. The Chief Architect moves upstream in the investment decision process to educate stakeholders on foundational capabilities serving them, and the need to evolve them to meet changing needs by allocating sufficient attention (and funds) to them.
(2.6) Approach to IT Capacity planning 2.6.1 Summary
With moving towards a more agile method of working, that is to have Product Owners and Development teams communicate directly and allowed to make changes to their IT Products, how will IITB manage its IT capacity planning?

2.6.2 Raised by stakeholder(s)
- BPMO

2.6.3 What is being done about this concern

Moving towards using teams (DevOps teams), instead of set of individuals, to perform capacity planning. Teams are pre-defined, including their associated costs (e.g., $1M/year, $2M/year, depending on their constitution).

DevOps teams are assigned a set of IT Products to manage. Should the demand shift in the organization, e.g., much more towards IT Products X, Y, and Z; and not towards IT Products A, B, or C, then there is a risk that DevOps teams assigned to IT Products A, B, and C become idle. Three thoughts on the matter:

(1) We believe this risk to be idle is low as IT Products are constantly evolving and their technical debt need to be managed. DevOps teams continuously improve so they should not be idle.

(2) Adding more teams to IT Products X, Y, and Z does not necessarily increase throughput as the changes required are in the software (i.e., code base, and configuration settings). Adding more teams to work on a code base does not change the fact that it's the code base that needs changing. Code base is the smallest denomination of a deployable unit of software.

(3) Exceptionally, DevOps teams may be shifted to other IT Products, especially as integration capabilities are expected to be in higher demands. Integration capabilities produce other software components to interact with other IT Products (e.g., publicly facing APIs). The constraints here are to maintain a level of consistency in technical stacks, so that newly assigned DevOps teams can more quickly get up to speed.<br">
Ensure the following Coherent Actions address this concern:
  • Governance / Produce a Policy guidance document activity
  • Governance / IITB Agile Governance Framework
  • </td> </tr>
(2.9) Risk to project management overhead 2.9.1 Summary

The strategy looks at limiting the size of projects to Small and below. Is it expected that, should an initiative require multiple releases to production and passes the $2.5M threshold, to redo the Project Management Lifecycle for the subsequent releases?

If so, this creates a risk of too much overhead for IT Teams to handle and may result in slowing delivery.

2.9.2 Raised by stakeholder(s)
- BSIM

2.9.3 What is being done about this concern

This guiding policy requirement has been removed. Ultimately, it's not the limit of project funding we want to limit, it's the approach to its execution that needs to change (from a gated, advance planning, approach, to an empirical cycle of trying, monitoring, and course correcting).
(2.10) Risk to capability-based planning ability and transformation 2.10.1 Summary

There is a risk that smaller investments promote continuing investing in the wrong IT Product and, as such, limit the organization's ability to improve a given capability or transform.

A potential scenario is that what was thought of spending $500k to a legacy product one time, comes up as a series of small investments over the year aggregated to more than $2.5M. In hindsight, the organization may have preferred to use that $2.5M towards transitioning to a modern IT Product instead.

2.10.2 Raised by stakeholder(s)

- EA

2.10.3 What is being done about this concern

This guiding policy requirement has been removed. Ultimately, it's not the limit of project funding we want to limit, it's the approach to its execution that needs to change (from a gated, advance planning, approach, to an empirical cycle of trying, monitoring, and course correcting).

The strategy also seeks to place the Chief Architect in a position of authority for sanctioning the defined outcomes and metrics of the Business Case, as a condition for IT-enabled Project.
(2.12) Confusion between Development Value Stream and Business Architecture's definition of Value Stream 2.12.1 Summary

The term "value stream" has a specific meaning in the context of Business Architecture (it is broken down into "value stages" which are further broken down into "business capabilities"). The strategy uses the SAFe meaning behind “development value stream” which may create conflict with Business Architecture's terminology.

2.12.2 Raised by stakeholder(s)
- Technical Debt (APM)

2.12.3 What is being done about this concern

This guiding policy statement was removed. Instead, the Strategy will remain at the “Agile Governance Framework”. Development Value Streams (or such concepts) will be addressed as part of the Coherent Action "Governance / IT Agile Governance Framework".
View this page on GitHub