Build a Data Architecture Roadmap

Optimizing data architecture requires a plan, not just a data model.

ANALYST PERSPECTIVE

Integral to an insight-driven enterprise is a modern and business-driven data environment.

“As business and data landscapes change, an organization’s data architecture needs to be able to keep pace with these changes. It needs to be responsive so as to not only ensure the organization continues to operate efficiently but that it supports the overall strategic direction of the organization.

In the dynamic marketplace of today, organizations are constantly juggling disruptive forces and are finding the need to be more proactive rather than reactive. As such, organizations are finding their data to be a source of competitive advantage where the data architecture has to be able to not only support the increasing amount, sources, and rate at which organizations are capturing and collecting data but also be able to meet and deliver on changing business needs.

Data architecture optimization should, therefore, aid in breaking down data silos and creating a more shared and all-encompassing data environment for better empowering the business.” (Crystal Singh, Director, Research, Data and Information Practice, Info-Tech Research Group)

Our understanding of the problem

Executive summary

Situation

• The data architecture of a modern organization involves many moving pieces requiring coordination to provide greatest value from data.
• Data architects are at the center of this turmoil and must be able to translate high-level business requirements into specific instructions for data workers using complex data models.

Complication

• Data architects must account for the constantly growing data and application complexity, and more demanding needs from the business.
• There is an ever-increasing number of data sources and a growing need to integrate components to ensure that performance isn’t compromised.
• There isn’t always a clearly defined data architect role, yet the responsibilities must be filled to get maximum value from data.

Resolution

• To deal with these challenges, a data architect must have a framework in place to identify the appropriate solution for the challenge at hand.
  • Identify and prioritize the business drivers in which data architecture changes would create the largest overall benefit, and determine the corresponding data architecture tiers that need to be addressed to customize your solution.
  • Discover the best practice trends, measure your current state, and define the targets for your data architecture tactics.
  • Build a cohesive and personalized roadmap for restructuring your data architecture. Manage your decisions and resulting changes.

Info-Tech Insight

1. Data architecture is not just about models. Viewing data architecture as just technical data modeling can lead to a data environment that does not aptly serve or support the business. Identify the priorities of your business and adapt your data architecture to those needs.
2. Changes to data architecture are typically driven by four common business driver patterns. Use these as a shortcut to understand how to evolve your data architecture.
3. Data is used differently across the layers of an organization’s data architecture; therefore, the capabilities needed to optimize the use of data change with it. Architecting and managing data from source to warehousing to presentation requires different tactics for optimal use.

Your data is the foundation of your organization’s knowledge and ability to make decisions

Data should be at the foundation of your organization’s evolution.

The transformational insights that executives are constantly seeking to leverage can be uncovered with a data practice that makes high quality, trustworthy information readily available to the business users who need it.

50% Organizations that embrace data are 50% more likely to launch products and services ahead of their competitors. (Nesta, 2016)

Whether hoping to gain a better understanding of your business or trying to become an innovator in your industry, any organization can get value from its data regardless of where you are in your journey to becoming a data-driven enterprise:

As organizations seek to become more data driven, it is imperative to better manage data for its effective use

Here comes the zettabyte era.

A zettabyte is a billion terabytes. Organizations today need to measure their data size in zettabytes, a challenge that is only compounded by the speed at which the data is expected to move.

Arriving at the understanding that data can be the driving force of your organization is just the first step. The reality is that the true hurdles to overcome are in facing the challenges of today’s data landscape.

“The data environment is very chaotic nowadays. Legacy applications, data sprawl – organizations are grappling with what their data landscape looks like. Where are our data assets that we need to use?” (Andrew Johnston, Independent Consultant)

Solution

Well-defined and structured data management practices are the best way to mitigate the limitations that derive from these challenges and leverage the most possible value from your data.

Refer to Info-Tech’s capstone Create a Plan For Establishing a Business-Aligned Data Management Practice blueprint to understand data quality in the context of data disciplines and methods for improving your data management capabilities.

Data architecture is an integral aspect of data management

Data architects must maintain a comprehensive view of the organization’s rapidly proliferating data

The data architect: Acts as a “translator” between the business and data workers to communicate data and technology requirements. Facilitates the creation of the data strategy. Manages the enterprise data model. Has a greater knowledge of operational and analytical data use cases. Recommends data management policies and standards, and maintains data management artifacts. Reviews project solution architectures and identifies cross impacts across the data lifecycle. Is a hands-on expert in data management and warehousing technologies. Is not necessarily it’s own designated position, but a role that can be completed by a variety of IT professionals.

Data architects bridge the gap between strategic and technical requirements: “Fundamentally, the role of a data architect is to understand the data in an organization at a reasonable level of abstraction.” (Andrew Johnston, Independent Consultant)

Many are experiencing the pains of poor data architecture, but leading organizations are proactively tackling these issues

Outdated and archaic systems and processes limit the ability to access data in a timely and efficient manner, ultimately diminishing the value your data should bring.

Intuitive organizations who have recognized these shortcomings have already begun the transition to modernized and optimized systems and processes.

Leading organizations are attacking data architecture problems … you will be left behind if you do not start now!

Once on your path to redesigning your data architecture, neglecting the strategic elements may leave you ineffective

Focusing on only data models without the required data architecture guidance can cause harmful symptoms in your IT department, which will lead to organization-wide problems.

Follow Info-Tech’s methodology to optimize data architecture to meet the business needs

The following is a summary of Info-Tech’s methodology:

1	Prioritize your core business objectives and identify your business driver. Learn how business drivers apply to specific tiers of Info-Tech’s five-tier data architecture model. Determine the appropriate tactical pattern that addresses your most important requirements.
2	Select the areas of the five-tier architecture to focus on. Measure current state. Set the targets of your desired optimized state.
3	Roadmap your tactics. Manage and communicate change.

Info-Tech will get you to your optimized state faster by focusing on the important business issues

First Things First

1. Info-Tech’s methodology helps you to prioritize and establish the core strategic objectives behind your goal of modernizing data architecture. This will narrow your focus to the appropriate areas of your current data systems and processes that require the most attention.

Info-Tech has identified these four common drivers that lead to the need to optimize your data architecture.

• Becoming More Data Driven
• Regulations and Compliance
• Mergers and Acquisitions
• New Functionality or Business Rule

These different core objectives underline the motivation to optimize data architecture, and will determine your overall approach.

Use the five-tier architecture to provide a consumable view of your data architecture

Every organization’s data system requires a unique design and an assortment of applications and storage units to fit their business needs. Therefore, it is difficult to paint a picture of an ideal model that has universal applications. However, when data architecture is broken down in terms of layers or tiers, there exists a general structure that is seen in all data systems.

Thinking of your data systems and processes in this framework will allow you to see how different elements of the architecture relate to specific business operations.

Use the five-tier architecture to prioritize tactics to improve your data architecture in line with your pattern

Info-Tech’s Data Architecture Capability Model	Based on your business driver, the relevant data tiers, and your organization’s own specific requirements you will need to establish the appropriate data architecture capabilities. This blueprint will help you measure how you are currently performing in these capabilities… And help you define and set targets so you can reach your optimized state.
Once completed, these steps will be provided with the information you will need to create a comprehensive roadmap. Lastly, this blueprint will provide you with the tools to communicate this plan across your organization and offer change management guidelines to ensure successful adoption.	Info-Tech Insight Optimizing data architecture requires a tactical approach, not a passive approach. The demanding task of optimization requires the ability to heavily prioritize. After you have identified why, determine how using our pre-built roadmap to address the four common drivers.

Do not forget: data architecture is not a standalone concept; it fits into the more holistic design of enterprise architecture

Data Architecture in Alignment Data architecture can not be designed to simply address the focus of data specialists or even the IT department. It must act as a key component in the all encompassing enterprise architecture and reflect the strategy and design of the entire business. Data architecture collaborates with application architecture in the delivery of effective information systems, and informs technology architecture on data related infrastructure requirements/considerations Please refer to the following blueprints to see the full picture of enterprise architecture: Select and Implement an EA Tool Enhance Your Application Architecture

Adapted from TOGAF Refer to Phase C of TOGAF and Bizbok for references to the components of business architecture that are used in data architecture.

Info-Tech’s data architecture optimization methodology helped a monetary authority fulfill strict regulatory pressures

CASE STUDY

Industry: Financial Source: Info-Tech Consulting

Look for this symbol as you walk through the blueprint for details on how Info-Tech Consulting assisted this monetary authority.

Situation: Strong external pressures required the monetary authority to update and optimize its data architecture.

The monetary authority is responsible for oversight of the financial situation of a country that takes in revenue from foreign incorporation. Due to increased pressure from international regulatory bodies, the monetary authority became responsible for generating multiple different types of beneficial ownership reports based on corporation ownership data within 24 hours of a request.

A stale and inefficient data architecture prevented the monetary authority from fulfilling external pressures.

Normally, the process to generate and provide beneficial ownership reports took a week or more. This was due to multiple points of stale data architecture, including a dependence on outdated legacy systems and a broken process for gathering the required data from a mix of paper and electronic sources.

Provide a structured approach to solving the problem

Info-Tech helped the monetary authority identify the business need that resulted from regulatory pressures, the challenges that needed to be overcome, and actionable tactics for addressing the needs.

Info-Tech’s methodology was followed to optimize the areas of data architecture that address the business driver.

• External Requirements
• Business Driver
  Diagnose Data Architecture Problems
  • Outdated architecture (paper, legacy systems)
  • Stale data from other agencies
  • Incomplete data
    Data Architecture Optimization Tactics
    1. Optimized Source Databases
    2. Improved Integration
    3. Data Warehouse Optimization
    4. Data Marts for Reports
    5. Report Delivery Efficiency

As you walk through this blueprint, watch for additional case studies that walk through the details of how Info-Tech helped this monetary authority.

This blueprint’s three-step process will help you optimize data architecture in your organization

Use these icons to help direct you as you navigate this research

Use these icons to help guide you through each step of the blueprint and direct you to content related to the recommended activities.

This icon denotes a slide where a supporting Info-Tech tool or template will help you perform the activity or step associated with the slide. Refer to the supporting tool or template to get the best results and proceed to the next step of the project.

This icon denotes a slide with an associated activity. The activity can be performed either as part of your project or with the support of Info-Tech team members, who will come onsite to facilitate a workshop for your organization.

Info-Tech offers various levels of support to best suit your needs

Diagnostics and consistent frameworks used throughout all four options

Build a Business-Aligned Data Architecture Optimization Strategy – project overview

	PHASE 1 Prioritize Your Data Architecture With Business-Driven Tactics	PHASE 2 Personalize Your Tactics to Optimize Your Data Architecture	PHASE 3 Create Your Tactical Data Architecture Roadmap
Best-Practice Toolkit	1.1 Identify Your Business Driver for Optimizing Data Architecture 1.2 Determine Actionable Tactics to Optimize Data Architecture	2.1 Measure Your Data Architecture Capabilities 2.2 Set a Target for Data Architecture Capabilities 2.3 Identify the Tactics that Apply to Your Organization	3.1 Personalize Your Data Architecture Roadmap 3.2 Manage Your Data Architecture Decisions and the Resulting Changes
Guided Implementations	Understand what data architecture is, how it aligns with enterprise architecture, and how data architects support the needs of the business. Identify the business drivers that necessitate the optimization of the organization’s data architecture. Create a tactical plan to optimize data architecture across Info-Tech’s five-tier logical data architecture model.	Understand Info-Tech’s tactical data architecture capability model and measure the current state of these capabilities at the organization. Determine the target state of data architecture capabilities. Understand the trends in the field of data architecture and identify how they can fit into your environment.	Use the results of the data architecture capability gap assessment to determine the priority of activities to populate your personalized data architecture optimization roadmap. Understand how to manage change as a data architect or equivalent.
Onsite Workshop	Module 1: Identify the Drivers of the Business for Optimizing Data Architecture	Module 2: Create a Tactical Plan for Optimizing Data Architecture	Module 3: Create a Personalized Roadmap for Data Architecture Activities

Workshop overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Build a Business-Aligned Data Architecture Optimization Strategy

PHASE 1

Prioritize Your Data Architecture With Business-Driven Tactics

Phase 1 outline

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 1: Prioritize Your Data Architecture With Business-Driven Tactics

Proposed Time to Completion: 2 weeks

Phase 1 will help you create a strategy to optimize your data architecture using actionable tactics

In this phase, you will determine your focus for optimizing your data architecture based on the business drivers that are commonly felt by most organizations.

1. Identify the business drivers that necessitate data architecture optimization efforts.
2. Understand Info-Tech’s Five-Tier Data Architecture, a logical architecture model that will help you prioritize tactics for optimizing your data architecture environment.
3. Identify tactics for optimizing the organization’s data architecture across the five tiers.

“To stay competitive, we need to become more data-driven. Compliance pressures are becoming more demanding. We need to add a new functionality.”

Info-Tech’s Five-Tier Data Architecture:

1. Data Sources
2. Data Integration and Translation
3. Data Warehousing
4. Data Analytics
5. Data Presentation

Tactical plan for Data Architecture Optimization

Phase 1, Step 1: Identify Your Business Driver for Optimizing Data Architecture

This step will walk you through the following activities:

• Understand how data architecture fits into the organization’s larger enterprise architecture.
• Understand what data architecture is and how it should be driven by the business.
• Identify the driver that is creating a need for data architecture optimization.

This step involves the following participants:

• Data Architect
• Enterprise Architect

Outcomes of this step

• A starting point for the many responsibilities of the data architect role. Balancing business and technical requirements can be challenging, and to do so you need to first understand what is driving the need for data architecture improvements.
• Holistic understanding of the organization’s architecture environment, including enterprise, application, data, and technology architectures and how they interact.

Data architecture involves planning, communication, and understanding of technology

Data Architecture

A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources (TOGAF 9).

The subject area of data management that defines the data needs of the enterprise and designs the master blueprints to meet those needs (DAMA DMBOK, 2009).

IBM (2007) defines data architecture as the design of systems and applications that facilitate data availability and distribution across the enterprise.

Definitions vary slightly across major architecture and management frameworks.

However, there is a general consensus that data architecture provides organizations with:

• Alignment
• Planning
• Road mapping
• Change management
• A guide for the organization’s data management program

Data architecture must be based on business goals and objectives; developed within the technical strategies, constraints, and opportunities of the organization in support of providing a foundation for data management.

Info-Tech Insight

Data Architecture is not just data models. Data architects must understand the needs of the business, as well as the existing people and processes that already exist in the organization to effectively perform their job.

Review how data architecture fits into the broader architectural context

		Each layer of architecture informs the next. In other words, each layer has components that execute processes and offer services to the next layer. For example, data architecture can be broken down into more granular activities and processes that inform how the organization’s technology architecture should be arranged.
Data does not exist on its own. It is informed by business architecture and used by other architectural domains to deliver systems, IT services, and to support business processes. As you build your practice, you must consider how data fits within the broader architectural framework.	The Zachman Framework is a widely used EA framework; within it, data is identified as the first domain. The framework aims to standardize artifacts (work-products) within each architectural domain, provides a cohesive view of the scope of EA and clearly delineates data components. Use the framework to ensure that your target DA practice is aligned to other domains within the EA framework.	(Source: Zachman International)

