V2-5 Analytics On Azure Spec Audit Checklist

Download as pdf or txt
Download as pdf or txt
You are on page 1of 22

Analytics on Microsoft Azure Specialization

Program guide, audit checklist, and FAQ

V2.5
Valid January 1, 2024 - June 30, 2024
Program updates and announcements
Module B – Jan 1, 2024
The V2.5 Analytics on Microsoft Azure Specialization checklist is available for preview. This is required
for audits Jan 1 – June 30, 2024. Changes to V2.5 from the V2.4 checklist include simplification of Module B
Control 2.1 (Solution design) has added Fabric Data Factory in the ingestion engine control evidence,
Microsoft OneLake to the Data storage control evidence and Data Analytics analysis options of Azure
Synapse Analytics OR Azure Databricks, OR Microsoft Fabric or Dedicated SQL Pool (formerly SQL
Datawarehouse) for acceptable evidence. Control 2.3 (Proof of Concept or Pilot) and Control 3.1
(Deployment) now allow use of Azure Synapse Analytics OR Azure Databricks, OR Microsoft Fabric OR
Dedicated SQL Pool (formerly SQL Data Warehouse), rather than requiring the use of all three in the same
evidence controls.

• With this change, three (3) unique customers are now required for these controls over 24 months,
rather than one (1) unique customer.

Module B - Dec 1, 2023


The V2.5 Analytics on Microsoft Azure Specialization checklist was made available for preview.

SQL Data warehouse has been renamed Dedicated SQL Pool in relevant controls

Module A - October 1, 2023


Azure Active Directory has been renamed Microsoft Entra ID

August 28, 2023


The Microsoft Cloud Partner Program has changed its name to the Microsoft AI Cloud Partner
Program effective immediately

Module B - July 5, 2023


V2.4 Analytics on Microsoft Azure Specialization checklist is published. This checklist version is required
for audits during July 5, 2023- Jan 1, 2024. No control changes were made in V2.4 from V2.3 checklist

Azure Innovate has been added for this Azure specialization in program benefits, see the FAQ

Module B - Jan 2, 2023


V2.3 Analytics on Microsoft Azure Specialization audit checklist is published. This checklist version is
required Jan 2, 2023 - July 5, 2023

Module B - Dec 5, 2022


The PREVIEW for V2.3 Analytics on Microsoft Azure Specialization was made available for
partners This checklist version is required Jan 2, 2023
• There are no new Module A or B Control updates
• FAQ clarification that a “No Pass” results when a partner fails or withdraws from the audit

2
Module B - Oct 3, 2022
Microsoft retired Gold Cloud partner competency, Solutions partner designation required
Gold and Silver competencies are retired and replaced with Solutions Partner designations. For
this specialization, your organization must have an active Solutions Partner for Data & AI
(Azure) designation.

Module A - July 1, 2022


Updates published May 2, 2022 in preview are now required
In Control 2.2, a new Skilling Plan has been added to the checklist. This is required July 1, 2022.

Module A - May 2, 2022


The partner Preview for the updated Module A Cloud Foundation checklist was made available

Module B - May 2, 2022


1. Azure Synapse Link has been added for optional use in Module B controls 2.1 Design, 2.3 PoC and 3.1
Deployment
2. Updated guidance for the definition of Proof of Concept and Pilots has been added to the FAQ

Jan 1, 2022
Guidance and FAQ Updates

3
Contents

Analytics on Microsoft Azure Specialization Overview........................................................................................... 5


How to apply .................................................................................................................................................................. 5
NDAs for the audit ......................................................................................................................................................... 5
Payment terms and conditions ................................................................................................................................... 5
Audit blueprint ............................................................................................................................................................... 5
Audit roles........................................................................................................................................................................ 6
Audit Process: High-level overview ............................................................................................................................ 6
Audit Process: Details .................................................................................................................................................... 8
Audit preparation best practices and resources ...................................................................................................... 9
Audit checklists ............................................................................................................................................................. 11
Partner FAQ ................................................................................................................................................................... 22

4
Analytics on Microsoft Azure specialization Program Overview

This document defines the requirements to earn the Analytics on Microsoft Azure specialization. It also
provides further requirements, guidelines, and audit checklists for the associated audits required to earn
this Azure specialization.

