Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 5 Next »

ASD-DSD Architecture

Contents

  1. Intro | context 2

  2. TC cloud infrastructure overview w/ OPIs and support channels.

2.1       Our TC Cloud Infrastructure.

2.2       CoEs (Center of Expertise) and Support Channels.

2.3       Licensing Considerations.

  1. Cloud Services Provisioning Guidelines & Best practices.

3.1        Power Platform application development is back ended by CDS.

3.2       Power Platform environments and Azure virtual services & resources are leveraged across project initiatives.

3.2.1      Azure provisioning practices.

3.2.2      Power Platform – Application Lifecycle Management (ALM) practices 

3.3        Azure Cloud – recommended naming & tagging conventions.

4 Project Development Guidelines & Best practices.

Annex A - Resource References.

Annex B – ASD-DSD Azure & Power Platform Gatekeepers | Overseers.

Annex C – ASD-DSD Azure & Power Platform Provisioning Tracking.

C-1       Azure Resource Group Provisioning.

C-2       Power Platform Provisioning.

1.    Intro | context

Whereby existing infrastructure documentation is technically oriented towards the minutia of environment configuration, this guide aims at  presenting the essentials for understanding the cloud infrastructure and services available within TC for application developers and sets forth some governing best practices for provisioning virtual infrastructure and leveraging SaaS services.

In conveying this content, both internal TC documentation as well as public references are given to augment the general guidance. Collectively, the material contained within plus the direct document references should give a strong basis of understanding of the TC Cloud infrastructure & services and what each are used for as well as the current support channels for each – as available.

1.    TC cloud infrastructure overview w/ OPIs and support channels

Whereby RDIMS-#16355261 - Overview TC pB Cloud Infrastructure in Azure gives detailed cloud platform insight, illustration 2.1 below summarizes the main elements of the TC cloud. 

2.1       Our TC Cloud Infrastructure

Essentially there are two tenants to be considered for the purpose of application development and deployment.  The Azure tenant is the Protected B (pB) environment of virtualized infrastructure and SaaS service offerings and the other tenant is the Power Platform tenant where Power Apps, including Dynamics 365 and Power Apps, are built and deployed.   DevOps and M365 as SaaS are delivered through the Azure platform.  The Common Data Service (CDS) within the Power Platform is enabled through Azure services.  The main aspects of environment access, configuration and Center of Excellence (CoE) points of contact are as follows:

Azure Tenant – Virtualized infrastructure & SaaS services

Power Platform Tenant – Dynamics 365 & Power App development with CDS; Power Automate; Power BI

DevOps (DSD-ASD) SaaS through Azure – project development environment & task tracking, GIT codebase repositories.

M365 SaaS through Azure – Enterprise subscription delivering O365, SharePoint, MS Teams, One Drive

All of these are accessible through user.name@034gc.onmicrosoft.com credentials; assuming licensing and environment configuration has been done for your account.

 

2.2       CoEs and Support Channels

This section highlights the organizational touch points for the varying aspects of cloud and identifies an OPI individual and support channel, where relevant.  Note as organizational roles change this section will need to be kept current. 

Key leaders & players in the Centers of Excellence:

 Ken Morency - Azure | Cloud Infrastructure (CoE)

  • controls the main TC azure tenant.

 Robert Robinson - Power Platform (Dynamics 365 & Power App); also, re: DevOps as stated by Bryen Begg:  Azure DevOps SaaS solution is owned by Rob Robinson of Solution Centre.

  • Irina Krasteleva is driving a lot of this, and under her Michel Ouellette is the main resource administering the TC tenant.  They have the CoE Toolkit and are standing up the CoE.

Pierre-Louis Ponton – M365|O365

Enterprise Architecture (EA): as of right now, reach out to the Manager of EA – Chris Gamberg.  The named Director of Enterprise Architecture has still not been announced.

2.3       Licensing Considerations

Developer licenses:

For developer licenses and extra storage – TC purchases licenses through Dell: 