Data architects operate in alignment with the other various architecture groups

Data architects operate in alignment with the other various architecture groups, with coordination from the enterprise architect.

Enterprise Architect
The enterprise architect provides thought leadership and direction to domain architects.

They also maintain architectural standards across all the architectural domains and serve as a lead project solution architect on the most critical assignments.

• Business Architect
  A business subject matter expert who works with the line-of-business team to assist in business planning through capability-based planning.
• Security Architect
  Plays a pivotal role in formulating the security strategy of the organization, working with the business and CISO/security manager. Recommends and maintains security standards, policies, and best practices.
• Infrastructure Architect
  Recommends and maintains standards across the compute, storage, and network layers of the organization. Reviews project solution architectures to ensure compliance with infrastructure standards, regulations, and target state blueprints.
• Application Architect
  Manages the business effectiveness, satisfaction, and maintainability of the application portfolio. Conduct application architecture assessments to document expected quality attribute standards, identify hotspots, and recommend best practices.
• Data Architect
  Facilitates the creation of data strategy and has a greater understanding of operational and analytical data use cases. Manages the enterprise data model which includes all the three layers of modelling - conceptual, logical, and physical. Recommends data management policies and standards, and maintains data management artefacts. Reviews project solution architectures and identifies cross impacts across the data lifecycle.

As a data architect, you must maintain balance between the technical and the business requirements

The data architect role is integral to connecting the long-term goals of the business with how the organization plans to manage its data for optimal use.

Info-Tech Insight

The data architect role is not always clear cut. Many organizations do not have a dedicated data architect resource, and may not need one. However, the duties and responsibilities of the data architect must be carried out to some degree by a combination of resources as appropriate to the organization’s size and environment.

Understand the role of a data architect to ensure that essential responsibilities are covered in the organization

A database administrator (DBA) is not a data architect, and data architecture is not something you buy from an enterprise application vendor.

See Info-Tech’s Data Architect job description for a comprehensive description of the data architect role.

Leverage data architecture frameworks to understand how the role fits into the greater Enterprise Architecture framework

Enterprise data architectures are available from industry consortiums such as The Open Group (TOGAF®), and open source initiatives such as MIKE2.0.

The Open Group TOGAF enterprise architecture model is a detailed framework of models, methods, and supporting tools to create an enterprise-level architecture.

• TOGAF was first developed in 1995 and was based on the Technical Architecture Framework for Information Management (TAFIM) developed by the US Department of Defense.
• TOGAF includes application, data, and infrastructure architecture domains providing enterprise-level, product-neutral architecture principles, policies, methods, and models.
• As a member of The Open Group, it is possible to participate in ongoing TOGAF development initiatives.

The wide adoption of TOGAF has resulted in the mapping of it to several other industry standards including CoBIT and ITIL.

MIKE2.0 (Method for an Integrated Knowledge Environment), is an open source method for enterprise information management providing a framework for information development.

• SAFE (Strategic Architecture for the Federated Enterprise) provides the technology solution framework for MIKE2.0
• SAFE includes application, presentation, information, data, Infrastructure, and metadata architecture domains.

Info-Tech Best Practice

If an enterprise-level IT architecture is your goal, TOGAF is likely a better model. However, if you are an information and knowledge-based business then MIKE2.0 may be more relevant to your business.

The data architect must identify what drives the need for data from the business to create a business-driven architecture

As the business landscape evolves, new needs arise. An organization may undergo new compliance requirements, or look to improve their customer intimacy, which could require a new functionality from an application and its associated database.

There are four common scenarios that lead to an organization’s need to optimize its data architecture and these scenarios all present unique challenges for a data architect:

1. Becoming More Data Driven As organizations are looking to get more out of their data, there is a push for more accurate and timely data from applications. Data-driven decision making requires verifiable data from trustworthy sources. Result: Replace decisions made on gut or intuition with real and empirical data - make more informed and data-driven decisions.
2. New Functionality or Business Rule In order to succeed as business landscapes change, organizations find themselves innovating on products or services and the way they do things. Changes in business rules, product or service offering, and new functionalities can subsequently demand more from the existing data architecture. Result: Prepare yourself to successfully launch new business initiatives with an architecture that supports business needs.
3. Mergers and Acquisitions If an organization has recently acquired, been acquired, or is merging with another, the technological implications require careful planning to ensure a seamless fit. Application consolidation, retirement, data transfer, and integration points are crucial. Result: Leverage opportunities to incorporate and consolidate new synergistic assets to realize the ROI.
4. Risk and Compliance Data in highly regulated organizations needs to be kept safe and secure. Architectural decisions around data impact the level of compliance within the organization. Result: Avoid the fear of data audits, regulatory violations, and privacy breaches.

Info-Tech Best Practice

These are not the only reasons why data architects need to optimize the organization’s data architecture. These are only four of the most common scenarios, however, other business needs can be addressed using the same concept as these four common scenarios.

Use the Data Architecture Driver tool to identify your focus for data architecture

Follow Info-Tech’s process of first analyzing the needs of the business, then determining how best to architect your data based on these drivers. Data architecture needs to be able to rapidly evolve to support the strategic goals of the business, and the Data Architecture Driver Pattern Identification Tool will help you to prioritize your efforts to best do this.

Identify the drivers for improving your data architecture

INPUT: Data Architecture Driver tool assessment prompts.

OUTPUT: Identified business driver that applies to your organization.

Materials: Data Architecture Driver Pattern Identification Tool

Participants: Data architect, Enterprise architect

Interview the business to get clarity on business objectives and drivers

1.1.2 1 hour per interview

INPUT: Sample questions targeting the activities, challenges, and opportunities of each business unit

OUTPUT: Sample questions targeting the activities, challenges, and opportunities of each business unit

Materials: Data Architecture Driver Pattern Identification Tool

Participants: Data architect, Business representatives, IT representatives

Identify 2-3 business units that demonstrate enthusiasm for or a positive outlook on improving how organizational data can help them in their role and as a unit.

Conducting a deep-dive interview process with these key stakeholders will help further identify high-level goals for the data architecture strategy within each business unit. This process will help to secure their support throughout the implementation process by giving them a sense of ownership.

Key Interview Questions:

1. What are your primary activities? What do you do?
2. What challenges do you have when completing your activities?
3. How is poor data impacting your job?
4. If [your selected domain]’s data is improved, what business issues would this help solve?

Request background information and documentation from stakeholders regarding the following:

• What current data management policies and processes exist (that you know of)?
• Who are the data owners and end users?
• Where are the data sources within the department stored?
• Who has access to these data sources?
• Are there existing or ongoing data issues within those data sources?

Interview the enterprise architect to get input on the drivers of the business

1.1.3 2 hours

INPUT: Data Architecture Driver tool assessment prompts.

OUTPUT: Identified business driver that applies to your organization.

Materials: Data Architecture Driver Pattern Identification Tool

Participants: Data architect, Enterprise architect

Data architecture improvements need to be driven by business need.

Instructions As you work through Tab 2. Driver Identification of the Data Architecture Driver Pattern Identification Tool, consult with the enterprise architect or equivalent to assist you in rating the importance of each of the symptoms of the business drivers. This will help you provide greater value to the business and more aligned objectives.

Tab 2. Driver Identification

Once you know what that need is, go to Step 2.

Phase 1, Step 2: Establish Actionable Tactics to Optimize Data Architecture

This step will walk you through the following activities:

• Understand Info-Tech’s five-tier data architecture to begin focusing your architectural optimization.
• Create your Data Architecture Optimization Template to plan your improvement tactics.
• Prioritize your tactics based on the five-tier architecture to plan optimization.

This step involves the following participants:

• Data Architect
• Enterprise Architect
• DBAs

Outcomes of this step

• A tactical and prioritized plan for optimizing the organization’s data architecture according to the needs of the business.

To plan a business-driven architecture, data architects need to keep the organization’s big picture in mind

Remember… Architecting an organization involves alignment, planning, road mapping, design, and change management functions.

Data architects must be heavily involved with:

• Understanding the short- and long-term visions of the business to develop a vision for the organization’s data architecture.
• Creating processes for governing the identification, collection, and use of accurate and valid data, as well as for tracking data quality, completeness, and redundancy.
• They need to create strategies for data security, backup, disaster recovery, business continuity, and archiving, and ensure regulatory compliance.

To do this, you need a framework. A framework provides you with the holistic view of the organization’s data environment that you can use to design short- and long-term tactics for improving the use of data for the needs of the business.

Use Info-Tech’s five-tier data architecture to model your environment in a logical, consumable fashion.

Info-Tech Best Practice

The more complicated an environment is, the more need there is for a framework. Being able to pick a starting point and prioritize tasks is one of the most difficult, yet most essential, aspects of any architect’s role.

The five tiers of an organization’s data architecture support the use of data throughout its lifecycle

Info-Tech’s five-tier data architecture model summarizes an organization’s data environment at a logical level. Data flows from left to right, but can also flow from the presentation layer back to the warehousing layer for repatriation of data.

Use the Data Architecture Optimization Template to build your improvement roadmap

Download the Data Architecture Optimization Template.

Overview

Use this template to support your team in creating a tactical strategy for optimizing your data architecture across the five tiers of the organization’s architecture. This template can be used to document your organization’s most pressing business driver, the reasons for optimizing data architecture according to that driver, and the tactics that will be employed to address the shortcomings in the architecture.

	Info-Tech’s Data Architecture Optimization Template	Table of Contents
		1. Build Your Current Data Architecture Logical Model	Use this section to document the current data architecture situation, which will provide context for your plan to optimize your data architecture.
		2. Optimization Plan	Use this section to document the tactics that will be employed to optimize the current data architecture according to the tactic pattern identified by the business driver.

Fill out as you go

As you read about the details of the five-tier data architecture model in the following slides, start building your current logical data architecture model by filling out the sections that correspond to the various tiers. For example, if you identified that the most pressing business driver is becoming compliant with regulations, document the sources of data required for compliance, as well as the warehousing strategy currently being employed. This will help you to understand the organization’s data architecture at a logical level.

Tier 1 represents all of the sources of your organization’s data

–› Data to integration layer

Tier 1 is where the data enters the organization. All applications, data documents such as MS Excel spreadsheets, documents with table entries, manual extractions from other document types, user-level databases including MS Access and MySQL, other data sources, data feeds, big datasets, etc. reside here. This tier typically holds the siloed data that is so often not available across the enterprise because the data is held within department-level applications or systems. This is also the layer where transactions and operational activities occur and where data is first created or ingested. There are any number of business activities from transactions through business processes that require data to flow from one system to another, so it is often at this layer we see data created more than once, data corruption occurs, manual re-keying of data from system to system, and spaghetti-like point-to-point connections are built that are often fragile. This is usually the single most problematic area within an enterprise’s data environment. Application- or operational-level (siloed) reporting often occurs at this level. Info-Tech Best Practice An optimized Tier 1 has the following attributes: Rationalized applications Operationalized database administration Databases governed, monitored, and maintained to ensure optimal performance

Tier 2 represents the movement of data

–› Data to Warehouse Environment Find out more For more information on data integration, see Info-Tech’s Optimize the Organization’s Data Integration Practices blueprint.

Tier 2 is where integration, transformation, and aggregation occur. Regardless of how you integrate your systems and data stores, whether via ETL, ESB, SOA, data hub, ODS, point-to-point, etc., the goal of this layer is to move data at differing speeds for one of two main purposes: 1) To move data from originating systems to downstream systems to support integrated business processes. This ensures the data is pristine through the process and improves trustworthiness of outcomes and speed to task and process completion. 2) To move data to Tier 3 - The Data Warehouse Architecture, where data rests for other purposes. This movement of data in its purest form means we move raw data to storage locations in an overall data warehouse environment reflecting any security, compliance and other standards in our choices for how to store. Also, this is where data is transformed for unique business purpose that will also be moved to a place of rest or a place of specific use. Data masking, scrambling, aggregation, cleansing and matching, and other data related blending tasks occur at this layer. Info-Tech Best Practice An optimized Tier 2 has the following attributes: Business data glossary is leveraged ETL is governed ETL team is empowered Data matching is facilitated Canonical data model is present

Tier 3 is where data comes together from all sources to be stored in a central warehouse environment

Tier 3 is where data rests in long-term storage. This is where data rests (long-term storage) and also where an enterprise’s information, documents, digital assets, and any other content types are stored. This is also where derived and contrived data creations are stored for re-use, and where formulas, thought models, heuristics, algorithms, report styles, templates, dashboard styles, and presentations-layer widgets are all stored in the enterprise information management system. At this layer there may be many technologies and many layers of security to reflect data domains, classifications, retention, compliance, and other data needs. This is also the layer where data lakes exist as well as traditional relational databases, enterprise database systems, enterprise content management systems, and simple user-level databases. Info-Tech Best Practice An optimized Tier 3 has the following attributes: Data warehouse is governed Data warehouse operations and planning Data library is comprehensive Four Rosetta Stones of data are in place: BDG, data classification, reference data, master data.

Data from integration layer –› –› Analytics Find out more For more information on Data Warehousing, see Info-Tech’s Build an Extensible Data Warehouse Foundation and Drive Business Innovation With a Modernized Data Warehouse Environment blueprints.

Tier 4 is where knowledge and insight is born

Tier 4 represents data being used for a purpose. This is where you build fit-for-purpose data sets (marts, cubes, flat files) that may now draw from all enterprise data and information sources as held in Tier 3. This is the first place where enterprise views of all data may be effectively done and with trust that golden records from systems of record are being used properly. This is also the layer where BI tools get their greatest use for performing analysis. Unlike Tier 3 where data is at rest, this tier is where data moves back into action. Data is brought together in unique combinations to support reporting, and analytics. It is here that the following enterprise analytic views are crafted: Exploratory, Inferential, Causal, Comparative, Statistical, Descriptive, Diagnostic, Hypothesis, Predictive, Decisional, Directional, Prescriptive Info-Tech Best Practice An optimized Tier 4 has the following attributes: Reporting meets business needs Data mart operations are in place Governance of data marts, cubes, and BI tools in place

Warehouse Environment –› –› Presentation Find out more For more information on BI tools and strategy, see Info-Tech’s Select and Implement a Business Intelligence and Analytics Solution and Build a Next Generation BI with a Game-Changing BI Strategy blueprints.

The presentation layer, Tier 5, is where data becomes presentable information

Tier 5 represents data in knowledge form. This is where the data and information combine in information insight mapping methods (presentations, templates, etc.). We craft and create new ways to slice and dice data in Tier 4 to be shown and shared in Tier 5. Templates for presenting insights are extremely valuable to an enterprise, both for their initial use, and for the ability to build deeper, more insightful analytics. Re-use of these also enables maximum speed for sharing, consuming the outputs, and collective understanding of these deeper meanings that is a critical asset to any enterprise. These derived datasets and the thought models, presentation styles, templates, and other derived and contrived assets should be repatriated into the derived data repositories and the enterprise information management systems respectively as shown in Tier 3. Find out more For more information on enterprise content management and metadata, see Info-Tech’s Develop an ECM Strategy and Break Open Your DAM With Intuitive Metadata blueprints.
Info-Tech Best Practice An optimized Tier 5 has the following attributes: Metadata creation is supervised Metadata is organized Metadata is governed Content management capabilities are present	Info-Tech Insight Repatriation of data and information is an essential activity for all organizations to manage organizational knowledge. This is the activity where information, knowledge, and insights that are stored in content form are moved back to the warehousing layer for long-term storage. Because of this, it is crucial to have an effective ECM strategy as well as the means to find information quickly and efficiently. This is where metadata and taxonomy come in.