The Analytics on Microsoft Azure specialization is designed for partners to demonstrate their deep
knowledge, extensive experience, and proven success in planning and deploying Azure cloud analytics
services for customers. Such partners empower their customers to use Azure cloud analytics services to
realize the full breadth of their data assets and to build transformative, secure analytical solutions at
enterprise scale.

The Analytics on Microsoft Azure specialization allows partners with an active Solutions partner
designation to further differentiate their organizations, demonstrate their Analytics capabilities, and build
stronger connections with customers. For this specialization, an active Solutions Partner for Data & AI
(Azure) designation is required.

Partners will receive a Pass or No Pass result upon completion of the audit process. A Pass result satisfies
the audit requirement for this Azure specialization for two (2) years. See the Partner FAQ for renewal
information.

How to apply
Partners with the appropriate role and access permissions can apply. Only a Microsoft AI Cloud Partner
Account Administrator or a Global Administrator of an organization’s Microsoft partner account can
submit an application for the Azure specialization on behalf of the organization.

To do so, they sign into their Partner Center account. On the left pane, select Azure under the Specialization
section. Toggle to the specialization that you wish to apply for by using the drop-down menu at the top of
the page.

5
NDAs for the audit

Auditors comply with requests from partners to sign a direct NDA. All ISSI auditors are under a nondisclosure
agreement (NDA) with Microsoft. If a partner would like an NDA to be signed directly between ISSI and the
partner organization for purposes of the audit, one can be provided by the partner during the audit scheduling
process to ISSI. ISSI will sign and return it.

Payment terms and conditions

Pricing schedule
Module B Audit: $2,000 USD

Module A+B Audits: $3,000 USD

A Gap Review Meeting is included with each Module audit.

Payment terms

The cost of the audit is payable in full to the audit company and must be settled before the audit begins.
Failure to pay will result in cancellation of the audit.

Program status term

When a partner meets all prerequisite requirements shown in Partner Center and Microsoft receives a
valid Pass Report from the third-party audit company, the partner will be awarded the Analytics on
Microsoft Azure specialization for one (1) calendar year.

The status and the Analytics on Microsoft Azure specialization label can be used only by the organization
(determined by Partner Center MPN PGA ID account) and any associated locations (determined by MPN
PLA ID) that met all requirements and passed the audit. Any subsidiary or affiliated organizations
represented by separate Partner Center accounts (MPN PGA ID) may not advertise the status or display
the associated label.

Audit blueprint

Audits are evidence-based. During the audit, partners will be expected to present evidence they have met
the specific requirements on the checklist. This involves providing the auditor with access to live
demonstrations, documents, and SME personnel to demonstrate compliance with checklist requirements.
The audit checklist will be updated to stay current with technology and market changes, and the audit is
conducted by an independent, third-party auditor.

6
The following is included in the audit blueprint:

1. Audit Roles
2. Audit Process: High level overview
3. Audit Process: Details
4. Audit Best practices and resources

Audit roles
Role of the auditor

The auditor reviews submitted evidence and objectively assesses whether the evidence provided by the
partner satisfies the audit checklist requirements.

The auditor selects and evaluates evidence, based on samples of the information available from live
systems. The appropriate use of such sampling is closely related to the confidence that can be placed in
the audit conclusions. All ISSI auditors are under a non-disclosure agreement (NDA) with Microsoft.
Auditors will also comply with requests from partners to sign a direct NDA.

Role of the partner

The partner must provide objective evidence that satisfies the auditor for all checklist items. It is the
responsibility of the partner to have reviewed all check-list items prior to the audit, to have collated
all necessary documentation and evidence, and to have ensured that the right subject matter experts
are available to discuss and show systems, as appropriate. All audit evidence must be reproducible
and verifiable.

Role of the Microsoft Partner Development Manager

For partners that have an assigned Microsoft Partner Development Manager (PDM), the PDM is
responsible for ensuring that the partner fully understands the requirements prior to applying for the
audit. The PDM may attend the optional consulting engagements that ISSI offers, but the PDM and other
Microsoft FTEs may not attend the audit.

Audit Process: High-level overview

Step Action Responsibility

1 Review: specialization requirements in Partner Center. Review audit Partner


checklists in the specialization and begin to prepare needed evidence with
personnel for an evidence-based audit. Recommended: Before you apply,
review the specific audit checklist thoroughly and confirm SME personnel.
2 Meet the prerequisites and apply for the audit: In the initial application Partner
phase, applications are submitted in two (2) stages:
1. Prerequisite requirements (see Partner Center for details)
2. Audit
Do not start the application process unless you are ready to undertake the
audit. Assess your firm’s ability to complete the audit, including
considerations for readiness, employee availability, and holidays.

