[[_TOC_]] * * * Goals and Pre-Requisites ======================== The primary outcome of the Analysis Party is to extract meaning out of available data and initiate the full assessment of the portfolio of applications. Typically, the Analysis Party will follow **1-Portfolio Discovery and Initial Planning**, although it can also be performed independently whenever data is already available from other sources. This can be the case when a Discovery Tool has been deployed or when previous Discovery related engagements have taken place. The main pre-requisite is the availability of 1 full week of programmatic data collection as a minimum (or equivalent data) from all in-scope systems, including asset communication data in order to evaluate application dependencies. Checklist --------- - Expectation setting with the customer executive/leader for the event  - Review tactical and strategic goals of the event, discuss expected friction points - Establish the logistics to escalate to the customer executive if it is needed during the party itself. - Confirm attendees from the customer who will represent roles and responsibilities listed in attendees (see agenda). These attendees should be a mix of doers and decision makers - Preview expectations with the attending leaders of each domain (security, applications, etc.) - Document assigned roles and expected attendees by session / tracks - Confirm logistics for the meeting (single meeting room for all participants or preferred customer tool for virtual collaboration) - Confirm infrastructure and application data set is complete and ready for use in the party Analysis Party Agenda & Sessions ================================ Analysis Party Agenda & Participants [Agenda%20&%20Attendees%20-Portfolio%20Analysis%20Party.xlsx](/.attachments/DK-Portfolio/Agenda%20&%20Attendees%20-Portfolio%20Analysis%20Party.xlsx) Activity Details ---------------- | Day | Session | Details / Guidance  | Artifacts | | --- | --- | --- | --- | | **Day 1** | Opening and Goal Setting | Establish goals for the day | | | Asset & Dependency Output Review | This session serves as a quick review of the available data. Typically, the output of the discovery tooling or equivalent data. The goal is to level-up on how to access the data and how it is presented. This session is a high-level review to level-up attendees on data usage and format. | Discovery Tool of choice or equivalent source of data | | Review/Validate Application Stacks | When discovery tooling is being used, some of these tools will have the ability to auto-generate application stacks (note that this could have a different definition depending the tool). Overall, this feature uses internal algorithms to analyze processes and communication data in order to determine (indicatively) which infrastructure components (such as servers) seem to make up an application. In some cases, the name of the application itself will be suggested, this is typically the case for well-known commercial products. However, for proprietary applications or when there is a specific internal name for a commercial product, these will not be detected. In these cases, the application will appear as either 'unknown application', 'auto-generated stack', or by some type of definition inherent to the discovery tool. These are the ‘stacks’ that must be validated during this session. Likewise, when alternative sources of data are being used, this session should focus on validating the mapping between application and infrastructure, dependencies, and to obtain further application metadata according to data requirements. Work with the relevant stakeholders to name/validate the applications and to validate/update the associated infrastructure as needed. Also, collect additional attributes, at a high-level, such as environment, owner, location, criticality, existence of disaster recovery components, and others. In addition, highlight complex applications that might require special treatment and cases where AWS offerings such as SAP, Mainframe, Windows, DB Freedom could apply. **Important Note 1:**  when tooling is being used, educate the stakeholders that the tool automates the process based on a given logic combining process and communication data. Validating the suggestions of the tool is a necessary step that requires manual review. When using a discovery tool that does not have the capability to auto-generate application stacks, the mapping of application to infrastructure becomes a manual effort. The amount of effort will depend on the information provided by the tool. For example, if ADS (AWS Application Discovery Service) is used, it will be required to manually review communication data to associate the servers to an application manually. Migration Hub includes a graphical interface that can be used. However, this will be time consuming. In these cases, use the time allocated in the Analysis Party to educate the participants on the process and to identify as much applications as possible. This will help the working group to get familiar with the process and to be able to complete it over the subsequent days or weeks. **Important Note 2:** even in the cases where the discovery tooling does automated application to infrastructure mapping, depending on the size of the scope, the time allocated in the party might not be sufficient to validate all applications. Ensure the stakeholders are comfortable with completing the remaining applications post-party. It is recommended to plan for potential further sessions in advance or adjust the party length accordingly. | Discovery Tool of choice or equivalent source of data **Template - Application and Infrastructure Inventory****Data Collection Requirements (all stages)** | | Wrap-up Day 1 | Review outcomes of the day and next steps | | | **Day 2** | Opening and Goal Setting | Establish goals for the day and address any open item | | | 7R Disposition Tree  | The 7R Disposition Tree is used as a guide for Application Owners and Architects, among others, to evaluate which path to take when migrating an application. Each project will have unique circumstances and decision-making processes that need to be incorporated into the tree logic. A default 7R disposition tree is included with this guide. Iterate it and test it with sample applications, and introduce as many changes as necessary. In addition, ensure the definition of the 7Rs is agreed among stakeholders. This could include changing those definitions if the stakeholders feel comfortable with an alternate description or naming. For example, some teams prefer to separate between Refactor and Rearchitect whereas, by default, AWS groups both together. Ensure a common language is used across Customer, AWS and Partners. **Important Note:** this session is a first iteration of the tree, it will require further reviews and updates based on learning and data gathering to reach a baselined version. This typically takes 2 to 3 weeks. | **Artifact - 7R Disposition Tree** | | Application Prioritization Criteria | The goal of this session is to establish which key attributes will determine the order in which applications should be migrated. This is a key input for constructing migration wave plans. If tooling in use lacks the capability/features to perform prioritization, use the Migration Portfolio Assessment ([MPA) tool](http://mpa-proserve.amazonaws.com/) (available to AWS Employees and Partners). It will be required to export all application and infrastructure data from the discovery tool and import it into MPA. Request permission from the data owner(s) to upload their data into MPA.  When exporting data, consider exporting all assets (applications and infrastructure), as well as Communication (or dependency) data. The communications data will be required for the Wave Planning session (later in the agenda) with MPA. Once the data has been imported into MPA, navigate to the Plan section, application prioritization. The objective is to decide, alongside relevant stakeholders, which application attributes will be used to prioritize the order in which applications will be moved to AWS, and then assigning a corresponding weighting to the possible values of those attributes. Next, define the attribute relevance level for prioritization. If MPA is being used, the higher the relevance the higher the importance of that attribute for prioritization. Customers will typically prefer to migrate non-critical applications in the initial waves such as non-production or dev environments. For example, if a Development application from specific business units/departments are good initial candidates, the environment and business unit attributes will have higher relevance (for prioritization) in MPA than other application attributes. The result will be a ranking of applications. If the weighting/criticality is correct, the top 5 should be good initial candidates for migration. If the top applications do not make sense, adjust the criteria and recreate the list. It takes several iterations to reach a baselined version. | Discovery Tool of choice or equivalent source of data [Link to MPA](http://mpa-proserve.amazonaws.com/) **Artifact - Application Prioritization Criteria** | | Validate Wave 1 (or pilot apps) candidates | This session focuses on validating the outcomes of the Initial **1.4-Preliminary Portfolio Analysis** and **2.1-Application Assessment Party** in order to confirm/validate/update Wave 1 scope. | | | Initial Wave Planning | The objective of this session is to leverage the prioritization criteria and start shaping a wave plan. Note that Wave Planning can take several weeks. The intention of this session is to outline a first draft and focus on validating the first few Waves, especially Wave 1. How much can be achieved during this session will depend on the data available, the participants, and the size of the scope. If the Discovery Tool of choice does not include Wave Planning features, the [MPA tool](http://mpa-proserve.amazonaws.com/) can be used (available to AWS Employees and Partners) to construct the plan. Ensure all assets and communications data have been exported from the discovery tool (or equivalent) and imported it into MPA. This information is key to aid the Wave Planning process. | **Wave Planning** [Link to MPA](http://mpa-proserve.amazonaws.com/) | | Wrap-up Analysis Party | Review of Party outcomes and next steps (e.g., ad-hoc sessions to iterate/finalize elements of the agenda) | | Primary Outcomes ================ 1. **Infrastructure and Application Inventory -** Inventory should include: 1. List of all VM hosts, physical and virtual servers in scope and their attributes 2. List of applications and the relevant attributes utilized for sizing, prioritization, disposition, categorization, etc. 3. Server to applications mapping 4. Server to server communication 5. Database inventory 6. Database to application mapping 7. Application to application dependency 2. **A Tested/Iterated 7R Disposition Tree** 3. **Prioritization Criteria** 4. **Validated Wave 1** 5. **Migration Wave plan (draft)** 1. MPA export 2. Other (Vendor option, modified/custom) **Attachments:** [Agenda%20&%20Attendees%20-Portfolio%20Analysis%20Party.xlsx](/.attachments/DK-Portfolio/Agenda%20&%20Attendees%20-Portfolio%20Analysis%20Party.xlsx)