Dev licenses are $81/user/month – part # Dyn365E for Customer Service - includes 250mb storage per user

Extra storage is $34/GB/month – part # CommonDataSrvcDBCpct

 

Case management licenses:

For user licenses – TC purchases licenses through the Softchoice protected B contract.

$21.20/user/month and includes 250MB of storage per user – part # DYN365EFORCASEMGMT

The case management licenses include D365 (Model-driven Apps) and Canvas-Apps & also Power Automate (triggering or terminating in a Power App; see notes below) and covers all environments.

 

Power App – per app licenses:

For user licenses – TC has purchased direct from MS | standing offer for $11/app/month.  This licensing model restricts the user to apps in a specific environment, e.g. PRD or ACC.  It is intended for light touch users whereby a user can interact with 2 apps per environment under this model.

Notes:

  • Standalone Automate solutions not tied to a Power App licensing has been confirmed with MS as covered by the enterprise site license for M365|O365 within the capacity and API request allotments. 

  • Internet-facing portal licensing has yet to be worked out by the department.

 

3.    Cloud Services Provisioning Guidelines & Best practices

 

3.1       Power Platform application development is back ended by CDS

 

Architecture Position Statement:  Power Platform application development is back ended by CDS unless rationalized to be another external data source, e.g. Azure SQL database.

Briefly about CDS:

CDS is a native and intrinsic database system to the Power Platform.  CDS runs on Azure in that it stores the data, retrieves it and controls it using Azure services which include Azure SQL database, SQL elastic pools used for relational data, blob storage for the non-relational data, search, and CosmosDB for logs.  CDS easily structures a variety of data and business logic to support interconnected applications and processes in a secure and compliant manner.  CDS is entirely abstracted behind an API end point, itself fronted by a security layer (authentication, authorization, auditing), then a logic layer (e.g. business rules, workflows), then data (e.g. modelling, reporting, validation, CDM), then storage (relational, files & blobs, logs, serach|find, data lake for large), and then integration (eventing, webhooks, data export).

Standardized business entities are defined with the Common Data Model (CDM) and this can be extended by custom relational entities.  CDS is not just a data source, it is the complete platform that can orchestrate how an app works when it comes to business logic, security model, integration, administration and governance. Therefore the CDS is considered a smart, scalable and secure solution

Applications can leverage external data sources through connectors or virtual entity configurations where necessary, but the core persistence for the application and the operational data store should be CDS unless it is otherwise rationalized. 

When adopting CDS be mindful of the inherent data management and inability to connect to a database directly; i.e. it relies on REST API and a Data Export Service.  Furthermore, Power Apps canvas can be built across a connector, but model-driven requires CDS. 

Power Apps developed as an interim solution to the COTS end state, or even finding themselves maintained long term as falling outside of the COTS functionality, can be integrated:

i)  Through the CDS RESTful Web API, which implements the OData provider, in terms of the COTS solution integrating into the CDS; and

ii)  Also through leveraging virtual entities &/or external data source connectors for the Power App integrating outwards to the COTS solution. 

 

Again be mindful as the CDS is leveraged for more than its data entity abilities, any logic developed would need to be considered for re-platforming should it be decided that a Power App & its scope of data be implemented elsewhere in another enabling technology; consideration should include process automation, business rules and other features inherent in the CDS.

3.2       Power Platform environments and Azure virtual services & resources are leveraged across project initiatives

Architecture Position Statement:  each individual Power App does not get its own environment and, where utilized, its own allocation of azure virtual resources, but instead is collaborated within a set of shared environments and resources through an ALM strategy implementation and adherence.

3.2.1     Azure provisioning practices

Azure Resource Manager is the deployment and management service for Azure. It provides a management layer that enables administrators to create, update, and delete resources in the Azure account. Therein management features, like access control, locks, and tags, secure and organize resources after deployment.