7
3 Validate: The partner meets all requirements prior to audit. Microsoft

4 Confirmed by Microsoft: Microsoft confirms to the third-party audit Microsoft


company that the partner is eligible for audit.

5 Schedule with partner: The auditor will schedule within two(2) business Auditor (with
days. partner)

6 Conduct the audit: Within thirty(30) calendar days of the approval for Auditor
audit.

7 Provide a Gap Report: If applicable, to the partner within two (2) Auditor
business
days of the completed audit, listing any Open Action Items. *

8 Acknowledge Gap Report receipt and schedule meeting: Partner


Within two (2) business days of receiving the Gap Report,
the partner acknowledges receipt of the report and
schedules a Gap Review Meeting. Partners can begin
immediate remediation of open items.
9 Complete the meeting: Within fifteen (15) calendar days of Auditor (with
receiving the Gap Report, the partner schedules and completes partner)
the Gap Review Meeting with the auditor to provide evidence
and address any Open Action Items. *
10 Issue Final Report: To the partner within five (5) business Auditor
days. Notify Microsoft of audit Pass or No Pass result.

11 Notify the partner: About program status within two(2) business days. Microsoft

* These steps will be skipped if the partner has no Open Action Items after the audit.

8
Audit Process: Details

Microsoft uses an independent, third-party audit company, Information Security Systems International, LLC
(ISSI), to schedule and conduct Azure specialization audits. After the audit date has been confirmed, ISSI
will provide an agenda to the partner. The duration of an audit is four (4) hours for Module B workloads and
eight (8) hours for Module A+B audits combined, depending upon the scope of the audit. During the audit,
the partner must provide access to the appropriate personnel who can discuss and disclose evidence that
demonstrates compliance with program requirements. We highly recommend that subject matter experts
for each section attend as well as a person who is familiar with the entire audit.

On the day of the audit, the partner must be prepared to provide the auditor with access to live
demonstrations, documents, and personnel, as necessary to demonstrate compliance with the
requirements. During the audit, the auditor will seek to verify that the partner’s evidence has addressed all
required audit checklist items satisfactorily.

A note on audit checklist effective dates: Partners are audited against the checklist items that are active on
the date of their remote audit, not the date they apply. Audits are updated twice annually. The partner
application or renewal date has no bearing on the version of the checklist that is used for the audit.
The audit can produce either of two (2) outcomes:

1. The partner passes the audit.


• The auditor will present a brief synopsis of the audit. This will include identifying observed
strengths and opportunities for improvement.
• The auditor will provide a Final Report to the partner.
• The auditor will notify Microsoft.

2. The partner does not satisfy all checklist items during the audit.
• The auditor will present a brief synopsis of the audit at the end of the day, including
observed strengths and Open Action Items, as outlined in the Gap Report, within two (2)
business days.
• The partner will acknowledge receipt of the Gap Report within two (2) business days.
• The partner will move into the Gap Review phase and schedule their Gap Review Meeting
within fifteen (15) calendar days.

The Gap Review

If the partner does not, to the auditor’s satisfaction, provide evidence that meets the required scores across
all audit categories during the audit, the partner will move into a Gap Review. A Gap Review is part of the
audit and completes the process. Within two (2) business days after the audit, the partner will receive a Gap
Report, which details any Open Action Items and the outstanding required evidence. It is suggested to begin
remediation on any open action items as soon as possible following the audit.

9
The partner then has two (2) business days to acknowledge receipt of the Gap Report and schedule a Gap
Review Meeting. The Gap Review Meeting is conducted with the auditor over the partner’s virtual
conference platform of choice. The meeting must take place within fifteen (15) calendar days of when the
Gap Report was sent, and it may last no longer than one (1) hour. During the Gap Review Meeting the
partner must present evidence that addresses any and all Open Action Items.

The Gap Review Meeting can produce either of two (2) outcomes:

1. The partner resolves all Open Action Items.


• The auditor confirms that the partner has provided the required evidence.
• The auditor provides a Final Report to the partner.
• The auditor notifies Microsoft about the outcome (subject to Auditor Terms and Conditions).

2. The partner does not resolve all Open Action Items.