As a data architect, you must prioritize your focus according to business need

Determine your focus.

Now that you have an understanding of the drivers requiring data architecture optimization, as well as the current data architecture situation at your organization, it is time to determine the actions that will be taken to address the driver.

1. Business driver	Data Architecture Driver Pattern Identification Tool, Tab 2. Tactic Pattern Plan	3. Documented tactic plan Data Architecture Optimization Template
2. Tactics across the five tiers

The next four slides provide an overview of the priorities that accompany the four most common business drivers that require updates to a stale data architecture.

Business driver #1: Adding a new functionality to an application can have wide impacts on data architecture

Does the business wants to add a new application or supplement an existing application with a new functionality?

Whether the business wants to gain better customer intimacy, achieve operational excellence, or needs to change its compliance and reporting strategy, the need for collecting new data through a new application or a new functionality within an existing application can arise. This business driver has the following attributes:

Often operational oriented and application driven. An application is changed through an application version upgrade, migration to cloud, or application customization, or as a result of application rationalization or changes in the way that application data is generated. However, not all new functionalities trigger this scenario. Non-data-related changes, such as a new interface, new workflows, or any other application functionality changes that do not involve data, will not have data architecture impacts.
	When this business driver arises, data architects should focus on optimizing architecture at the source tier and the integration of the new functionality.	Tactics for this business driver should address the following pattern:

Business driver #2: Organizations today are looking to become more data driven

Does the business wants to better leverage its data?

An organization can want to use its data for multiple reasons. Whether these reasons include improving customer experience or operational excellence, the data architect must ensure that the organization’s data aggregation environment, reporting and analytics, and presentation layer are assessed and optimized for serving the needs of the business.

“Data-drivenness is about building tools, abilities, and, most crucially, a culture that acts on data.” (Carl Anderson, Creating a Data-Driven Organization)

Tactics for this business driver should address the following pattern:			When this business driver arises, data architects should focus on optimizing architecture at the source tier and the integration of the new functionality.
	This scenario is typically project driven and analytical oriented. The business is looking to leverage data and information by processing data through BI tools and self-service. Example: The organization wants to include new third-party data, and needs to build a new data mart to provide a slice of data for analysis.

Business driver #3: Risk and compliance demands can put pressure on outdated architectures

Is there increasing pressure on the business to maintain compliance requirements as per regulations?

An organization can want to use its data for multiple reasons. Whether these reasons include improving customer experience or operational excellence, the data architect must ensure that the organization’s data aggregation environment, reporting and analytics, and presentation layer are assessed and optimized for serving the needs of the business.

There are different types of requirements: Can be data-element driven. For example, PII, PHI are requirements around data elements that are associated with personal and health information. Can be process driven. For example, some requirements restrict data read/write to certain groups.
	When this business driver arises, data architects should focus on optimizing architecture where data is stored: at the sources, the warehouse environment, and analytics layer.	Tactics for this business driver should address the following pattern:

Business driver #4: Mergers and acquisitions can require a restructuring of the organization’s data architecture

Is the organization looking to acquire or merge with another organization or line of business? There are three scenarios that encompass the mergers and acquisitions business driver for data architecture: The organization acquires/merges with another organization and wants to integrate the data. The organization acquires/merges a subset of an organization (a line of business, for example) and wants to integrate the data. The organization acquires another organization for competitive purposes, and does not need to integrate the data.		Regardless of what scenario your organization falls into, you must go through the same process of identifying the requirements for the new data: Understand what data you are getting. The business may acquire another organization for the data, for the technology, and/or for algorithms (for example). If the goal is to integrate the new data, you must understand if the data is unstructured, structured, how much data, etc. Plan for the integration of the new data into your environment. Do you have the expertise in-house to integrate the data? Database structures and systems are often mismatched (for example, acquired company could have an Oracle database whereas you are an SAP shop) and this may require expertise from the acquired company or a third party. Integrate the new data. Often, the extraction of the new data is the easy part. Transforming and loading the data is the difficult and costly part.
“As a data architect, you must do due diligence of the acquired firm. What are the workflows, what are the data sources, what data is useful, what is useless, what is the value of the data, and what are the risks of embedding the data?” (Anonymous Mergers and Acquisitions Consultant)
	When this business driver arises, data architects should focus on optimizing architecture at the source tier, the warehousing layer, and analytics.

Determine your tier priority pattern and the tactics that you should address based on the business drivers

1.2.1 30 minutes

INPUT: Business driver assessment

OUTPUT: Tactic pattern and tactic plan

Materials: Data Architecture Driver Pattern Identification Tool, Data Architecture Optimization Template

Participants: Data architect, Enterprise architect

Instructions After you have assessed the organization’s business driver on Tab 1. Driver Identification, move to Tab 2. Tactic Pattern Plan. Here, you will find a summary of the business driver that applies to you, as well as the tier priority pattern that will help you to focus your efforts for data architecture. Document the Tier Priority Pattern and associated tactics in Section 2. Optimization Plan of the Data Architecture Optimization Plan.
Data Architecture Driver Tool		Data Architecture Optimization Template

Info-Tech Insight

Our approach will help you to get to the solution of the organization’s data architecture problems as quickly as possible. However, keep in mind that you should still address the other tiers of your data architecture even if they are not part of the pattern we identified. For example, if you need to become more data driven, don’t completely ignore the sources and the integration of data. However, to deliver the most and quickest value, focus on tiers 3, 4, and 5.

This phase helped you to create a tactical plan to optimize your data architecture according to business priorities

Phase 1 is all about focus.

Data architects and those responsible for updating an organization’s data architecture have a wide-open playing field with which to take their efforts. Being able to narrow down your focus and generate an actionable plan will help you provide more value to the organization quickly and get the most out of your data.

Phase 1
• Business Drivers
  • Tactic Pattern
    • Tactical Plan

Now that you have your prioritized tactical plan, move to Phase 2. This phase will help you map these priorities to the essential capabilities and measure where you stack up in these capabilities. This is an essential step in creating your data architecture roadmap and plan for coming years to modernize the organization’s data architecture.

To identify what the monetary authority needed from its data architecture, Info-Tech helped determine the business driver

CASE STUDY

Industry: Financial Source: Info-Tech Consulting

Part 1

Prior to receiving new external requirements, the monetary Authority body had been operating with an inefficient system. Outdated legacy systems, reports in paper form, incomplete reports, and stale data from other agencies resulted in slow data access. The new requirements demanded speeding up this process. Although the organization understood it needed changes, it first needed to establish what were the business objectives, and which areas of their architecture they would need to focus on. The business driver in this case was compliance requirements, which directed attention to the sources, aggregation, and insights tiers.

Looking at the how the different tiers relate to certain business operations, the organization uncovered the best practise tactics to achieving an optimized data architecture. 1. Source Tactics: 3. Warehousing Tactics: 4. Analytics Tactics: Identify data sources Ensure data quality Properly catalogue data Properly index data Provide the means for data accessibility Allow for data reduction/space for report building Once the business driver had been established, the organization was able to identify the specific areas it would eventually need to evaluate and remedy as needed.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech Workshop

Book a workshop with our Info-Tech analysts:

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team. Info-Tech analyst will join you and your team onsite at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop. Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

1.1.1		Identify the business driver that will set the direction of your data architecture optimization plan. In this activity, the facilitator will guide the team in identifying the business driver that is creating the need to improve the organization’s data architecture. Data architecture needs to adapt to the changing needs of the business, so this is the most important step of any data architecture improvements.
1.2.1		Determine the tactics that you will use to optimize data architecture. In this activity, the facilitator will help the team create a tactical plan for optimizing the organization’s data architecture across the five tiers of the logical model. This plan can then be followed when addressing the business needs.

Build a Business-Aligned Data Architecture Optimization Strategy

PHASE 2

Personalize Your Tactics to Optimize Your Data Architecture

Phase 2 will determine your tactics that you should implement to optimize your data architecture

Phase 2 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 2: Personalize Your Tactics to Optimize Your Data Architecture

Proposed Time to Completion: 2 weeks

Phase 2, Step 1: Measure Your Data Architecture Capabilities

This step will walk you through the following activities:

• As you walk through the data architecture capability model, measure your current state in each of the relevant capabilities.
• Distinguish between essential and nice-to-have capabilities for your organization.

This step involves the following participants:

• Data Architect

Outcomes of this step

• A framework for generating a tactical plan for data architecture optimization.
• Knowledge of the various trends in the data architecture field that can be incorporated into your plan.

To personalize your tactical strategy, you must measure up your base data architecture capabilities

What is a capability?

Capabilities represent a mixture of people, technology, and processes. The focus of capability design is on the outcome and the effective use of resources to produce a differentiating capability or an essential supporting capability.

To personalize your tactics, you have to understand what the essential capabilities are across the five tiers of an organization’s data architecture. Then, assess where you currently stand in these capabilities and where you need to go in order to build your optimization plan.

Info-Tech’s data architecture capability model can be laid over the five-tier data architecture to understand the essential and advanced capabilities that an organization should have, and to build your tactical strategy for optimizing the organization’s data architecture across the tiers.

Use Info-Tech’s data architecture capability model as a resource to assess and plan your personalized tactics

Info-Tech’s data architecture capability model can be laid over the five-tier data architecture to understand the essential and advanced capabilities that an organization should have, and to build your tactical strategy for optimizing the organization’s data architecture across the tiers.

Use the Data Architecture Tactical Roadmap Tool to create a tailored plan of action

2.1.1 Data Architecture Tactical Roadmap Tool

Benefits of using this tool:

• Comprehensive documentation of data architecture capabilities present in leading organizations.
• Generates an accurate architecture roadmap for your organization that is developed in alignment with the broader enterprise architecture and related architectural domains.

To create a plan for your data architecture priorities, you must first understand where you currently stand

Now that you understand the business problem that you are trying to solve, it is time to take action in solving the problem.

The organization likely has some of the capabilities that are needed to solve the problem, but also a need to improve other capabilities. To narrow down the capabilities that you should focus on, first select the business driver that was identified in Phase 1 in Tab 1. Business Driver Input of the Data Architecture Tactical Roadmap Tool. This will customize the roadmap tool to deselect the capabilities that are likely to be less relevant to your organization.

For Example: If you identified your business driver as “becoming more data-driven”, you will want to focus on measuring and building out the capabilities within Tiers 3, 4, and 5 of the capability model.

Data Architecture Capability Model

Note If you want to assess your organization for all of the capabilities across the data architecture capability model, select “Comprehensive Data Architecture Assessment” in Tab 1. Business Driver Input of the Data Architecture Tactical Roadmap Tool.

Determine your current state across the related architecture tiers

2.1.2 1 hour

INPUT: Current data architecture capabilities.

OUTPUT: An idea of where you currently stand in the capabilities.

Materials: Data Architecture Tactical Roadmap Tool

Participants: Data architect, Enterprise architect, Business representatives

Use the Data Architecture Tactical Roadmap Tool to evaluate the baseline and target capabilities of your practice in terms of how data architecture is approached and executed.

Info-Tech Insight

Focus on Early Alignment. Assessing capabilities within specific people’s job functions can naturally result in disagreement or debate, especially between business and IT people. Objectively facilitate any debate and only finalize capability assessments when there is full alignment. Remind everyone that data architecture should ultimately serve business needs wherever possible.

Phase 2, Step 2: Set a Target for Data Architecture Capabilities

This step will walk you through the following activities:

• Determine your target state in each of the relevant capabilities.
• Distinguish between essential and nice-to-have capabilities for your organization.

This step involves the following participants:

• Data Architect

Outcomes of this step

• A holistic understanding of where the organization’s data architecture currently sits, where it needs to go, and where the biggest gaps lie.

To create a plan for your data architecture priorities, you must also understand where you need to get to in the future

Keep the goal in mind by documenting target state objectives. This will help to measure the highest priority gaps in the organization’s data architecture capabilities.

Example driver = Becoming more data driven				Current Capabilities		Target Capabilities
			Gaps and Priorities

Determine your future state across the relevant tiers of the data architecture capability model

INPUT: Current state of data architecture capabilities.

OUTPUT: Target state of data architecture capabilities.

Materials: Data Architecture Tactical Roadmap Tool

Participants: Data architect

The future of data architecture is now.

Determine the state of data architecture capabilities that the organization needs to reach to address the drivers of the business.

For example: If you identified your business driver as “becoming more data driven”, you will want to focus on the capabilities within Tiers 3, 4, and 5 of the capability model.

Driver = Becoming more data driven

Target Capabilities

Identify where gaps in your data architecture capabilities lie

2.2.2 1 hour

INPUT: Current and target states of data architecture capabilities.

OUTPUT: Holistic understanding of where you need to improve data architecture capabilities.

Materials: Data Architecture Tactical Roadmap Tool

Participants: Data architect

Visualization of gap assessment of data quality practice capabilities

To enable deeper analysis on the results of your capability assessment, Tab 4. Capability Gap Analysis in the Data Architecture Tactical Roadmap Tool creates visualizations of the gaps identified in each of your practice capabilities and related data management practices. These diagrams serve as analysis summaries.

Gap Assessment of Data Source Capabilities

Use Tab 3. Data Quality Practice Scorecard to enhance your data quality project.

1. Enhance your gap analyses by forming a relative comparison of total gaps in key practice capability areas, which will help in determining priorities.
2. Put these up on display to improve discussion in the gap analyses and prioritization sessions.
3. Improve the clarity and flow of your strategy template, final presentations, and summary documents by copying and pasting the gap assessment diagrams.

Phase 2, Step 3: Identify the Tactics That Apply to Your Organization

This step will walk you through the following activities:

• Before making your personal tactic plan, identify the trends in data architecture that can benefit your organization.
• Understand Info-Tech’s data architecture capability model.
• Initiate the Data Architecture Roadmap Tool to begin creating a roadmap for your optimization plan.

This step involves the following participants:

• Data Architect

Outcomes of this step

• A framework for generating a tactical plan for data architecture optimization.
• Knowledge of the various trends in the data architecture field that can be incorporated into your plan.

Capitalize on trends in data architecture before you determine the tactics that apply to you

Stop here. Before you begin to plan for optimization of the organization’s data environment, get a sense of the sustainability and scalability of the direction of the organization’s data architecture evolution.

Practically any trend in data architecture is driven by an attempt to solve one or more the common challenges of today’s tumultuous data landscape, otherwise known as “big data.” Data is being produced in outrageous amounts, at very high speeds, and in a growing number of types and structures.

To meet these demands, which are not slowing down, you must keep ahead of the curve. Consider the internal and external catalysts that might fuel your organization’s need to modernize its data architecture:

Read the Data Architecture Trends Presentation to understand the current cutting edge topics in data architecture

The speed at which new technology is changing is making it difficult for IT professionals to keep pace with best practices, let alone cutting edge technologies.

The Info-Tech Data Architecture Trends Presentation provides a glance at some of the more significant innovations in technology that are driving today’s advanced data architectures. This presentation also explains how these trends relate to either the data challenges you may be facing, or the specific business drivers you are hoping to bring to your organization.

Data Architecture Trends Presentation

Gaps between your current and future capabilities will help you to determine the tactics that apply to you

Now that you know where the organization currently stands, follow these steps to begin prioritizing the initiatives:

1. What are you trying to accomplish? Determine target states that are framed in quantifiable objectives that can be clearly communicated. The more specific the objectives are the better.
2. Evaluate the “delta,” or difference between where the organization currently stands and where it needs to go. This will be expressed in terms of gap closure strategies, and will help clarify the initiatives that will populate the road map.
3. Determine the relative business value of each initiative, as well as the relative complexities of successfully implementing them. These scores should be created with stakeholder input, and then plotted in an effort/transition quadrant map to determine where the quickest and most valuable wins lie.

Info-Tech Insight

Optimizing data architecture requires a tactical approach, not a passive approach. The demanding task of optimization requires the ability to heavily prioritize. After you have identified why, determine how using our pre-built roadmap to address the four common drivers.

Each of the layers of an organization’s data architecture have associated challenges to optimization

Stop! Before you begin, recognize these “gotchas” that can present roadblocks to creating an effective data architecture environment.

Before diving headfirst into creating your tactical data architecture plan, documenting the challenges associated with each aspect of the organization’s data architecture can help to identify where you need to focus your energy in optimizing each tier. The following table presents the common challenges across the five tiers:

Create metrics before you plan to optimize your data architecture

2.2.3 1 hour

INPUT: Tactics that will be used to optimize data architecture.

OUTPUT: Metrics that can be used to measure optimization success.

Materials: Data Architecture Tactical Roadmap Tool

Participants: Data architect

Metrics will help you to track your optimization efforts and ensure that they are providing value to the organization.

There are two types of metrics that are useful for data architects to track and measure: program metrics and project metrics. Program metrics represent the activities that the data architecture program, which is the sum of multiple projects, should help to improve. Project metrics are the more granular metrics that track each project.

Use Tab 6. Metrics of the Data Architecture Tactical Roadmap Tool to document and track metrics associated with your optimization tactics.

Use Info-Tech’s resources to build your data architecture capabilities

The following resources from Info-Tech can be used to improve the capabilities that were identified as having a gap. Read more about the details of the five-tier architecture in the blueprints below:

With the optimal tactics identified, the monetary authority uncovered areas needing improvement

CASE STUDY

Industry: Financial Source: Info-Tech Consulting

Part 2

After establishing the appropriate tactics based on its business driver, the monetary authority was able to identify its shortcomings and adopt resolutions to remedy the issues.

Establishing these solutions provided the organization with necessary information to build their roadmap and move towards implementing an optimized data architecture.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech Workshop

Book a workshop with our Info-Tech analysts:

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team. Info-Tech analyst will join you and your team onsite at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop. Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

2.1.1 – 2.2.2		Evaluate your current capabilities and design your target data quality practice from two angles In this assessment and planning activity, the team will evaluate the current and target capabilities for your data architecture’s ability to meet business needs based on the essential capabilities across the five tiers of an organization’s architectural environment.
2.2.3		Create metrics to track the success of your optimization plan. The Info-Tech facilitator will guide you through the process of creating program and project metrics to track as you optimize your data architecture. This will help to ensure that the tactics are helping to improve crucial business attributes.

Build a Business-Aligned Data Architecture Optimization Strategy

PHASE 3

Create Your Tactical Data Architecture Roadmap

Phase 3 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 3: Create Your Tactical Data Architecture Roadmap

Proposed Time to Completion: 2 weeks

Phase 3, Step 1: Personalize Your Data Architecture Roadmap

This step will walk you through the following activities:

• Determine the timing, effort, and ownership of the recommended optimization initiatives.
• Brainstorm initiatives that are not yet on the roadmap but apply to you.

This step involves the following participants:

• Data Architect
• DBAs
• Enterprise Architect

Outcomes of this step

• A roadmap of specific initiatives that map to the tactical plan for optimizing your organization’s data architecture.
• A plan for communicating high-level business objectives to data workers to address the issues of the business.

Now that you have tactical priorities, identify the actionable steps that will lead you to an optimized data architecture

Phase 1 and 2 helped you to identify tactics that address some of the most common business drivers. Phase 3 will bring you through the process of practically planning what those tactics look like in your organization’s environment and create a roadmap to plan how you will generate business value through optimization of your data architecture environment.

Use the Data Architecture Tactic Roadmap Tool to personalize your roadmap

Generating Your Roadmap On Tab 5. Tactic and Initiative Planning, you will find a list of tactics that correspond to every capability that applies to your chosen driver and where there is a gap. In addition, each tactic has a sequence of “Suggested Initiatives,” which represent the best-practice steps that you should take to optimize your data architecture according to your priorities and gaps. Customize this list of initiatives according to your needs. The Gantt chart is generated in Tab 7. Initiative Roadmap, and can be used to organize your plan and ensure that all of the essential aspects of optimizing data architecture are addressed. The roadmap can be used as an “executive brief” roadmap and as a communication tool for the business.

Tab 5. Tactic and Initiative Planning Tab 7. Initiative Roadmap

Determine the details of your data architecture optimization activities

3.1.2 1 hour

INPUT: Timing of initiatives for optimizing data architecture.

OUTPUT: Optimization roadmap

Materials: Data Architecture Tactic Roadmap Tool

Participants: Data architect, Enterprise Architect

Instructions

1. With the list of suggested activities in place on Tab 5. Tactic and Initiative Planning, select whether or not the initiatives will be included in the roadmap. By default, all of the initiatives are set to “Yes.”
2. Plan the sequence, starting time, and length of each initiative, as well as the assigned responsibility of the initiative in Tab 5. Tactic and Initiative Planning of the Data Architecture Tactic Roadmap Tool.
3. The tool will a generate a Gantt chart based on the start and length of your initiatives.
4. The Gantt chart is generated in Tab 7. Initiative Roadmap.

Tab 5. Tactic and Initiative Planning

Tab 7. Initiative Roadmap

Info-Tech Insight

The activities that populate the roadmap can be taken as best practice activities. If you want an actionable, comprehensive, and prescriptive plan for optimizing your data architecture, fill in the timing of the activities and print the roadmap. This can serve as a rapid communication tool for your data architecture plan to the business and other architects.

Optimizing data architecture relies on communication between the business and data workers

Remember: Data architects bridge the gap between strategic and technical requirements of data. Therefore, as you plan the data and its interactions with applications, it is imperative that you communicate the plan and its implications to the business and the data workers.

Also remember: In Phase 1, you built your tactical data architecture optimization plan. Use this document to communicate your plan for data architecture optimization to both the business and the data workers. Socialize this document as a representation of your organization’s current data architecture as well as where it is headed in the future.

Communicate your data architecture optimization plan to the business for approval

INPUT: Data Architecture Tactical Roadmap

OUTPUT: Communication plan

Materials: Data Architecture Optimization Template

Participants: Data Architect, Business representatives, IT representatives

Instructions Begin by presenting your plan and roadmap to the business units who participated in business interviews in activity 1.1.3 of Phase 1. If you receive feedback that suggests that you should make revisions to the plan, consult Info-Tech Research Group for suggestions on how to improve the plan. If you gain approval for the plan, communicate it to DBAs and other data workers.

Iterative optimization and communication plan:

With a roadmap in place, the monetary authority followed a tactical and practical plan to repair outdated data architecture

CASE STUDY

Industry: Financial Source: Info-Tech Consulting

Part 3

After establishing the appropriate tactics based on its business driver, the monetary authority was able to identify its shortcomings and adopt resolutions to remedy the issues.

Phase 3, Step 2: Manage Your Data Architecture Decisions and the Resulting Changes

This step will walk you through the following activities:

• With a plan in place, document the major architectural decisions that have been and will be made to optimize data architecture.
• Create a plan for change and release management, an essential function of the data architect role.

This step involves the following participants:

• Data Architect
• Enterprise Architect

Outcomes of this step

• Resources for documenting and managing the inevitable change associated with updates to the organization’s data architecture environment.

To implement data architecture changes, you must plan to accommodate the issues that come with change

Once you have a plan in place, one the most challenging aspects of improving an organization is yet to come…overcoming change!

“When managing change, the job of the data architect is to avoid unnecessary change and to encapsulate necessary change.

You must provide motivation for simplifying change, making it manageable for the whole organization.” (Andrew Johnston, Independent Consultant)

Create roadmap Communicate roadmap Implement roadmap Change management

Use the Data Architecture Decision Template when architectural changes are made

Document the architectural decisions made to provide context around changes made to the organization’s data environment. The goal of this Data Architecture Decision Template is to provide data architects with a template for managing the changes that accompany major architectural decisions. As you work through the Build a Business-Aligned Data Architecture Optimization Strategy blueprint, you will create a plan for tactical initiatives that address the drivers of the business to optimize your data architecture. This plan will bring about changes to the organization’s data architecture that need change management considerations. Document any major changes to the organization’s data architecture that are required to evolve with the organization’s drivers. This will ensure that major architectural changes are documented, tracked, and that the context around the decision is maintained. “Environment is very chaotic nowadays – legacy apps, sprawl, ERPs, a huge mix and orgs are grappling with what our data landscape look like? Where are our data assets that we need to use?” (Andrew Johnston, Independent Consultant)

Use Info-Tech’s Data Architecture Decision Template to document any major changes in the organization’s data architecture.

Leverage Info-Tech’s resources to smooth change management

As changes to the architectural environment occur, data architects must stay ahead of the curve and plan the change management considerations that come with major architectural decisions.

“When managing change, the job of the data architect is to avoid unnecessary change and to encapsulate necessary change.

You must provide motivation for simplifying change, making it manageable for the whole organization.” (Andrew Johnston, Independent Consultant)

Change Management Blueprint	Change Management Roadmap Tool

Use Info-Tech’s resources for effective release management

As changes to the architectural environment occur, data architects must stay ahead of the curve and plan the release management considerations around new hardware and software releases or updates.

Release management is a process that encompasses the planning, design, build, configuration, and testing of hardware and software releases to create a defined set of release components (ITIL). Release activities can include the distribution of the release and supporting documentation directly to end users. See Info-Tech’s resources on Release Management to smooth changes:

Release Management Blueprint	Release Management Process Standard Template

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech Workshop

Book a workshop with our Info-Tech analysts:

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team. Info-Tech analyst will join you and your team onsite at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop. Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

3.1.1		Create your personalized roadmap of activities. In this activity, the facilitator will guide the team in evaluating practice gaps highlighted by the assessment, and compare these gaps at face value so general priorities can be documented. The same categories as in 3.1.1 are considered.
3.1.3		Communicate your data architecture optimization plan. The facilitator will help you to identify the optimal medium and timing for communicating your plan for optimizing your data architecture.

Insight breakdown

Insight 1

• Data architecture needs to evolve along with the changing business landscape. There are four common business drivers that put most pressure on archaic architectures. As a result, the organization’s architecture must be flexible and responsive to changing business needs.

Insight 2

• Data architecture is not just about models.
  Viewing data architecture as just technical data modeling can lead to structurally unsound data that does not serve the business.

Insight 3

• Data is used differently across the layers of an organization’s data architecture, and the capabilities needed to optimize use of data change with it. Architecting and managing data from source to warehousing to presentation requires different tactics for optimal use.

Summary of accomplishment

Knowledge Gained

• An understanding of what data architecture is, how data architects can provide value to the organization, and how data architecture fits into the larger enterprise architecture picture.
• The capabilities required for optimization of the organization’s data architecture across the five tiers of the logical data architecture model.

Processes Optimized

• Prioritization and planning of data architect responsibilities across the five tiers of the five-tier logical data architecture model.
• Roadmapping of tactics that address the most common business drivers of the organization.
• Architectural change management.

Deliverables Completed

• Data Architecture Driver Pattern Identification Tool
• Data Architecture Optimization Template
• Data Architecture Trends Presentation
• Data Architecture Roadmap Tool
• Data Architecture Decision Template

Research contributors and experts

Ron Huizenga, Senior Product Manager Embarcadero Technologies, Inc. Ron Huizenga has over 30 years of experience as an IT executive and consultant in enterprise data architecture, governance, business process reengineering and improvement, program/project management, software development, and business management. His experience spans multiple industries including manufacturing, supply chain, pipelines, natural resources, retail, healthcare, insurance, and transportation.

Andrew Johnston, Architect Independent Consultant An independent consultant with a unique combination of managerial, commercial, and technical skills, Andrew specializes in the development of strategies and technical architectures that allow businesses to get the maximum benefit from their IT resources. He has been described by clients as a "broad spectrum" architect, summarizing his ability to engage in many problems at many levels.

Research contributors

Internal Contributors
	Steven J. Wilson, Senior Director, Research & Advisory Services Daniel Ko, Research Manager Bernie Gilles, Senior Director, Research & Advisory Services
External Contributors
	Ron Huizenga, Embercardo Technologies Andrew Johnston, Independent Consultant Darrell Enslinger, Government Employees Health Association Anonymous Contributors

Bibliography