Considering resource groups,

  •        All the resources in a group should share the same lifecycle - deploy, update, and delete them together.

  •        Each resource can only exist in one resource group; however, a resource can move from one resource group to another group.

  •       Can add or remove a resource to a resource group at any time.

  •        A resource group can contain resources that are located in different regions.

  •        A resource group can be used to scope access control for administrative actions.

  •        A resource can interact with resources in other resource groups. This interaction is common when the two resources are related but don't share the same lifecycle (for example, web apps connecting to a database).

  •        When creating a resource group, need to provide a location for that resource group.  For compliance reasons, may need to ensure that data is stored in a particular region.

 

Refer to Annex A – Resources, Azure Provisioning Guidelines

Sidebar note: consider further replicating the guideline essentials within this section.

3.2.2     Power Platform – Application Lifecycle Management (ALM) practices

A sandbox environment supports development (dev) and quality assurance & acceptance testing (qaat|acc) activities; production environments are where the applications are put into operation for their intended use.

There will be specific and controlled ASD-DSD environments for the formal project undertakings for DEV, ACC & PRD.  Within these environments, projects are contained within Solutions, each which have Publishers. Solutions are the mechanism for implementing ALM; you use them to distribute components across environments through export and import (i.e. Solutions are used to transport apps and components from one environment to another).  Makers and developers work in development environments using unmanaged solutions, then import them to other downstream environments—such as ACC—as managed solutions. For the CDS, Business Units form the security modeling building block for common versus business area specific entities and data.  A well collaborated and common base of shared entities supporting ASD business applications is a primary goal as opposed to silo, single purpose and disconnected data sources. Proper prefixing will bring clarity within the solutions as well as the CDM. 

This is summarized as follows:

Business Units

A business unit basically is a group of users.  Large organizations with multiple customer bases often use multiple business units to control data access and define security roles so that users can access records only in their own business unit.

a.       TC is the top level

  i.      ASD would create one called “ASD” under TC

1. Then, would create additional BU’s under ASD

a.       APA

b.       AMERC

c.        Etc.

Solutions/Publishers

A solution is a container that encompasses Dynamics 365 CRM components.
A publisher is associated to a Solution, and is used to identify the prefix that will be used for any new entities that are created in the Solution.

b.       Would have a common Solution for ASD, which would contain entities that are potentially useful to multiple applications in ASD. 

i.      Any entities that would be created in this Solution would have a prefix of “asd_”

c.        Each project would then have their own solution which would identify a Publisher with a specific prefix.  For example:

i.      Solution “Airworthiness Planning Action” would use prefix “apa_” for any entities created which are for APA purposes only.

Refer to Annex A – Resources, Power Apps – ALM (Application Lifecycle Management) Practices for full guidance.

Sidebar note: consider further replicating the ALM essentials within this section.

 3.3       Azure Cloud – recommended naming & tagging conventions

As per MS guidance docs, organizing your cloud-based resources is critical to securing, managing, and tracking the costs related to your workloads. To organize your resources, define a management group hierarchy, follow a well-considered naming convention, and apply resource tagging.

https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources

As per MS guidance docs, organize cloud assets to support operational management and accounting requirements. Well-defined naming and metadata tagging conventions help to quickly locate and manage resources. These conventions also help associate cloud usage costs with business teams via chargeback and showback accounting mechanisms.

Azure defines naming rules and restrictions for Azure resources. This guidance provides detailed recommendations to support enterprise cloud adoption efforts.

Changing resource names can be difficult. Establish a comprehensive naming convention before you begin any large cloud deployment.

https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging?WT.mc_id=email

 4.    Project Development Guidelines & Best practices