• The auditor presents a brief synopsis of the audit, including missed items.
• The partner receives a Final Report that details the missed items.
• The auditor notifies Microsoft about the outcome (subject to Auditor Terms and Conditions).

If the partner is still unable to provide satisfactory evidence to the auditor during their Gap Review
Meeting, the partner will be deemed to have failed the audit. Partners that still want to earn this
Azure specialization will need to begin the application process again.

Completion of the audit

The audit process concludes when ISSI issues the Final Report after the audit or after the Gap Review.
Partners will be awarded a Pass or No Pass result upon completion of the audit process, including if they
withdraw from the audit process. At the conclusion of the audit process, the auditor will issue a Final
Report to the partner and notify Microsoft of the pass or no pass result. A Pass result satisfies the
audit requirement for this Azure specialization for two (2) years. A “No Pass” result is generated when
a partner fails or withdraws from the audit. When a No Pass result is entered into Partner Center, you
will see your status as “Audit Failed” in your dashboard. This status will reset within one week to “Not
Enrolled,” allowing you to reapply. Contact Partner Center Support if needed.

Audit preparation best practices and resources


Partners should ensure that the audit checklist has been thoroughly read in advance of the audit

• Partners should ensure that all partner stakeholders involved have a copy of the audit checklist
and that a stakeholder who knows the entire process is available for the duration of the audit
• Partners should confirm that they have live access granted, and files and tools are readily
available during the audit exhibits

Stakeholder SME attendance in the audit

Stakeholders who can best address the relevant section should be available for the audit. However, please
make sure that a stakeholder who knows the entire process is available for the duration of the audit.

10
Auditors often probe for more information

The auditor probes for more information to ensure that mature and repeatable processes are in place with
the partner and that they are established, effective, and efficient. The auditor is looking to see how a
document was created, where it is located, and what source materials were used to create the document.
By probing for more information, the auditor evaluates and validates that the partner is operating at an
advanced level. This can only be done by questioning during the audit. This approach is explained to the
partner during the opening meeting.
Acceptable evidence: Excerpts, exhibit file formats and use of PowerPoints

PowerPoints are a common and accepted format for presenting a high-level overview of a partner’s systems.
However, please also be prepared to present live demonstrations from source files so that the auditor may
confirm that the systems in place are mature and effective. Excerpts can be used to communicate the high-
level overview but are not acceptable evidence, source documents must be presented.

Additional resources: Two optional audit preparation offers from the auditing firm *

To ensure objectivity, consulting auditors and auditors conducting the actual audits are different ISSI auditors.

1. Partners can participate in an optional, one (1)-hour, live Audit Process & Controls Overview session
provided by ISSI. This session provides a high-level overview of key aspects of the Azure specialization
audit process. The session includes a discussion of the checklist requirements along with best practices
to help partners prepare for the audit. Partners work directly with ISSI to schedule this remote session
(via online web conference). For more information about this session, see Azure Specialization - Audit
Process and Controls Overview

2. ISSI also provides optional extensive, in-depth consulting engagements to help partners prepare for their
Azure specialization audit. Partners work directly with ISSI to schedule this remote session (via online web
conference). For more information about this type of in-depth engagement, see Azure Specialization
Consulting Offer https://issi-inc.com/az-advspeconsulting/

* Please note that there is a cost associated with the consulting and audit preparations services. See Payment Terms
and Conditions.

11
Audit checklists

The Analytics on Microsoft Azure specialization audit checklist contains two (2) modules, Module A: Cloud
Foundation and Module B: The Analytics on Microsoft Azure specialization workload. Module A, The Cloud
Foundation module evaluates the use of a consistent methodology and process for Azure adoption that is
aligned with customers’ expected outcomes, spanning the entire cloud adoption lifecycle. Module B, The
Analytics on Microsoft Azure specialization workload audit validates that the partner has adopted robust
processes to ensure customer success across all phases when deploying analytic solutions, from the
assessment phase to design, pilot, implementation, and post- implementation phases.

Review the following audit checklist tables for more details about each control phase and to learn how the
partner will be evaluated for an audit. The same customers may be used for Module A & B. The estimated
length of both modules together is eight (8) hours.

Module A: Cloud Foundation


1. Strategy
2. Plan
3. Environment readiness and Azure landing zone
4. Governance
5. Manage

Module B: Analytics on Microsoft Azure specialization workload


1. Assess
2. Design and Proof of Concept (POC)/Pilot
3. Deployment
4. Review and Release for Operations