Allen, Mark. “Get the ETL Out of Here.” MarkLogic. Sep, 2016. Web. 25 Apr 2017.[http://www.marklogic.com/blog/get-the-etl-out-of-here/]

Anadiotis, George. “Streaming hot: Real-time big data architecture matters.” ZDNet. Jan, 2017. Web. 25 Apr 2017. [http://www.zdnet.com/article/streaming-hot-real-time-big-data-architecture-matters/]

Aston, Dan. “The Economic value of Enterprise Architecture and How to Show It.” Erwin. Aug, 2016. Web. 20 Apr 2017. [http://erwin.com/blog/economic-value-enterprise-architecture-show/]

Baer, Tony. “2017 Trends to Watch: Big Data.” Ovum. Nov, 2016. Web. 25 Apr 2017.

Bmc. “Benefits & Advantages of Hadoop.” Bmc. Web. 25 Apr 2017. [http://www.bmcsoftware.ca/guides/hadoop-benefits-business-case.html]

Boyd, Ryan, et al. “Relational vs. Graph Data Modeling” DZone. Mar 2016. Web. 25 Apr 2017. [https://dzone.com/articles/relational-vs-graph-data-modeling]

Brahmachar, Satya. “Theme To Digital Transformation - Journey to Data Driven Enterprise” Feb, 2015. Web. 20 Apr 2017. [http://satyabrahmachari-thought-leader.blogspot.ca/2015/02/i-smac-theme-to-digital-transformation.html]

Capsenta. “NoETL.” Capsenta. Web. 25 Apr 2017. [https://capsenta.com/wp-content/uploads/2015/03/Capsenta-Booklet.pdf]

Connolly, Shaun. “Implementing the Blueprint for Enterprise Hadoop” Hortonworks. Apr, 2014. Web. 25 Apr 2017. https://hortonworks.com/blog/implementing-the-blue...

Forbes. “Cloud 2.0: Companies Move From Cloud-First To Cloud-Only.” Forbes. Apr, 2017. Web. 25 Apr 2017. [https://www.forbes.com/sites/vmware/2017/04/07/cloud-2-0-companies-move-from-cloud-first-to-cloud-only/#5cd9d94a4d5e]

Forgeat, Julien. “Lambda and Kappa.” Ericsson. Nov 2015. Web 25 Apr 2017. [https://www.ericsson.com/research-blog/data-knowledge/data-processing-architectures-lambda-and-kappa/]

Grimes, Seth. “Is It Time For NoETL?” InformationWeek. Mar, 2010. Web. 25 Apr 2017. [http://www.informationweek.com/software/information-management/is-it-time-for-noetl/d/d-id/1087813]

Gupta, Manav. et al. “How IB‹ leads in building big data analytics solutions in the cloud.” IBM. Feb, 2016. Web. 25 Apr 2017. [https://www.ibm.com/developerworks/cloud/library/cl-ibm-leads-building-big-data-analytics-solutions-cloud-trs/index.html#N102DE]

“How To Build A Roadmap.” Hub Designs Magazine. Web 25 Apr 2017. [https://hubdesignsmagazine.com/2011/03/05/how-to-build-a-roadmap/]

IBM. “Top industry use cases for stream computing.” IBM. Oct, 2015. Web. 25 Apr 2017. [https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=IMW14704USEN]

Mateos-Garcia, Juan, et al. “Skills Of The Datavores.” Nesta. July. 2015. Web. 8 Aug 2016. [https://www.nesta.org.uk/sites/default/files/skills_of_the_datavores.pdf].

Maynard, Steven. “Analytics: Don’t Forget The Human Element” Forbes. 2015. Web. 20 Apr. 2017. [http://www.ey.com/Publication/vwLUAssets/EY-Forbes-Insights-Data-and-Analytics-Impact-Index-2015/$FILE/EY-Forbes-Insights-Data-and-Analytics-Impact-Index-2015.pdf]

Neo4j. “From Relational to Neo4j.” Neo4j. Web. 25 Apr 2017. [https://neo4j.com/developer/graph-db-vs-rdbms/#_from_relational_to_graph_databases]

NoETL “NoETL.” NoETL. Web. 25 Apr 2017. [http://noetl.org/]

Nolan, Roger. “Digital Transformation: Is Your Data Management Ready?” Informatica. Jun, 2016. Web. 20 Apr 2017. [https://blogs.informatica.com/2016/06/10/digital-transformation-data-management-ready/#fbid=hmBYQgS6hnm]

OpsClarity. “2016 State of Fast Data & Streaming Applications.” OpsClarity. Web. 25 Apr 2017. [https://www.opsclarity.com/wp-content/uploads/2016/07/2016FastDataSurvey.pdf]

Oracle. “A Relational Database Overview.” Oracle. Web. 25 Apr 2017. [https://docs.oracle.com/javase/tutorial/jdbc/overview/database.html]

Ponemon Institute LLC. “Big Data Cybersecurity Analytics Research Repor.t” Cloudera. Aug, 2016. Web. 25 Apr 2017. [https://www.cloudera.com/content/dam/www/static/documents/analyst-reports/big-data-cybersecurity-analytics-research-report.pdf]

Sanchez, Jose Juan. “Data Movement Killed the BI Star.” DV Blog. May, 2016. Web. 20 Apr. 2017. [http://www.datavirtualizationblog.com/data-movement-killed-the-bi-star/]

SAS. “Hadoop; What it is and why does it matter?” SAS. Web. 25 Apr 2017. [https://www.sas.com/en_ca/insights/big-data/hadoop.html#hadoopusers]

Schumacher, Robin. “A Quick Primer on graph Databases for RDBMS Professionals.” Datastax. Jul, 2016. Web. 25 Apr 2017. [http://www.datastax.com/2016/07/quick-primer-on-graph-databases-for-rdbms-professionals]

Swoyer, Steve. “It’s the End of the Data Warehouse as We Know It.” TDWI. Jan, 2017. Web. 20 Apr. 2017. [https://upside.tdwi.org/articles/2017/01/11/end-of-the-data-warehouse-as-we-know-it.aspx]

Webber, Jim, and Ian Robinson. “The Top 5 Use Cases of Graph Databases.” Neo4j. 2015. Web. 25 Apr 2017. [http://info.neo4j.com/rs/773-GON-065/images/Neo4j_Top5_UseCases_Graph%20Databases.pdf]

Zachman Framework. [https://www.zachman.com/]

Zupan, Jane. “Survey of Big Data Decision Makers.” Attiv/o. May, 2016. Web. 20 Apr 2017. [https://www.attivio.com/blog/post/survey-big-data-decision-makers]

Decide if You Are Ready for SAFe

Approach the Scaled Agile Framework (SAFe) with open eyes and an open wallet.

Analyst Perspective

Ensure that SAFe is the right move before committing.

Waterfall is dead. Or obsolete at the very least.

Organizations cannot wait months or years for product, service, application, and process changes. They need to embrace business agility to respond to opportunities more quickly and deliver value sooner. Agile established values and principles that have promoted smaller cycle times, greater connections between teams, improved return on investment (ROI) prioritization, and improved team empowerment.

Where organizations continue to struggle is matching localized Scrum teams with enterprise initiatives. This struggle is compounded by legacy executive planning cycles, which undermine Agile team authority. SAFe has provided a series of frameworks to help organizations deal with these issues. It combines enterprise planning and alignment with cross-team collaboration.

Don't rely on popularity or marketing to make your scaled Agile decision. SAFe is a highly disruptive transformation, and it requires extensive training, coaching, process changes, and time to implement. Without the culture shift to an Agile mindset at all levels, SAFe becomes a mirror of Waterfall processes dressed in SAFe names. Furthermore, SAFe itself will not fix problems with communication, requirements, development, testing, release, support, or governance. You will still need to fix these problems within the SAFe framework to be successful.

Hans Eckman
Principal Research Director, Applications Delivery and Management
Info-Tech Research Group

Executive Summary

Info-Tech Insight
SAFe is a highly disruptive enterprise transformation, and it won't solve your organizational delivery challenges by itself. Start with an open mind, and understand what is needed to support a multi-year cultural transition. Decide how far and how fast you are willing to transform, and make sure that you have the right transformation and coaching partner in place. There is no right software development lifecycle (SDLC) or methodology. Find or create the methodology that best aligns to your needs and goals.

Agile's Four Core Values

"...while there is value in the items on the right, we value the items on the left more."
- The Agile Manifesto

STOP! If you're not Agile, don't start with SAFe.

Successful SAFe requires an Agile mindset at all levels.

Be aware of common myths around Agile and SAFe

SAFe does not...

1...solve development and communication issues.

2...ensure that you will finish requirements faster.

3...mean that you do not need planning and documentation.

"Without proper planning, organizations can start throwing more resources at the work, which spirals into the classic Waterfall issues of managing by schedule."
– Kristen Morton, Associate Implementation Architect,
OneShield Inc. (Info-Tech Interview)

Info-Tech Insight
Poor culture, processes, governance, and leadership will disrupt any methodology. Many drivers for SAFe could be solved by improving and standardizing development and release management within current methodologies.

Review the drivers that are motivating your organization to adopt and scale Agile practices

Functional groups have their own drivers to adopt Agile development processes, practices, and techniques (e.g. to improve collaboration, decrease churn, or increase automation). Their buy-in to scaling Agile is just as important as the buy-in of stakeholders.

If a group's specific needs and drivers are not addressed, its members may develop negative sentiments toward Agile development. These negative sentiments can affect their ability to see the benefits of Agile, and they may return to their old habits once the opportunity arises.

It is important to find opportunities in which both business objectives and functional group drivers can be achieved by scaling Agile development. This can motivate teams to continuously improve and adhere to the new environment, and it will maintain business buy-in. It can also be used to justify activities that specifically address functional group drivers.

Examples of Motivating Drivers for Scaling Agile

• Improve artifact handoffs between development and operations.
• Increase collaboration among development teams.
• Reveal architectural and system risks early.
• Expedite the feedback loop from support.
• Improve capacity management.
• Support development process innovation.
• Create a safe environment to discuss concerns.
• Optimize value streams.
• Increase team engagement and comradery.

Don't start with scaled Agile!

Scaling Agile is a way to optimize product management and product delivery in application lifecycle management practices. Do not try to start with SAFe when the components are not yet in place.

Scale Agile delivery to improve cross-functional dependencies and releases

Top Business Concerns When Scaling Agile

1 Organizational Culture: The current culture may not support team empowerment, learning from failure, and other Agile principles. SAFe also allows top-down decisions to persist.

2 Executive Support: Executives may not dedicate resources, time, and effort into removing obstacles to scaling Agile because of lack of business buy-in.

3 Team Coordination: Current collaboration structures may not enable teams and stakeholders to share information freely and integrate workflows easily.

4 Business Misalignment: Business vision and objectives may be miscommunicated early in development, risking poorly planned and designed initiatives and low-quality products.

Extending collaboration is the key to success.

Uniting stakeholders and development into a single body is the key to success. Assess the internal and external communication flow and define processes for planning and tracking work so that everyone is aware of how to integrate, communicate, and collaborate.

The goal is to enable faster reaction to customer needs, shorter release cycles, and improved visibility of the project's progress with cross-functional and diverse conversations.

Advantages of successful SAFe implementations

Once SAFe is complete and operational, organizations have seen measurable benefits:

• Multiple frameworks to support different levels of SAFe usage
• Deliberate and consistent planning and coordination
• Coordinating dependencies within value streams
• Reduced time to delivery
• Focus on customers and end users
• Alignment to business goals and value streams
• Increased employee engagement

Sources: TechBeacon, 2019; Medium, 2020; "Benefits," Scaled Agile, 2023;
"Pros and Cons," PremierAgile, n.d.; "Scaling Agile Challenges," PremierAgile, n.d.

Source: "Benefits," Scaled Agile, 2023

Recognize the difference between Scrum teams and the Scaled Agile Framework (SAFe)

SAFe provides a framework that aligns Scrum teams into coordinated release trains driven by top-down prioritization.

Develop Your Agile Approach for a Successful Transformation

Source: Scaled Agile, Inc.

Info-Tech's IT Management & Governance Framework

Info-Tech Insight
SAFe is an enterprise, culture, and process transformation that impacts all IT services. Some areas of Info-Tech's IT Management & Governance Framework have higher impacts and require special attention. Plan to include transformation support for each of these topics during your SAFe implementation. SAFe will not fix broken processes on its own.

Without adopting an Agile mindset, SAFe becomes Waterfall with SAFe terminology

Source: Scaled Agile, Inc.

Info-Tech Insight
When first implementing SAFe, organizations reproduce their organizational design and Waterfall delivery structures with SAFe terms:

• Delivery Manager = Release Train Engineer
• Stakeholder/Sponsor = Product Manager
• Release = Release Train
• Project/Program = Project or Portfolio

SAFe isn't without risks or challenges

Risks and Causes of Failed SAFe Transformations

• SAFe conflicts with legacy cultures and delivery processes.
• SAFe promotes continued top-down decisions, undermining team empowerment.
• Scaled product families are required to define proper value streams.
• Team empowerment and autonomy are reduced.
• SAFe activities are poorly executed.
• There are high training and coaching costs.
• Implementation takes a long time.
• End-to-end delivery management tools aligned to SAFe are required.
• Legacy delivery challenges are not specifically solved with SAFe.
• SAFe is designed to work for large-scale development teams.

Challenges

• Adjusting to a new set of terms for common roles, processes, and activities
• Executing planning cycles
• Defining features and epics at the right level
• Completing adequate requirements
• Defining value streams
• Coordinating releases and release trains
• Providing consistent quality

Sources: TechBeacon, 2019; Medium, 2020; "Benefits," Scaled Agile, 2023;
"Pros and Cons," PremierAgile, n.d.; "Scaling Agile Challenges," PremierAgile, n.d.

Focus on your core competencies instead

Before undertaking an enterprise transformation, consider improving the underlying processes that will need to be fixed anyway. Fixing these areas while implementing SAFe compounds the effort and disruption.

Product Delivery

• Agile/DevOps Research Center
• Develop Your Agile Approach for a Successful Transformation
  • Understand Agile fundamentals, principles, and practices so you can apply them effectively in your organization.
• Implement DevOps Practices That Work
  • Streamline business value delivery through the strategic adoption of DevOps practices.

Product Management

• Product Lifecycle Management Research Center
• Make the Case for Product Delivery
  • Align your organization on the practices to deliver what matters most.
• Deliver on Your Digital Product Vision
  • Build a product vision your organization can take from strategy through execution.
• Deliver Digital Products at Scale
  • Deliver value at the scale of your organization through defining enterprise product families.
• Introduce Program Management to Your Organization
  • Use programs to align projects to your strategic goals.
• Optimize IT Project Intake, Approval, and Prioritization
  • Decide which IT projects to approve and when to start them.
• Manage Requirements in an Agile Environment
  • Agile and requirements management are complementary, not competitors.
• Build a Software Quality Assurance Program
  • Build quality into every step of your SDLC.
• Automate Testing to Get More Done
  • Drive software delivery throughput and quality confidence by extending your automation test coverage.
• Application Portfolio Management Foundations
  • Ensure your application portfolio delivers the best possible return on investment.

"But big-bang transitions are hard. They require total leadership commitment, a receptive culture, enough talented and experienced agile practitioners to staff hundreds of teams without depleting other capabilities, and highly prescriptive instruction manuals to align everyone's approach."
– "Agile at Scale," Harvard Business Review

Insight Summary

Overarching insight
SAFe is a highly disruptive enterprise transformation, and it will not solve your organizational delivery challenges by itself. Start with an open mind, and understand what is needed to support a multi-year cultural transition. Decide how far and fast you are willing to transform and make sure that you have the right transformation and coaching partner in place.

SAFe conflicts with core Agile principles.
The popularity of SAFe is largely due to its structural resemblance to enterprise portfolio and project planning with top-down prioritization and decision-making. This directly conflicts with Agile's purpose and principles of empowerment and agility.

SAFe and Agile will not solve enterprise delivery challenges.
Poor culture, processes, governance, and leadership will disrupt any methodology. Many issues with drivers for SAFe could be solved by improving development and release management within current methodologies.

Most organizations should not be using a pure SAFe framework
Few organizations are capable of, or should be, applying a pure SAFe framework. Successful organizations have adopted and modified SAFe frameworks to best fit their needs, teams, value streams, and maturity.

Without an Agile mindset, SAFe will be executed as Waterfall stages using SAFe terminology.
Groups that "Do Agile" are not likely to embrace the behavioral changes needed to make any scaled framework effective. SAFe becomes a series of Waterfall PIs using SAFe terminology.

Your transformation does not start with SAFe.
Start your transition to scaled Agile with a maturity assessment for current delivery practices. Fixing broken process, tools, and teams must be at the heart of your initiative.

Blueprint Deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Key Deliverable

SAFe Transformation Playbook

Build a transformation and organizational change management plan to guide your transition. Define clear ownership for every critical step.

Scaled Agile Readiness Assessment

Conduct the Agile readiness survey. Without an Agile mindset, SAFe will follow Waterfall or WaterScrumFall practices.

Case Study

Spotify's approach to Agile at scale

INDUSTRY: Digital Media
SOURCE: Unified Communications and Collaborations

Spotify's Scaling Agile Initiative

With rapid user adoption growth (over 15 million active users in under six years), Spotify had to find a way to maintain an Agile mindset across 30+ teams in three different cities, while maintaining the benefits of cross-functional collaboration and flexibility for future growth.

Spotify's Approach

Spotify found a fit-for-purpose way for the organization to increase team autonomy without losing the benefits of cross-team communication from economics of scale. Spotify focused on identifying dependencies that block or slow down work through a mix of reprioritization, reorganization, architectural changes, and technical solutions. The organization embraced dependencies that led to cross-team communication and built in the necessary flexibility to allow Agile to grow with the organization.

Spotify's scaling Agile initiative used interview processes to identify what each team depended on and how those dependencies blocked or slowed the team.

Squad refers to an autonomous Agile release team in this case study.

Case Study

Suncorp instilled dedicated communication streams to ensure cross-role collaboration and culture.

INDUSTRY: Insurance
SOURCE: Agile India, International Conference on Agile and Lean Software Development, 2014

Case Study

Nationwide embraces DevOps and improves software quality.

INDUSTRY: Insurance
SOURCE: Agile India, International Conference on Agile and Lean Software Development, 2014

Info-Tech offers various levels of support to best suit your needs

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is one to four calls over the course of one to six weeks.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Supporting Your Agile Journey

Enable Product Agile Delivery Executive Workshop	Develop Your Agile Approach	Spread Best Practices with an Agile Center of Excellence	Implement DevOps Practices That Work	Enable Organization-Wide Collaboration by Scaling Agile
Align and prepare your IT leadership teams. Audience: Senior and IT delivery leadership Size: 8-16 people Time: 7 hours	Tune Agile team practices to fit your organization culture. Audience: Agile pilot teams and subject matter experts (SMEs) Size: 10-20 people Time: 4 days	Leverage Agile thought leadership to expand your best practices. Audience: Agile SMEs and thought leaders Size: 10-20 people Time: 4 days	Build a continuous integration and continuous delivery pipeline. Audience: Product owners (POs) and delivery team leads Size: 10-20 people Time: 4 days	Execute a disciplined approach to rolling out Agile methods. Audience: Agile steering team and SMEs Size: 3-8 people Time: 3 hours

Sample agendas are included in the following sections for each of these topics.

Your Product Transformation Journey

Phase 1

Determine if SAFe Is Right for Your Organization

Phase 1
1.1 Understand where SAFe fits into your delivery methodologies and SDLCs
1.2 Determine if you are ready for SAFe (fit for purpose)

This phase will walk you through the following activities:

• 1.1.1 Define your primary drivers for SAFe.
• 1.1.2 Create your own list of pros and cons of SAFe.
• 1.2.1 Assess your Agile readiness.
• 1.2.2 Define enablers and blockers for scaling Agile delivery.
• 1.2.3 Estimate your SAFe implementation risk.
• 1.2.4 Start your SAFe implementation plan.

This phase involves the following participants:

• Senior leadership
• IT leadership
• Project Management Office
• Delivery managers
• Product managers/owners
• Agile thought leaders and coaches
• Compliance teams leads

Step 1.1

Understand where SAFe fits into your delivery methodologies and SDLCs

Activities
1.1.1 Define your primary drivers for SAFe
1.1.2 Create your own list of pros and cons of SAFe

This step involves the following participants:

• IT leadership
• Delivery managers
• Project management office
• Product owners and managers
• Development team leads
• Portfolio managers
• Architects

Outcomes of this step:

• List of primary drivers for SAFe
• List of pros and cons of SAFe

Agile's Four Core Values

"...while there is value in the items on the right, we value the items on the left more."
– The Agile Manifesto

STOP! If you're not Agile, don't start with SAFe.

Successful SAFe requires an Agile mindset at all levels.

Be aware of common myths around Agile and SAFe

SAFe does not...

1...solve development and communication issues.

2...ensure that you will finish requirements faster.

3...mean that you do not need planning and documentation.

"Without proper planning, organizations can start throwing more resources at the work, which spirals into the classic Waterfall issues of managing by schedule."
– Kristen Morton, Associate Implementation Architect,
OneShield Inc. (Info-Tech Interview)

Info-Tech Insight
SAFe only provides a framework and steps where these issues can be resolved.

The importance of values and principles

Modern development practices (such as Agile, Lean, and DevOps) are based on values and principles. This supports the move away from command-and-control management to self-organizing teams.

Values

• Values represent your team's core beliefs and capture what you want to instill in your team.

Principles

• Principles represent methods for solving a problem or deciding.
• Given that principles are rooted in specifics, they can change more frequently because they are both fallible and conducive to learning.

Consider the guiding principles of your application team

Teams may have their own perspectives on how they deliver value and their own practices for how they do this. These perspectives can help you develop guiding principles for your own team to explain your core values and cement your team's culture. Guiding principles can help you:

• Enable the appropriate environment to foster collaboration within current organizational, departmental, and cultural constraints
• Foster the social needs that will engage and motivate your team in a culture that suits its members
• Ensure that all teams are driven toward the same business and team goals, even if other teams are operating differently
• Build organizational camaraderie aligned with corporate strategies

Info-Tech Insight
Following methodologies by the book can be detrimental if they do not fit your organization's needs, constraints, and culture. The ultimate goal of all teams is to deliver value. Any practices or activities that drive teams away from this goal should be removed or modified.

Review the drivers that are motivating your organization to adopt and scale Agile practices

Functional groups have their own drivers to adopt Agile development processes, practices, and techniques (e.g. to improve collaboration, decrease churn, or increase automation). Their buy-in to scaling Agile is just as important as the buy-in of stakeholders.

By not addressing a group's specific needs and drivers, the resulting negative sentiments of its members toward Agile development can affect their ability to see the benefits of Agile and they may return to old habits once the opportunity arises.

Find opportunities in which both business objectives and functional group drivers can be achieved with scaling Agile development. This alignment can motivate teams to continuously improve and adhere to the new environment, and it will maintain business buy-in. This assessment can also be used to justify activities that specifically address functional group drivers.

Examples of Motivating Drivers for Scaling Agile

• Improve artifact hand-offs between development and operations.
• Increase collaboration among development teams.
• Reveal architectural and system risks early.
• Expedite the feedback loop from support.
• Improve capacity management.
• Support development process innovation.
• Create a safe environment to discuss concerns.
• Optimize value streams.
• Increase team engagement and comradery.

Exercise 1.1.1 Define your primary drivers for SAFe

30 minutes

• Brainstorm a list of drivers for scaling Agile.
• Build a value canvas to help capture and align team expectations.
• Identify jobs or functions that will be impacted by SAFe.
• List your current pains and gains.
• List the pain relievers and gain creators.
• Identify the deliverable needed for a successful transformation.
• Complete your SAFe value canvas in your SAFe Transformation Playbook.

Enter the results in your SAFe Transformation Playbook.

SAFe Value Canvas Template

Case Study

A public utilities organization steadily lost stakeholder engagement, diminishing product quality.

INDUSTRY: Public Utilities
SOURCE: Info-Tech Expert Interview

Challenge

• The goal of a public utilities organization was to adopt Agile so it could quickly respond to changes and trim costs.
• The organization decided to scale Agile using a structured approach. It began implementation with IT teams that were familiar with Agile principles and leveraged IT seniors as Agile champions. To ensure that Agile principles were widespread, the organization decided to develop a training program with vendor assistance.
• As Agile successes began to be seen, the organization decided to increase the involvement of business teams gradually so it could organically grow the concept within the business.

Results

• Teams saw significant success with many projects because they could easily demonstrate deliverables and clearly show the business value. Over time, the teams used Agile for large projects with complex processing needs.
• Teams continued to deliver small projects successfully, but business engagement waned over time. Some of the large, complex applications they delivered using Agile lacked the necessary functionality and appropriate controls and, in some cases, did not have the ability to scale due to a poor architectural framework. These applications required additional investment, which far exceeded the original cost forecasts.

While Agile and product development are intertwined, they are not the same!

Delivering products does not necessarily require an Agile mindset. However, Agile methods help to facilitate the journey because product thinking is baked into them.

Recognize the difference between Scrum teams and the Scaled Agile Framework (SAFe)

SAFe provides a framework that aligns Scrum teams into coordinated release trains driven by top-down prioritization.

Develop Your Agile Approach for a Successful Transformation

Without adopting an Agile mindset, SAFe becomes Waterfall with SAFe terminology

Info-Tech Insight
When first implementing SAFe, organizations reproduce their organizational design and Waterfall delivery structures with SAFe terms:

• Delivery Manager = Release Train Engineer
• Stakeholder/Sponsor = Product Manager
• Release = Release Train
• Project/Program = Project or Portfolio

Advantages of successful SAFe implementations

Once SAFe is complete and operational, organizations have seen measurable benefits:

• Multiple frameworks to support different levels of SAFe usage
• Deliberate and consistent planning and coordination
• Coordinating dependencies within value streams
• Reduced time to delivery
• Focus on customers and end users
• Alignment to business goals and value streams
• Increased employee engagement

Sources: TechBeacon, 2019; Medium, 2020; "Benefits," Scaled Agile, 2023;
"Pros and Cons," PremierAgile, n.d.; "Scaling Agile Challenges," PremierAgile, n.d.

Source: "Benefits," Scaled Agile, 2023

SAFe isn't without risks or challenges

Risks and Causes of Failed SAFe Transformations

• SAFe conflicts with legacy cultures and delivery processes.
• SAFe promotes continued top-down decisions, undermining team empowerment.
• Scaled product families are required to define proper value streams.
• Team empowerment and autonomy are reduced.
• SAFe activities are poorly executed.
• There are high training and coaching costs.
• Implementation takes a long time.
• End-to-end delivery management tools aligned to SAFe are required.
• Legacy delivery challenges are not specifically solved with SAFe.
• SAFe is designed to work for large-scale development teams.

Challenges

• Adjusting to a new set of terms for common roles, processes, and activities
• Executing planning cycles
• Defining features and epics at the right level
• Completing adequate requirements
• Defining value streams
• Coordinating releases and release trains
• Providing consistent quality

Sources: TechBeacon, 2019; Medium, 2020; "Benefits," Scaled Agile, 2023; "Pros and Cons," PremierAgile, n.d.; "Scaling Agile Challenges," PremierAgile, n.d.

Exercise 1.1.2 Create your own list of the pros and cons of SAFe

1 hour

Enter the results in your SAFe Transformation Playbook

Focus on your core competencies instead

Before undertaking an enterprise transformation, consider improving the underlying processes that will need to be fixed anyway. Fixing these areas while implementing SAFe compounds the effort and disruption.

Product Delivery

• Agile/DevOps Research Center
• Develop Your Agile Approach for a Successful Transformation
  • Understand Agile fundamentals, principles, and practices so you can apply them effectively in your organization.
• Implement DevOps Practices That Work
  • Streamline business value delivery through the strategic adoption of DevOps practices.

Product Management

• Product Lifecycle Management Research Center
• Make the Case for Product Delivery
  • Align your organization on the practices to deliver what matters most.
• Deliver on Your Digital Product Vision
  • Build a product vision your organization can take from strategy through execution.
• Deliver Digital Products at Scale
  • Deliver value at the scale of your organization through defining enterprise product families.
• Introduce Program Management to Your Organization
  • Use programs to align projects to your strategic goals.
• Optimize IT Project Intake, Approval, and Prioritization
  • Decide which IT projects to approve and when to start them.
• Managing Requirements in an Agile Environment
  • Agile and requirements management are complementary, not competitors.
• Build a Software Quality Assurance Program
  • Build quality into every step of your SDLC.
• Automate Testing to Get More Done
  • Drive software delivery throughput and quality confidence by extending your automation test coverage.
• Application Portfolio Management Foundations
  • Ensure your application portfolio delivers the best possible return on investment.

"But big-bang transitions are hard. They require total leadership commitment, a receptive culture, enough talented and experienced agile practitioners to staff hundreds of teams without depleting other capabilities, and highly prescriptive instruction manuals to align everyone's approach."
- "Agile at Scale," Harvard Business Review

Step 1.2

Determine if you are ready for SAFe (fit for purpose)

Activities
1.2.1 Assess your Agile readiness
1.2.2 Define enablers and blockers for scaling Agile delivery
1.2.3 Estimate your SAFe implementation risk
1.2.4 Start your SAFe implementation plan

This step involves the following participants:

• IT leadership
• Delivery managers
• Project management office
• Product owners and managers
• Development team leads
• Portfolio managers
• Architects

Outcomes of this step:

• Agile Readiness Assessment results
• Enablers and blockers for scaling Agile
• SAFe implementation risk
• SAFe implementation plan

Use CLAIM to guide your Agile journey

Conduct the Agile Readiness Assessment Survey

Without an Agile mindset, SAFe will follow Waterfall or WaterScrumFall practices.

• Start your journey with a clear understanding of the level of Agile and product maturity throughout your organization.
• Each area that lacks strength should be evaluated further and added to your journey map.

Exercise 1.2.1 Assess your Agile readiness

1 hour

• Open and complete the Agile Readiness Assessment in your playbook or the Excel tool provided.
• Discuss each area's high and low scores to reach a consensus.
• Record your results in your SAFe Transformation Playbook.

Enter the results in Scaled Agile Readiness Assessment.

Exercise 1.2.2 Define enablers and blockers for scaling Agile delivery

1 hour

• Identify and mitigate blockers for scaling Agile in your organization.
  • Identify enablers who will support successful SAFe transformation.
  • Identify blockers who will make the transition to SAFe more difficult.
  • For each blocker, define at least one mitigating step.

Enter the results in your SAFe Transformation Playbook

Estimate your SAFe implementation risk

Exercise 1.2.3 Estimate your SAFe implementation risk

30 minutes

• Determine which description best matches your overall organizational state.
• Enter the results in your SAFe Transformation Playbook.
• Change the text to bold in the cell you selected to describe your current state and/or add a border around the cell.

Enter the results in SAFe Transformation Playbook.

Interpret your SAFe implementation risks

Analyze your highlighted selections and patterns in the rows and columns. Use these factors to inform your SAFe implementation steps and timing.

Build your implementation plan

Build a transformation and organizational change management plan to guide your transition. Define clear ownership for every critical step.

Plan your transformation.

• Align stakeholders and thought leaders.
• Select an implementation partner.
• Insert critical steps.

Build your SAFe framework.

• Define your target SAFe framework.
• Customize your SAFe framework.
• Establish SAFe governance and reporting.
• Insert critical steps.

Implement SAFe practices.

• Define product families and value streams.
• Conduct SAFe training for:
  • Executive leadership
  • Agile SAFe coaches
  • Practitioners
• Insert critical steps.

For additional help with OCM, please download Master Organizational Change Management Practices.

Exercise 1.2.4 Start your SAFe implementation plan

30 minutes

• Using the high-level SAFE implementation framework, begin building out the critical steps.
• Record the results in your SAFe Transformation Playbook.
• Your playbook is an evergreen document to help guide your implementation. It should be reviewed often.

Enter the results in your SAFe Transformation Playbook

Select an implementation partner

Finding the right SAFe implementation partner is critical to your transformation success.

• Using your previous assessment, align internal and external resources to support your transformation.
• Select a partner who has experience in similar organizations and is aligned with your delivery goals.
• Plan to transition support to internal teams when SAFe practices have stabilized and moved into continuous improvement.
• Augment your transformation partner with internal coaches.
• Plan for a multiyear engagement before SAFe benefits are realized.

Summary of Accomplishments

Your journey begins.

Implementing SAFe is a long, expensive, and difficult process. For some organizations, SAFe provides the balance of leadership-driven prioritization and control with shorter release cycles and time to value. The key is making sure that SAFe is right for you and you are ready for SAFe. Few organizations fit perfectly into one of the SAFe frameworks. Instead, consider fine-tuning and customizing SAFe to meet your needs and gradual transformation.

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

Contact your account representative for more information.
workshops@infotech.com
1-888-670-8889

Additional Support

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech Workshop.

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.

Info-Tech analysts will join you and your team at your location or welcome you to Info-Tech's historic Toronto office to participate in an innovative onsite workshop.

Below are sample activities that will be conducted by Info-Tech analysts with your team:

Scaled Agile Delivery Readiness Assessment
This assessment will help identify enablers and blockers in your organizational culture using our CLAIM+G organization transformation model.

SAFE Value Canvas
Use a value campus to define jobs, pains, gains, pain relievers, gain creators, and needed deliverables to help inform and guide your SAFe transformation.

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Bibliography

"6 Biggest SAFe Agile Implementation Mistakes to Avoid." Triumph Strategic Consulting, 27 July 2017.

"The 7 Must-Haves for Achieving Scaling Agile Success." The 7 Must-Haves for Achieving Scaling Agile Success.

Ageling, Willem-Jan. "11 Most Common Reasons to Use Scaled Agile Framework (SAFE) and How to Do This With Unscaled Scrum." Medium, Serious Scrum, 26 Jan. 2020.

Agile India, International Conference on Agile and Lean Software Development, 2014.

"Air France - KLM - Agile Adoption with SAFe." Scaled Agile, 28 Nov. 2022.

"Application Development Trends 2019 - Global Survey Report." OutSystems.

"Benefits of SAFe: How It Benefits Organizations." Scaled Agile, 13 Mar. 2023.

Berkowitz, Emma. "The Cost of a SAFe(r) Implementation: CPRIME Blog." Cprime, 30 Jan. 2023.

"Chevron - Adopting SAFe with Remote Workforce." Scaled Agile, 28 Nov. 2022.

"Cisco It - Adopting Agile Development with SAFe." Scaled Agile, 13 Sept. 2022.

"CMS - Business Agility Transformation Using SAFe." Scaled Agile, 13 Sept. 2022.

Crain, Anthony. "4 Biggest Challenges in Moving to Scaled Agile Framework (SAFe)." TechBeacon, 25 Jan. 2019.

"The Essential Role of Communications ." Project Management Institute .

Gardiner, Phil. "SAFe Implementation: 4 Tips for Getting Started." Applied Frameworks, 20 Jan. 2022.

"How Do I Start Implementing SAFe?" Agility in Mind, 29 July 2022.

"How to Masterfully Screw Up Your SAFe Implementation." Wibas Artikel-Bibliothek, 6 Sept. 2022.

"Implementation Roadmap." Scaled Agile Framework, 14 Mar. 2023.

Islam, Ayvi. "SAFe Implementation 101 - The Complete Guide for Your Company." //Seibert/Media, 22 Dec. 2020.

"Johnson Controls - SAFe Implementation Case Study." Scaled Agile, 28 Nov. 2022.

"The New Rules and Opportunities of Business Transformation." KPMG.

"Nokia Software - SAFe Agile Transformation." Scaled Agile, 28 Nov. 2022.

Pichler, Roman. "What Is Product Management?" Romanpichler, 2014.

"Product Documentation." ServiceNow.

"Pros and Cons of Scaled Agile Framework." PremierAgile.

"Pulse of the Profession Beyond Agility." Project Management Institute.

R, Ramki. "Pros and Cons of Scaled Agile Framework (SAFe)." Medium, 3 Mar. 2019.

R, Ramki. "When Should You Consider Implementing SAFe (Scaled Agile Framework)?" Medium, Medium, 3 Mar. 2019.

Rigby, Darrell, Jeff Sutherland, and Andy Noble. "Agile at Scale: How to go from a few teams to hundreds." Harvard Business Review, 2018.

"SAFe Implementation Roadmap." Scaled Agile Framework, Scaled Agile, Inc., 14 Mar. 2023.

"SAFe Partner Cprime: SAFe Implementation Roadmap: Scaled Agile." Cprime, 5 Apr. 2023.

"SAFe: The Good, the Bad, and the Ugly." Project Management Institute.

"Scaled Agile Framework." Wikipedia, Wikimedia Foundation, 29 Mar. 2023.

"Scaling Agile Challenges and How to Overcome Them." PremierAgile.

"SproutLoud - a Case Study of SAFe Agile Planning." Scaled Agile, 29 Nov. 2022.

"Story." Scaled Agile Framework, 13 Apr. 2023.

Sutherland , Jeff. "Scrum: How to Do Twice as Much in Half the Time." Tedxaix, YouTube, 7 July 2014.

Venema, Marjan. "6 Scaled Agile Frameworks - Which One Is Right for You?" NimbleWork, 23 Dec. 2022.

Warner, Rick. "Scaled Agile: What It Is and Why You Need It." High-Performance Low-Code for App Development, OutSystems, 25 Oct. 2019.

Watts, Stephen, and Kirstie Magowan. "The Scaled Agile Framework (SAFE): What to Know and How to Start." BMC Blogs, 9 Sept. 2020.

"What Is SAFe? The Scaled Agile Framework Explained." CIO, 9 Feb. 2021.

"Why Agile Transformations Fail: Four Common Culprits." Planview.

"Why You Should Use SAFe (and How to Find SAFe Training to Help)." Easy Agile.

Y., H. "Story Points vs. 'Ideal Days.'" Cargo Cultism, 19 Aug. 2010.

Bibliography

Enable Organization-Wide Collaboration by Scaling Agile

Ambler, Scott W. "Agile Architecture: Strategies for Scaling Agile Development." Agile Modeling, 2012.

- - -. "Comparing Approaches to Budgeting and Estimating Software Development Projects." AmbySoft.

- - -. "Agile and Large Teams." Dr. Dobb's, 17 Jun 2008.

Ambler, Scott W. and Mark Lines. Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. IBM Press, 2012.

Ambler, Scott W., and Mark Lines. "Scaling Agile Software Development: Disciplined Agility at Scale." Disciplined Agile Consortium White Paper Series, 2014.

AmbySoft. "2014 Agile Adoption Survey Results." Scott W. Ambler + Associates, 2014.

Bersin, Josh. "Time to Scrap Performance Appraisals?" Forbes Magazine, 5 June 2013. Accessed 30 Oct. 2013..

Cheese, Peter, et al. " Creating an Agile Organization." Accenture, Oct. 2009. Accessed Nov. 2013..

Croxon, Bruce, et al. "Dinner Series: Performance Management with Bruce Croxon from CBC's 'Dragon's Den.'" HRPA Toronto Chapter. Sheraton Hotel, Toronto, ON, 12 Nov. 2013. Panel discussion.

Culbert, Samuel. "10 Reasons to Get Rid of Performance Reviews." Huffington Post Business, 18 Dec. 2012. Accessed 28 Oct. 2013.

Denning, Steve. "The Case Against Agile: Ten Perennial Management Objections." Forbes Magazine, 17 Apr. 2012. Accessed Nov. 2013.

Estis, Ryan. "Blowing up the Performance Review: Interview with Adobe's Donna Morris." Ryan Estis & Associates, 17 June 2013. Accessed Oct. 2013.

Heikkila et al. "A Revelatory Case Study on Scaling Agile Release Planning." EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), 2010.

Holler, Robert, and Ian Culling. "From Agile Pilot Project to Enterprise-Wide Deployment: Five Sure-Fire Ways To Fail When You Scale." VersionOne, 2010.

Kniberg, Henrik, and Anders Ivarsson, "Scaling Agile @ Spotify," Unified Communications and Collaborations, 2012.

Narayan, Sriram. "Agile IT Organization Design: For Digital Transformation and Continuous Delivery." Addison-Wesley Professional, 2015.

Shrivastava, NK, and Phillip George. "Scaling Agile." RefineM, 2015.

Sirkia, Rami, and Maarit Laanti. "Lean and Agile Financial Planning." Scaled Agile Framework Blog, 2014.

Scaled Agile Framework (SAFe). "Agile Architecture." Scaled Agile Inc., 2015.

VersionOne. 9th Annual: State of Agile Survey. VersionOne, LLC, 2015.

Appendix A: Supporting Info-Tech Research

Transformation topics and supporting research to make your journey easier, with less rework

Supporting research and services

Improving IT Alignment

Build a Business-Aligned IT Strategy
Success depends on IT initiatives clearly aligned to business goals, IT excellence, and driving technology innovation.

Make Your IT Governance Adaptable
Governance isn't optional, so keep it simple and make it flexible.

Create an IT View of the Service Catalog
Unlock the full value of your service catalog with technical components.

Application Portfolio Management Foundations
Ensure your application portfolio delivers the best possible return on investment.

Shifting Toward Agile DevOps

Agile/DevOps Research Center
Access the tools and advice you need to be successful with Agile.

Develop Your Agile Approach for a Successful Transformation
Understand Agile fundamentals, principles, and practices so you can apply them effectively in your organization.

Implement DevOps Practices That Work
Streamline business value delivery through the strategic adoption of DevOps practices.

Perform an Agile Skills Assessment
Being Agile isn't about processes, it's about people.

Define the Role of Project Management in Agile and Product-Centric Delivery
Projects and products are not mutually exclusive.

Shifting Toward Product Management

Make the Case for Product Delivery
Align your organization on the practices to deliver what matters most.

Deliver on Your Digital Product Vision
Build a product vision your organization can take from strategy through execution.

Deliver Digital Products at Scale
Deliver value at the scale of your organization through defining enterprise product families.

Mature and Scale Product Ownership
Strengthen the product owner role in your organization by focusing on core capabilities and proper alignment.

Build a Value Measurement Framework
Focus product delivery on business value- driven outcomes.

Improving Value and Delivery Metrics

Build a Value Measurement Framework
Focus product delivery on business value-driven outcomes.

Create a Holistic IT Dashboard
Mature your IT department by measuring what matters.

Select and Use SDLC Metrics Effectively
Be careful what you ask for, because you will probably get it.

Reduce Time to Consensus With an Accelerated Business Case
Expand on the financial model to give your initiative momentum.

Improving Governance, Prioritization, and Value

Make Your IT Governance Adaptable
Governance isn't optional, so keep it simple and make it flexible.

Maximize Business Value From IT Through Benefits Realization
Embed benefits realization into your governance process to prioritize IT spending and confirm the value of IT.

Drive Digital Transformation With Platform Strategies
Innovate and transform your business models with digital platforms.

Succeed With Digital Strategy Execution
Building a digital strategy is only half the battle: create a systematic roadmap of technology initiatives to execute the strategy and drive digital transformation.

Build a Value Measurement Framework
Focus product delivery on business value-driven outcomes.

Create a Holistic IT Dashboard
Mature your IT department by measuring what matters.

Improving Requirements Management and Quality Assurance

Requirements Gathering for Small Enterprises
Right-size the guidelines of your requirements gathering process.

Improve Requirements Gathering
Back to basics: great products are built on great requirements.

Build a Software Quality Assurance Program
Build quality into every step of your SDLC.

Automate Testing to Get More Done
Drive software delivery throughput and quality confidence by extending your automation test coverage.

Manage Your Technical Debt
Make the case to manage technical debt in terms of business impact.

Create a Business Process Management Strategy
Avoid project failure by keeping the "B" in BPM.

Build a Winning Business Process Automation Playbook
Optimize and automate your business processes with a user-centric approach.

Improving Release Management

Optimize Applications Release Management
Build trust by right-sizing your process using appropriate governance.

Streamline Application Maintenance
Effective maintenance ensures the long-term value of your applications.

Streamline Application Management
Move beyond maintenance to ensure exceptional value from your apps.

Optimize IT Change Management
Right-size IT change management to protect the live environment.

Manage Your Technical Debt
Make the case to manage technical debt in terms of business impact.

Improve Application Development Throughput
Drive down your delivery time by eliminating development inefficiencies and bottlenecks while maintaining high quality.

Improving Business Relationship Management

Embed Business Relationship Management in IT
Show that IT is worthy of Trusted Partner status.

Mature and Scale Product Ownership
Strengthen the product owner role in your organization by focusing on core capabilities and proper alignment.

Improving Security

Build an Information Security Strategy
Create value by aligning your strategy to business goals and business risks.

Develop and Deploy Security Policies
Enhance your overall security posture with a defensible and prescriptive policy suite.

Simplify Identity and Access Management
Leverage risk- and role-based access control to quantify and simplify the identity and access management (IAM) process.

Improving and Supporting Business-Managed Applications

Embrace Business-Managed Applications
Empower the business to implement their own applications with a trusted business-IT relationship.

Enhance Your Solution Architecture Practices
Ensure your software systems solution is architected to reflect stakeholders' short- and long-term needs.

Satisfy Digital End Users With Low- and No-Code
Extend IT, automation, and digital capabilities to the business with the right tools, good governance, and trusted organizational relationships.

Build Your First RPA Bot
Support RPA delivery with strong collaboration and management foundations.

Automate Work Faster and More Easily With Robotic Process Automation
Embrace the symbiotic relationship between the human and digital workforce.

Improving Business Intelligence, Analytics, and Reporting

Modernize Data Architecture for Measurable Business Results
Enable the business to achieve operational excellence, client intimacy, and product leadership with an innovative, agile, and fit-for-purpose data architecture practice.

Build a Reporting and Analytics Strategy
Deliver actionable business insights by creating a business-aligned reporting and analytics strategy.

Build Your Data Quality Program
Quality data drives quality business decisions.

Design Data-as-a-Service
Journey to the data marketplace ecosystems.

Build a Robust and Comprehensive Data Strategy
Learn about the key to building and fostering a data-driven culture.

Build an Application Integration Strategy
Level the table before assembling the application integration puzzle or risk losing pieces.

Appendix B: SDLC Transformation Steps

Waterfall SDLC

Valuable product delivered at the end of an extended project lifecycle, frequently in years

• Business is separated from the delivery of technology it needs. Only one-third of the product is actually valuable (ITRG, N=40,000).
• In Waterfall, a team of experts in specific disciplines hand off different aspects of the lifecycle.
• Document sign-offs are required to ensure integration between silos (Business, Development, and Operations) and individuals.
• A separate change-request process lays over the entire lifecycle to prevent changes from disrupting delivery.
• Tools are deployed to support a specific role (e.g. BA) and seldom integrated (usually requirements <-> test).

Wagile/Agifall/WaterScrumFall SDLC

Valuable product delivered in multiple releases

• Business is more closely integrated by a business product owner, who is accountable for day-to-day delivery of value for users.
• The team collaborates and develops cross-functional skills as they define, design, build, and test code over time.
• Sign-offs are reduced but documentation is still focused on satisfying project delivery and operations policy requirements.
• Change is built into the process to allow the team to respond to change dynamically.
• Tools start to be integrated to streamline delivery (usually requirements and Agile work management tools).

Agile SDLC

Valuable product delivered iteratively: frequency depends Ops' capacity

• Business users are closely integrated through regularly scheduled demos (e.g. every two weeks).
• Team is fully cross-functional and collaborates to plan, define, design, build, and test the code, supported by specialists.
• Documentation is focused on future development and operations needs.
• Change is built into the process to allow the team to respond to change dynamically.
• Automation is explored for application development (e.g. automated regression testing).

Agile With DevOps SDLC

High frequency iterative delivery of valuable product (e.g. every two weeks)

• Business users are closely integrated through regularly scheduled demos.
• Development and operations teams collaborate to plan, define, design, build, test, and deploy code, supported by automation.
• Documentation is focused on supporting users, future changes, and operational support.
• Change is built into the process to allow the team to respond to change dynamically.
• Test, build, deploy process is fully automated. (Service desk is still separated.)

DevOps SDLC

Continuous integration and delivery

• Business users are closely integrated through regularly scheduled demos.
• Fully integrated DevOps team collaborates to plan, define, design, build, test, deploy, and maintain code.
• Documentation is focused on future development and use adoption.
• Change is built into the process to allow the team to respond to change dynamically.
• Development and operations toolchain are fully integrated.

Fully integrated product SDLC

Agile + DevOps + continuous delivery of valuable product on demand

• Business users are fully integrated with the teams through dedicated business product owner.
• Cross-functional teams collaborate across the business and technical life of the product.
• Documentation supports internal and external needs (business, users, operations).
• Change is built into the process to allow the team to respond to change dynamically.
• Toolchain is fully integrated (including service desk).

Appendix C: Understanding Agile Scrum Practices and Ceremonies

Cultural advantages of Agile

Agile* SDLC

With shared ownership instead of silos, we are able to deliver value at the end of every iteration (aka sprint)

Key Elements of the Agile SDLC

• You are not "one and done." There are many short iterations with constant feedback.
• There is an empowered product owner. This is a single authoritative voice who represents stakeholders.
• There is a fluid product backlog. This enables prioritization of requirements "just-in-time."
• There is a cross-functional, self-managing team. This team makes commitments and is empowered by the organization to do so.
• There is working, tested code at the end of each sprint: Value becomes more deterministic along sprint boundaries.
• Stakeholders are allowed to see and use the functionality and provide necessary feedback.
• Feedback is being continuously injected back into the product backlog. This shapes the future of the solution.
• There is continuous improvement through sprint retrospectives.
• The virtuous cycle of sprint-demo-feedback is internally governed when done right.

* There are many Agile methodologies to choose from, but Scrum is by far the most widely used (and is shown above).

Understand the Scrum process

The scrum process coordinates multiple stakeholders to deliver on business priorities.

Understand the ceremonies part of the scrum process

Scrum vs. Kanban: Key differences

Scrum vs. Kanban: When to use each

Scrum

Related or grouped changes are delivered in fixed time intervals.

Use when:

• Coordinating the development or release of related items
• Maturing a product or service
• Coordinating interdependencies between work items

Kanban

Independent items are delivered as soon as each is ready.

Use when:

• Completing work items from ticketing or individual requests
• Completing independent changes
• Releasing changes as soon as possible

Appendix D: Improving Product Management

Product delivery realizes value for your product family

While planning and analysis are done at the family level, work and delivery are done at the individual product level.

Manage and communicate key milestones

Successful product-delivery managers understand and define key milestones in their product-delivery lifecycles. These milestones need to be managed along with the product backlog and roadmap.

Info-Tech Best Practice
Product management is not just about managing the product backlog and development cycles. Teams need to manage key milestones, such as learning milestones, test releases, product releases, phase gates, and other organizational checkpoints.

A backlog stores and organizes product backlog items (PBIs) at various stages of readiness

A well-formed backlog can be thought of as a DEEP backlog:

Detailed Appropriately: PBIs are broken down and refined as necessary.

Emergent: The backlog grows and evolves over time as PBIs are added and removed.

Estimated: The effort that a PBI requires is estimated at each tier.

Prioritized: A PBI's value and priority are determined at each tier.

Source: Perforce, 2018

Backlog tiers facilitate product planning steps

Ranging from the intake of an idea to a PBI ready for development; to enter the backlog, each PBI must pass through a given quality filter.

Each activity is a variation of measuring value and estimating effort in order to validate and prioritize a PBI.

A PBI successfully completes an activity and moves to the next backlog tier when it meets the appropriate criteria. Quality filters should exist between each tier.

Use quality filters to ensure focus on the most important PBIs

Expand the concepts of defining "ready" and "done" to include the other stages of a PBI's journey through product planning.

Info-Tech Best Practice
A quality filter ensures that quality is met and the appropriate teams are armed with the correct information to work more efficiently and improve throughput.

Define product value by aligning backlog delivery with roadmap goals

In each product plan, the backlogs show what you will deliver. Roadmaps identify when and in what order you will deliver value, capabilities, and goals.

Product roadmaps guide delivery and communicate your strategy

In "Deliver on Your Digital Product Vision," we demonstrate how a product roadmap is core to value realization. The product roadmap is your communicated path. As a product owner, you use it to align teams and changes to your defined goals, as well as your product to enterprise goals and strategy.

Info-Tech Insight
The quality of your product backlog - and your ability to realize business value from your delivery pipeline - is directly related to the input, content, and prioritization of items in your product roadmap.

Info-Tech's approach

Operationally align product delivery to enterprise goals

The Info-Tech Difference

Create a common definition of what a product is and identify the products in your inventory.

Use scaling patterns to build operationally aligned product families.

Develop a roadmap strategy to align families and products to enterprise goals and priorities.

Use products and families to assess value realization.

Mitigate the Risk of Cloud Downtime and Data Loss

Resilience and disaster recovery in an increasingly Cloudy and SaaSy world.

Analyst Perspective

Use this blueprint to expand your DRP and BCP to account for cloud services

As more applications are migrated to cloud-based services, disaster recovery (DR) and business continuity plans (BCP) must include an understanding of cloud risks and actions to mitigate those risks. This includes evaluating vendor and service reliability and resilience, security measures, data protection capabilities, and technology and business workarounds if there is a cloud outage or incident.

Use the risk assessments and cloud service incident response plans developed through this blueprint to supplement your DRP and BCP as well as further inform your crisis management plans (e.g. account for cloud risks in your crisis communication planning).

Executive Summary

Info-Tech Insight

Asking vendors about their DRP, BCP, and overall resilience has become commonplace. Expect your vendors to provide answers so you can assess risk. Furthermore, your vendor may have additional offerings to increase resilience or recommendations for third parties who can further assist your goals of improving cloud service resilience.

Key deliverable

Cloud Services Resilience Summary

Provide leadership with a summary of cloud risk, downtime workarounds implemented, and additional data protection.

Additional tools and templates in this blueprint

This blueprint will step you through the following actions to evaluate and mitigate cloud services risk

1. Assess your cloud risk

• Review your cloud services to determine potential impact of downtime/data loss, vendor SLA gaps, and vendor’s current resilience.

• Explore your cloud vendor’s resilience offerings, third-party solutions, DIY recovery options, and business workarounds.

• Document your cloud risk mitigation strategy and incident response plan, which might include a failover strategy, data protection, and/or business continuity.

Cloud Risk Mitigation

Identify options to mitigate risk

Create an incident response plan

Assess risk

Phase 1: Assess your cloud risk

Cloud does not guarantee uptime

Public cloud services (e.g. Azure, GCP, AWS) and popular SaaS solutions experience downtime every year.

A few cloud outage examples:

• Microsoft Azure AD outage, March 15, 2022:
  Many users could not log into O365, Dynamics, or the Azure Portal.
  Cause: software change.
• Three AWS outages in December 2021: December 7 (Netflix and others impacted), December 15 (Duo, Zoom, Slack, others), December 20 (Slack, Epic Games, others). Cause: network issues, power outage.
• Salesforce outage, May 12, 2022: Users could not access the Lightning platform. Cause: expired certificate.

Cloud availability

• Migrating to cloud services can improve availability, as they typically offer more resilience than most organizations can afford to implement themselves.
• However, having multiple data centers, zones, and regions doesn’t prevent all outages, as we see every year with even the largest cloud vendors.

DR challenges for IaaS, PaaS, and cloud-native

While there are limits to what you control, often traditional “failover” DR strategy can apply.

High-level challenges and resilience options:

• IaaS: No control over the hardware, but you can failover to another region. This is fairly similar to traditional DR.
• PaaS: No control over the software platform (e.g. SQL server as a service), but you can back up your data and explore vendor options to replicate your environment.
• Cloud-native applications: As with PaaS, you can back up your data and explore vendor options to replicate your environment.

Plan for resilience

• Include DR requirements when designing cloud service implementation. For example, for IaaS solutions, identify what data would need to be replicated and what services may need to be “always on” (e.g. database services where high-availability is demanded).
• Similarly, for PaaS and cloud-native solutions, consult your vendor regarding options to build in resilience options (e.g. ability to failover to another environment).

DR challenges for SaaS solutions

SaaS is the biggest challenge because you have no control over any part of the base application stack.

High-level challenges and resilience options:

• No control over the hardware (or the facility, maintenance processes, and so on).
• No control over the base application (control is limited to configuration settings and add-on customizations or integrations).
• Options to back up your data will depend on the service.

Note: The rest of this blueprint is focused primarily on SaaS resilience due to the challenges listed here. For other cloud services, leverage traditional DR strategies and vendor management to mitigate risk (as summarized on the previous slides).

Focus on what you can control

• For SaaS solutions in particular, you must toss out traditional DR. If Salesforce has an outage, you won’t be involved in recovering the system.
• Instead, DR for SaaS needs to focus on improving resilience where you do have control and implementing business workarounds to bridge the gap.

Evaluate your cloud services to clarify your specific risks

Time and money is limited, so focus first on cloud services that are most critical and evaluate the vendors’ SLA and existing resilience capabilities.

The activities on the next two slides will evaluate risk through two approaches:

Activity 1: Quantify potential impact and prioritize cloud services using a business impact analysis (BIA)

1-3 hours

1. Download the latest version of our DRP BIA: DRP Business Impact Analysis Tool. The tool includes instructions.
2. Include the cloud services you want to assess in the list of applications/systems (see the tool excerpt below), and follow the BIA methodology outlined in the Create a Right-Sized Disaster Recovery Plan blueprint.
3. Use the results to quantify potential impact and prioritize your efforts on the most-critical cloud services.

Activity 2: Review your key cloud vendors’ SLAs, incident preparedness, and data protection strategy

1-3 hours

Use the Cloud Services Incident Risk and Mitigation Review Tool as follows:

1. Send the Vendor Questionnaire tab to your cloud vendors to gather input, and review your existing agreements.
2. Copy the vendor responses into the tool (see the instructions in the tool) and evaluate. See the example excerpt below.
3. Identify action items to clarify gaps or address risks. Some action items might not be defined yet and will need to wait until you have had a chance to further explore risk mitigation options.

Phase 2: Identify options to mitigate risk

Consult your vendor to identify options to improve resilience, as a starting point

Your vendor might also be able to suggest third parties that offer additional support, backup, or service continuity options.

• The Vendor Questionnaire tab in the Cloud Services Incident Risk and Mitigation Review Tool includes a section at the bottom where your vendor can name additional options to improve resilience (e.g. premium support packages, potentially their own DR services).
• If your vendor has not completed that part of the questionnaire, meet with them to discuss this. Asking service vendors about resilience has become commonplace, so they should be prepared to answer questions about their own offerings and potentially can name trusted third-party vendors who can further assist you.
• Leverage Info-Tech’s advisory services to evaluate options outlined by your vendor and potential third-party options (e.g. enterprise backup solutions that support backing up SaaS data).

Some SaaS solutions have plenty of resilience options; others not so much

• The pervasiveness of O365 has led vendors to close the service continuity gap, with options to send and receive email during an outage and back up your data.
• With many SaaS solutions, there isn’t going to be a third-party service continuity option, but you might still be able to at least back up your data and implement business process workarounds to close the service gap.

Example SaaS risk and mitigation: O365

Example SaaS risk and mitigation: Salesforce

Establish a baseline standard for risk mitigation, regardless of cloud service

At a minimum, set a goal to review vendor risk at least annually, define standard processes for monitoring outages, and review options to back up your SaaS data.

Example baseline standard for cloud risk mitigation

• Review vendor risk at least annually. This includes reviewing SLAs, vendor’s incident preparedness (e.g. do they have a current DRP, BCP, and Security IRP?), and the vendor’s data protection strategy.
• Incident response plans must include, at a minimum, steps to monitor vendor outage and communicate status to relevant stakeholders. Where possible, business process workarounds are defined to bridge the service gap.
• For critical data (based on your BIA and an evaluation of risk), maintain your own backups of SaaS data for additional protection.

Embed risk mitigation standards into existing IT operations

• Include specific SLA requirements, including incident management processes, in your RFP process and annual vendor review.
• Define cloud incident response in your incident management procedures.
• Include cloud data considerations in your backup strategy reviews.

Phase 3: Create an incident response plan

Activity 1: Review the example incident response workflows and case studies as a starting point

1-3 hours

Review the SaaS Incident Response Workflows examples. The examples illustrate different approaches to incident response depending on the criticality of the service and options available. Review the case studies on the next few slides, which further illustrate the resilience and incident response solutions implemented. Note the key elements: Detection Assessment Monitoring status / contacting the vendor Communication with key stakeholders Invoking workarounds, if applicable	Example SaaS Incident Response Workflow Excerpt	Materials
		SaaS Incident Response Workflows examples
		Participants
		Core group of IT management and staff tasked with evaluating and improving cloud services’ resilience. Relevant business process owners to provide input and define business workarounds, where applicable.

Case Study 1: Recovery plan for critical fundraising event

If either critical SaaS dependency fails, the following plan is executed:

1. Donors are redirected to a predefined alternate donation page hosted by a different service. The alternate page connects to the backup payment processing service (with predefined integrations).
2. Marketing communications support the redirect.
3. While the backup solution doesn’t gather as much data, the payment details provide enough information to follow up with donors where necessary.

Criticality justified a failover option

The Annual Day of Giving generates over 50% of fundraising for the year. It’s critically dependent on two SaaS solutions that host the donation page and payment processing.

To mitigate the risk, the organization implemented the ability to failover to an alternate “environment” – much like a traditional DR solution – supported by workarounds to manage data collection.

Case Study 2: Protecting customer data

Daily exports from a SaaS-hosted donations site reduce potential data loss: