1. Questions/Concerns
1.1. Do the SSIS packages replicate the entire application database or just a slice to support reporting. DB2 to SQL?
1.2. What will MSFT fund? We probably need to scope the longer-term ACR to answer this
1.3. How are new tables (Expense Distribution, Invoice Line) intended to be used in line with authentication?
1.4. Does the solution need to account for load balancing and/or HA?
1.5. Does Centerplate want reports re-written in PBI?
1.6. Are there any considerations we need to adhere to related to data sensitivity (PII, PCI, SOX, GDPR, etc.)?
1.7. Can we use a single resource to support both DevOps and .Net dev support for discovery?
1.8. Internal or external customers?
2. Team
2.1. PM
2.2. BA
2.3. S&D Analyst
2.3.1. Need to confirm with York - role here
2.4. Cloud Arch
2.4.1. DevOps
2.4.2. .NET Dev
2.5. Data Engineer
3. Assumptions/Risks
3.1. Both old and new applications will be live together, with a phased roll off to switch over to the new application
3.1.1. Need to consider how we handle data changes being made between these two application databases to keep data in sync
3.2. Modern Apps not needed until second phase (Application re-write)
4. Next Steps
4.1. Estimation Spreadsheet
4.1.1. Target Completion Friday 10/8
4.2. Create a SOW
4.2.1. scope is focused on the Portal only
4.2.2. Discovery effort
4.2.3. Target Completion for Draft Monday 10/11
4.3. Application re-write would be a later phase and not part of this initial engagement
5. Client Needs
5.1. What the Client has
5.1.1. They have a “portal” application in progress in Azure that someone at Centerplate built
5.1.1.1. That person left the company, so It's unfinished
5.1.1.2. Integrated with Azure AD, roles-based architecture
5.1.1.3. Want to use as much of what is already built as we can
5.1.2. Workcenter is a legacy Java app with several business functions, backed by IBM DB2 database with 14GB+ data
5.1.2.1. Long-term goal is to decommission Workcenter
5.1.2.2. Wants to move to .NET on Azure, rewrite over time
5.1.3. Has SSIS packages that move data to Azure SQL from DB2, SSRS looking at that SQL instance, could move to Power BI
5.1.4. On-premise application looking to be migrated to the cloud
5.1.4.1. Move to .NET in Azure
5.2. Goals
5.2.1. Rebuild accounts payable and accounts receivable modules in portal
5.2.1.1. Accounts payable currently integrates with Lawson financials, but will need to integrate with Sodexo’s ERP (SAP)
5.2.2. Leverage Azure Pipelines and DevOps approaches to Cloud infra management as much as possible
5.2.2.1. Client has asked a few times about Azure DevOps vs. GitHub – I think he’s looking for direction here to feel like he’s doing the latest and greatest and will get support
5.2.2.2. Setup pipelines to promote from single QA environment to production
5.2.3. Utilize existing Portal, as much PaaS as possible (mentioned Serverless several times)
5.2.4. Integrate with AD
5.2.4.1. Role based authentication
5.2.4.1.1. Leverage an accounts table
5.2.4.1.2. Leverage a roles table
5.2.4.1.3. Create a new Expense Distribution Table
5.2.4.1.4. Create a new Invoice Line Item Table
5.2.4.2. New roles that don't exist
5.2.4.2.1. Accounts Payable
5.2.4.2.2. Accounts Receivable
6. Approach
6.1. Discovery first with focus on the Portal
6.1.1. Review SSIS packages
6.1.1.1. Including audit logs
6.1.1.2. Look for solution that has least impact on applications with syncing
6.1.2. Understand dependencies between both applications running in parallel
6.1.3. Review Application Database schemas
6.1.4. Understand user processes for updating data in DB2 application
6.1.5. Destination environment assessment
6.1.5.1. Cloud platform environment
6.1.5.2. DevOps processes
6.2. Understand if this is a rebranding effort for the portal
6.2.1. Understand full desired requirements of the portal
6.2.1.1. including functionality
6.2.1.2. including role based authentication
6.2.2. Understand how much functionality can be reused
6.2.3. Understand gap in functionality of existing portal
7. Deliverables
7.1. Roadmap and implementation plan
7.1.1. Our recommendations
7.1.1.1. what can be leveraged from existing functionality
7.1.1.2. What to create new
7.1.1.3. how to update and sync data
7.1.1.3.1. including custom ETL processes
7.1.1.3.2. Including schema updates
7.1.1.3.3. Including custom extracts of data
7.1.1.4. SSRS vs PBI for reports
7.1.1.5. DevOps pipelines
7.1.1.5.1. governance
7.1.1.5.2. process for deployments
7.1.2. Effort and cost estimates
7.2. Dependencies matrix between application databases
7.3. Integrations gap analysis for functionality
7.4. Evaluation of current architecture and functionality and gap analysis
7.5. Right sized architecture diagram for expected customer volume use
7.5.1. number of users
7.5.2. location of users
7.5.2.1. US
7.5.2.2. Canada