To pass each module audit, the partner must complete all audit checklist items.

Module A, Cloud Foundation is required for multiple Azure specializations. To complete Module A, Cloud
Foundation, the partner needs to pass all controls in Module A by providing the specified evidence.
Partners who have passed Azure Expert MSP V1.9 (Full and Progress) and later have satisfied the
requirements for Module A in all audit versions unless otherwise noted. Module A: Cloud Foundation is
required for multiple Azure specializations.

When applying to subsequent Azure specializations, a previous audit Pass result will satisfy the
requirements for Module A if the Pass result has been within two (2) years. It can only be applied to the
same version of Module A. Alternatively, the partner may present evidence of a previous pass result from
another Azure specialization audit conducted on V2.0 or later. Partners who have passed an Azure
specialization audit before July 1, 2021 and for the Analytics on Microsoft Azure specialization audit
before Oct 1, 2021, have likely not passed the Module A audit and will need to do so to qualify for the
Module B workload audits.

12
Module B, The Analytics on Microsoft Azure specialization workload. Each control has one (1) or more
requirements and required evidence the partner must provide for the auditor.

Both the requirements and the required evidence are defined in the following tables. For some controls, a
reference customer or customer evidence is the documentation requested.
Unless otherwise stated, the partner must show at least show at least three (3) unique customers with
recent deployments required within the last twenty-four (24) months. Please note some checklists call for
four (4) customer examples or have shorter timelines for evidence. The partner can use the same customer
across audit checklist controls, or they can use a different customer. For audit evidence relating to customer
engagements, the partner can use a customer case study and reference it multiple times. The same or
different customers can be used for Modules A & B if they demonstrate requirements.

Module A: Cloud Foundation

1.0 Strategy and Economics

The partner must have a defined approach for helping their customer evaluate and define a cloud adoption strategy
beyond an individual asset (app, VM, or data).

Requirement

1.1 Cloud Adoption Business Strategy


The partner must have a process that captures the data-driven business strategies being used to
guide customer decisions. The process should include, at minimum, the following:

• A strategy review that captures the customer’s business needs and the
problems the customer is trying to solve

• Personalized recommendations from the partner for the customers’


business strategies

Required evidence:
A Report, Presentation, or Document that captures strategic inputs and decisions for two (2) unique
customers, that demonstrates Cloud Adoption Strategy Evaluator assessment output, with projects
completed in the past twelve (12) months. These projects must be aligned with the above-described
process and highlight both customer Business and Financial outcomes.

For an example, see the Strategy and plan template in the Cloud Adoption Framework for Azure, or
the Cloud Adoption Strategy Evaluator.

2.0 Plan

The partner must have a consistent approach to planning for cloud adoption that is based on the strategy outlined in
the preceding section.

Requirement

13
2.1 Cloud Adoption Plan
The partner must have a process and approach for planning and tracking the completion of cloud
adoption projects. For an example of a cloud adoption plan, see the Azure DevOps Demo Generator
for the Cloud Adoption Framework.

Required evidence:
The partner must provide evidence of their capability with examples of two (2) unique
customers, with projects that were completed in the past twelve (12) months. Acceptable
evidence must include at least one (1) of the following:

• Cloud Adoption Plan Generator output or


• Azure DevOps backlog or
• Any other tools for project planning and tracking

2.2 Plan for Skilling


When customers adopt the cloud, their existing technical staff will need a variety of new skills to aid
in making technical decisions and to support the new cloud implementations. To ensure the long-
term success of the customer, the partner must document a skilling plan to prepare the customer’s
technical staff.

The Partner must document a list of key customer technical roles expected to require new skills such
as, but not limited to, IT Admins, IT Governance, IT Operations, and IT Security.
The documentation must include:
A description of the new skills the technical roles will need to achieve to successfully manage
the new environment.
Resources the customer can leverage when training their technical employees such as Microsoft
learning paths, technical certifications, or other comparable resources.

For guidance, review Microsoft docs Azure Cloud Adoption Framework How to build a skilling
readinessplan

Required evidence:
The partner must provide a skilling plan for at least two (2) unique customer engagements
completed within the last 12 months. The two (2) skilling plans documentation can include a
customer-facing presentation, planning documents, post deployment documentation or similar
plan documentation.

14
3.0 Environment readiness and Azure Landing Zone

The partner must be able to demonstrate that the following design areas are addressed through their approach
to landing zone implementation.

Requirement

3.1 Repeatable Deployment


The partner must demonstrate adherence to Azure landing zone design areas through a repeatable
deployment. The deployment should configure, at minimum, the following identity, network, and resource
organization attributes:

• Identity
o Adoption of identity management solutions, such as Microsoft Entra ID
(formerly Azure Active Directory) or equivalent

• Networking architecture design (topology)


o Define an Azure network topology - Cloud Adoption Framework | Microsoft Docs
o Application of hybrid architectures that use Azure ExpressRoute, VPN
Gateway, or equivalent services for connecting local datacenters to Azure

• Resource organization
o Implementation of tagging and naming standards during the project
The partner must demonstrate which of the following deployment approaches they used when they
deployed Azure landing zones:

1. Start small and expand: Azure landing zone does not deploy governance or
operations configurations, which are addressed later in the implementation.

2. Full Azure landing zone conceptual architecture: Azure landing zones implement a
standard approach to the configuration of governance and operations tools prior to
implementation.

3. Alternative approach: If the partner follows a proprietary approach or a mixture of the two
(2) approaches above, the partner must clearly articulate their approach to environment
configuration.

Required evidence:
The partner must provide evidence of a repeatable deployment they used to create landing zones
aligned to the Azure landing zone conceptual architecture or equivalent complete architecture deployed
to two (2) unique customer environments using Bicep, ARM (AZURE Resource Manager) templates,
Terraform modules, or equivalent tools to automatically deploy the environment configuration.
If a customer deviates from specified architecture, the partner must demonstrate the customer
requirements to justify the deviation.

The provided template can be pulled directly from the implementation options, or it can be based on
the partner’s own IP (Intellectual Property). In either case, the script as evidence must demonstrate the
configuration of the identity, network, and resource organization, as described earlier.

15
4.0 Governance

The partner must demonstrate their customer’s role in governing cloud-based solutions and the Azure tools they
use to facilitate any governance requirements their customer might have today or in the future.

Requirement
4.1 Governance Tooling
The partner must demonstrate the ability to deploy the required governance tools for two (2)
unique customer projects.

Required evidence:
The partner must demonstrate the use of Azure Policy or equivalent tool to provide controls to govern
the environment for two (2) unique customers with projects that were completed in the past twelve
(12) months.

5.0 Manage

The partner must demonstrate that they have set up their customer for operational success after the deployment is
completed. All partners have a role in setting up operations management, even if they do not provide long-term
managed services.

Requirement

5.1 Operations Management Tooling


The partner must demonstrate the use of Azure products or equivalent to help their customer and/or
managed service provider operate the environment after deployment.

Required evidence:
The partner must demonstrate the deployment of at least one (1) of the following Azure products or
third-party equivalents: Azure Monitor, Azure Automation, or Azure Backup/Site Recovery, for two
(2) unique customers with projects that were completed in the past twelve (12)
months.

16
Module B: Analytics on Microsoft Azure specialization workload

1.0 Assess

Partner must have a consistent approach for assessing customer requirements for Analytics solution.

Requirement

1.1 Analytics Portfolio Assessment


Partner must demonstrate how they assess current state and customer requirements to ensure adequate pre-
migration or pre-deployment planning and sizing are performed. Assessment must include areas specific to
deploying analytics solutions:

• Business need:
o Current pain points, challenges, and end user needs
o Product fit and gaps to identify which product will best serve the customer’s needs
o Data storage needs from a business standpoint – volume, type, location, current state vs future state
o Data governance and compliance
o Budget

• Application Landscape:
o Current infrastructure or greenfield physical infrastructure
o Logical architecture and requirements for migration, if applicable
o Information for all applications, services, and software-as-a-service BI platforms
(for example, PowerBI.com or Tableau online).

• Performance Benchmarks:
Assess and document application performance requirements and data transfer requirements.

• User Personas:
o Document user roles, how each will use the data, how each will access the data
o Stakeholder engagement across business user roles, BI, analytics and/or data science roles

17
• Data needs: At the workload level, assess which data needs must be fulfilled to meet stated
business requirements around data such as:
o Type of data, volume, speed that will influence the technology required
o Data centralization
o Classification and risk of data involved
o Identify data sources (on-premises, AWS, Google, etc.) and destination (data storage on Azure).
o Identify who or what should consume the data

• Networking:
Existing infrastructure/networking components that will connect to Azure to move data and current
applications.

• Security and Compliance needs:


Identity and access management, role-based access control, encryption, industry, and geography- centric
compliance requirements, if applicable

• Availability, resiliency, and disaster recovery needs:


o Customer expectations once moved to Azure
o Expected demand and scalability
o Uptime and SLAs

Required evidence:
Partner should provide relevant design documents with evidence of the above items being reviewed from at least three
(3) unique customers with completed analytics deployments within the last twenty-four (24) months (partner must show
that all assessment details above were considered for that customer). Assessments may be done manually or through an
industry- accepted assessment tool.

Accepted Documentation: Assessment Report, Assessment Checklist, Templates, Questionnaires, Project Plan,
Data Migration Assistant (DMA) Reports, or other Third-party Tooling Reports.

2.0 Design and Proof of Concept (PoC) or Pilot


Partner has robust methodologies for designing the workload.
Requirement
2.1 Solution Design
Partner must provide solution designs showing a consistent approach that addresses customer requirements captured
from the assessment phase. Solution design must show areas specific to deploying analytics solutions:
• User Roles: User roles required to deploy the analytics solution (ETL users, analysts, developer,
report designer, data scientists, etc.) and establish role-based access
• Data Source: Identify all data sources and file type to be ingested.
• Data Migration approach: Outline of the migration approach to be used for the data, if applicable.

• Ingestion Engine: Identify the use of a data ingestion engine to extract, transform, load, and clean data.
Ingestion engines include but are not limited to native products such as Azure Data Factory, Fabric Data
Factory, Informatica, Data Stage, and Azure Databricks.
• Data Storage: Identify storage type for the ingested data. Data storage can include but is not limited to
native products such as Azure Blob, Azure Data Lake, Azure Data Warehouse, Azure Synapse or OneLake.
• Encryption Method: Identify data encryption approach. Data encryption methodology can include but is
not limited to Transparent Data Encryption (TDE), masking and Azure Key Vault.
• Analytics Service: Data analysis using: Azure Synapse Analytics OR Azure Databricks, OR Microsoft Fabric or
Dedicated SQL Pool (formerly SQL Datawarehouse)
• Data Reporting and Visualization: Identify use of the analytics data using data reporting tools including
(but not limited to) Power BI, Tableau, MicroStrategy, etc.
• DevOps: Considerations for applying DevOps principles:

18
• Specify source depot (Visual Studio, Git Repository, etc.)
• Coding language
• Redesign code or plan for backward compatibility
• Code deployment process.

• Azure Landing Zone: Landing zone design must demonstrate how the design considers analytics- specific
constraints:
• Regional Planning: Document regional availability of data centers and services.
• Network and Infrastructure Providers: Document regional availability of networks, providers, and
hardware required to deploy.
• Networking, Network Security Groups, Identity and Access Methods: Identify the use of secure
networking for data migration and storage including firewall, networking security groups, VNet
and subnet.
• Implementation evidence of Identity and Access Management (IAM) and Role Based Access
Control (RBAC), data sovereignty & encryption, application security, auditing.
• Establish a Hub-Spoke architecture or retrofit the existing deployment to separate out
the network components of a Hub for optimal performance and security.
• Use of Security products such as Azure Security Services, M365 Security, or other security
solutions to secure access to the data.
• Use of governance tooling to support cost optimization across the environment. After
estimating the initial cost, set budgets and alerts at different scopes to proactively monitor the
cost.
• Use of backup and recovery solutions to ensure data retention.
• Environment must meet requirements for government regulatory compliance in the new
environment, where applicable, such as GDPR and HIPAA, and implementation through multiple
datacenter regions, as needed.
• Use of a monitoring solution to provide proactive remediation for the Azure environment, which
is integrated into the customer's existing monitoring tooling, if appropriate.
• Use of visualization and alerting considerations for solutions, where appropriate.
• Demonstrate how this deployment will use the operations baseline to help the
customer maintain data ingress, data governance, high availability of data, and
solution optimization.
• Risk: Addresses the migration risk assessment and mitigation, if applicable.

Important Note: If the landing zone was implemented by a customer or another partner, the Analytics
partner must review the landing zone against the above points and provide as evidence documented
recommended changes to the customer for any items that do not meet these requirements.

Required evidence:
Partner should provide relevant solution design documents that address the points above, from at least three (3)
unique customers with Azure Analytics projects completed within the past twenty-four (24) months.

Important Note: If the landing zone was implemented by the customer (or by another partner), the
partner must provide documentation of their review and recommendations to the customer.

Acceptable Documentation: Project plans, Functional specifications, Architectural diagrams,


Automated tooling reports, Physical and logical diagrams.

19
2.2 Azure Well Architected Review of Workloads
The partner must demonstrate usage of the Azure Well-Architected Review for Azure analytics assessment. The
Azure Well-Architected Review is designed to help partners evaluate your customers' workloads against the
latest set of industry best practices. It provides actionable guidance to design and improve your customers'
workloads.

The Review can be used to evaluate each workload against the pillars of the Azure Well-Architected Framework
that matter to that workload.

Required evidence:
Unless otherwise specified, Reviews may be conducted before, during, or after deployment. The partner must
provide exported results from the completed Microsoft Well Architected Review using the assessments in the
Azure Well- Architected Review. Reviews must be conducted within the last twelve (12) months, for three (3)
analytics workloads indicating the customer’s name. This can come from one (1) or more customers.

2.3 Proof of Concept or Pilot


Partner must provide evidence of three completed analytics proof of concepts (POCs) or pilots. The POCs or pilots
must validate the design decisions, review, and adjust the design as appropriate before production rollout.

POC or pilot must document the purpose, customer pain points, pilot success criteria, the intended benefits of the
pilot, and results for the following Azure products:

• Azure Synapse Analytics OR Azure Databricks, OR Microsoft Fabric OR Dedicated SQL Pool
(formerly SQL Data Warehouse)

Required evidence:
The partner must provide relevant documentation for three (3) customers with a completed analytics proof of
concept (POC) or pilot project within the past twenty-four (24) months.

Accepted Documentation:

POC/Pilot Architecture Diagrams; Reference Architectural Design Blueprints; Test Plans and Results; Implementation
Documentation; other POC Documents; and Monitoring Tool Report.

3.0 Deployment

Partner has robust methodologies for deploying the workload.

Requirement

3.1 Deployment
The partner must provide evidence of the partner’s capability to implement analytics solutions deployed in
production environments, based on customer-approved designs.

At least three (3) customers must have Azure Synapse Analytics OR Azure Databricks, OR Microsoft Fabric or
Dedicated SQL Pool (formerly SQL Datawarehouse)

Required evidence:
Provide documentation for three (3) unique customers with completed projects within the past twenty-four
(24) months. Documentation for each customer must include two (2) or more of the following items and
cover the entire sequence of the project (from design to production deployment):
• Signed SOWs for all projects
• Solution design documents for all projects
• Project plan and migration/deployment sequence
• Architecture diagrams

• High Level Design (HLD) and Low-Level Design (LLD)

20
• As-built documentation

4.0 Review and Release for Operations

Partner has robust methodologies for transitioning the Analytics workload.

Requirement

4.1 Service Validation and Testing


Partner must validate the deployment, including:
• Demonstrate the process and approach for testing and evaluating the performance of all
applications against end user expectations and Azure best practices.
• Demonstrate the process and approach for evaluating and improving architectural best practices
to remediate issues with migrated platforms or workloads that don’t meet performance or cost
expectations.

Required evidence:
Documentation of testing and performance validation that addresses the above points for the three (3) unique
customers. The documentation must indicate that the implemented solution meets customer expectations with a
sign-off from the customer.

Projects must have been implemented within the last twenty-four (24) months. These projects can be the same as
the projects evidenced earlier in Control 3.1, Deployment.
4.2
Post-deployment Documentation
Partner must provide documentation post-deployment to ensure customers are successful in using the new service in Azure.
• Demonstrate how the partner documents, decisions, architectural designs, and procedures were implemented.
• Demonstrate Standard Operating Procedures for business-as-usual operations team which
describe ‘how- to’ scenarios.

Required evidence:
Documentation showing the above points for three (3) unique customers with completed Azure analytics projects within
the last twenty-four (24) months.

21
Azure Specializations Partner FAQ

Questions regarding the Azure Partner program specializations, the current checklists and pre-qualifications for
partners can usually be answered by visiting Microsoft Azure Partner Specializations

Questions on the audit checklists and program can be sent to the Azure Partner Specializations help alias
<mailto:AzureAS@microsoft.com>

If you have questions that have not been answered , please go to Partner Center support to create a ticket with
our Frontline team.

22

You might also like