Project Management Position Statement: Our approach to Power Platform Application|Solution development involves adhering to these key points during project undertakings:

  •   Adopt agile philosophies.

  •   Indeed focus on working solutions and code over reams of documentation while recognizing and producing the required essential supporting documentation.

  •   Compartmentalize the solution into successively detailed work items leveraging DevOps: Epic – Feature – User Story (product backlog item (PBI) in scrum) and, lastly, tasks to achieve the PBI.

  •   Prioritize the backlog and organize into Sprints (2-4wks duration). 

  •   ROM (rough order magnitude) estimate the Epics-Features-User Stories|PBI for governance (budgeting & project tractability) purposes. 

  •   During Sprint planning, carefully elaborate the discrete tasks and accurately define total effort. Stakeholders are fully involved in managing the PBI and planning | prioritizing the items within the upcoming Sprint(s).

  •   Throughout Sprint execution, track work remaining and update total effort as required (for traceability, velocity tracking and future capacity planning). 

  •   Impose and adhere to the daily standup.  Each participant briefly describing the following:

    • i)         what was completed last period (i.e. yesterday)

    • ii)       what will be done this period (today)

    • iii)     state impediment(s) which should be recorded and actioned by the PMO and whatever teams members required to resolve the impediment(s). 

  •   During the daily standup, no team member should be talking about a task that isn’t on the Kanban board in the current Sprint.  If there is task discussion beyond the board, there is disconnect or a missing, and likely meaningful, task that needs to be added. 

  •   During the Sprint retrospective, detail what worked and what didn’t work so well and strive for continuous improvement.  Optimally a Sprint produces tangible, and in terms of software solutions, deployable working elements therefore the stakeholder are given an opportunity to discuss and see demonstrated the tasks completed - i.e. inspect what was produced,

Project Management Position Statement: The DSD-ASD SDLC during an Agile project undertaking involves these key activities and phases of progression:

Solicit and document requirements - ensure UX|user research aspects are fully covered; ensure the to-be state is considered when re-engineering legacy (never simply recreate the as-is without determining the to-be with users|stakeholders).

Design|Wireframe & Storyboard (e.g. Use Case (UC), business process model, data model, Functional System Design (FSD) if very complex or involved) – layout elements & describe process flow and business rules iteratively with solution owner(s); stakeholders.

Develop using the following guidelines:

i) With model-driven, upfront schema design (completeness & accuracy) is important;

ii) Implement functionality in accordance with workflow and usage;

iii) The tighter the design iteration results in less flux in application rework;

iv) Employ best practices, e.g. coding conventions, have meaningful controls and variable names. This is especially important on code referenced controls(see the ASD-PowerApp File collection in MS Teams where they discuss an iterative approach with solution owner(s); stakeholders on an epic, feature or even PBI (user story) basis; a discrete task completed usually isn’t significant to justify a stakeholder review.

QAAT - obtain user acceptance.

Deploy & Support considering the following:

iv)      Requires at a minimum an Authority to Operate (ATO), a Security ConOps, an SOS and a LOA to provide to security for review.  Security will then provide a SRTM to be populated and to fulfil security considerations;

v)       Furthermore a PPIA w/ ATIP; and architecture views to describe the solution (business, application, data, and infrastructure) may be called upon throughout the ATO process. 

vi)      Depending on the nature and complexity of the solution, a more comprehensive review & approval process may be instilled on the project; e.g. full ARB (architecture review board) process.

Annex A - Resource References

Document Reference

 

Commentary

Within MS Teams: ASD-PowerApp see the File collection.

 

PowerApps canvas app coding standards and guidelines.

 

 

RDIMS #16355261

Overview TC pB Cloud Infrastructure in Azure.

 

 

Within MS Teams: ASD-PowerApp see the File collection.

 

Power Apps & Automate Licensing Guide – May2020

Within MS Teams: ASD-PowerApp see the File collection.

 

Power Apps – ALM (Application Lifecycle Management) Practices

 

Within MS Teams: ASD-PowerApp see the File collection.

 

Azure Provisioning Guidelines

 

 

 

Annex B – ASD-DSD Azure & Power Platform Gatekeepers | Overseers

Gatekeeper | Overseer

Commentary (R&R, operational insight and the like)

 

 

 

 

 

 

 

 

 

  • TBD | documented once the initial review has been completed.

 


 


 


  • No labels