The Request Owner is the User/Group/Org that has been Assigned as Accountable for this Allocation Request. By Default the Creator of the Request is Owner and Accountable.
\" },\n { Id: \"Dynatrace Request Status\", tipText: \"This status indicates that the allocation exists for capacity and cost estimation only. Will not show up as a request for EOT consideration.
\"+\n \"This status places the Dynatrace request in the EOT's queue of new requests, awaiting a response. Once progressed to In Review no other changes will be permitted on the allocation by the App/Platform team except to Withdraw the request
\"+\n \"This status indicates the App/Platform Dynatrace deployment is on hold and wait until the EOT has reviewed the new information submitted.
\"+\n \"The App/Platform is being considered within a Coverage phase but more information is needed by EOT. A project Task is open to track and collaborate on this request (see Allocation Task for Details).
\"+\n \"This Allocation request is finalized and cannot be reopen
\" },\n { Id: \"Dynatrace Request Disposition\", style: \"height: 300px;\", tipText: \"The App/Platform team is ask to hold-off until the EOT can verify capacity, support, provisioning and licensing capacity.
\"+\n \"The Enterprise request for deployment has been declined, may be due to support, licensing, capacity, capability or a variety of other reasons.
\"+\n \"This status indicates the App/Platform Dynatrace deployment and the progress of that approval. See Application Tasks to view related activities
\"+\n \"The Request is over and has been Ended by Either the EOT or App/Platform team. Either EOT and/or App/Platform team can re-open the request, however, it will be immediately placed back into New status.
\" },\n { Id: \"Allocation Cost Center\", style: \"height: 100px;\", tipText: \"The Cost Center selected in the Allocation only serves to perform Cost Estimation Allocations. Cost Centers in Elevate have a default Rate Group by which they calculate the configured chargeback costs. If no Cost Center is selected then Cost Estimations will be excluded from the allocation.
\" },\n\n { Id: \"Provider\", style: \"height: 125px;\", tipText: \"An Instrumental part of Elevates Observability Blueprinting is capturing all of the Infrastructure providers that will are involved in Application/Platform deployments. Providers refer to any company that is responsible for providing the physical/virtual infrastructure to be monitored. For example the common cloud providers that will often show up here, like, Azure, AWS, Google, etc. The Enterprise should also appear to indicate all on-premise hardware and/or internal private clouds.
\" },\n { Id: \"Region\", style: \"height: 150px;\", tipText: \"For every provider that appears in the Blueprint, they should all have one or more regions where the infrastructure is located. Not only should we be consistent with how Cloud architectures are captured but it dramatically helps in organizing observed entities and telemetry targets. The regions should exactly match the regions for each of their respective cloud providers and if the provider is the Enterprise itself those regions should either be aligned with exactly how the Enterprise codes them and, if not then they should be aligned with one of the common cloud providers preferred by the Enterprise.
\" },\n { Id: \"Location/DataCenter\", style: \"height: 200px;\", tipText: \"These are used interchangeably in Elevate. The reason its identified either or, is because many Enterprises have large numbers of branch offices (locations) that may be monitored. However, more commonly these will be data centers where large shared infrastructure is located. This is where the Apps/Platforms are deployed and Dynatrace Agents reside. When defining the data centers for common Cloud providers these are interchangeable with what Cloud Providers refer to as Availability Zones. Therefore, when defining a data center for a cloud provider it should exactly match the name of the Availability Zone. Often times, Enterprises will assign their locations / data centers with a short name or code in which case these should match theirs for clarity within reporting and the interface.
\" },\n { Id: \"Zone\", style: \"height: 100px;\", tipText: \"A subgrouping of IT assets that restrict access to other IT assets. The most common definition being a domain of a network that represents the logical hierarchy of subnetworks such as DMZ, Secure, and Internal. This can also extend to use cases in the public cloud where specific accounts/subscriptions are limited by security constraints.
\" },\n { Id: \"Dynatrace Needed By\", style: \"height: 125px;\", tipText: \"This is the date that the App/Platform team is requesting to have Dynatrace deployed for their App/Platform Logical Environment and Location. While this may be the desired date the EOT may require more time and the team should confirm/negotiate the actual viable dates with the Enterprise. The EOT is ultimately capacity planning for a group of applications for a specific deployment Goal Date
\" },\n { Id: \"Allocation Need Ends\", style: \"height: 100px;\", tipText: \"Allocation End Dates are typically chosen under a variety of reasons. The App/Platform may be migrating to a different location/data center, cloud provider, or major changes need to be made and this is used to expire this allocation and request a completely new one for this location and environment.
\" },\n { Id: \"Footprint\", style: \"height: 150px;\", tipText: \"The App/Platform may have entirely different Footprints that they deploy to. For example an Application that have a legacy on-premise version that deploys to bare-metal boxes may also be migrating their application to a hybrid or fully-hosted version in the Cloud. These type of scenarios can be managed using Footprints as a way to divide the Application's deployment schemes and monitoring differently while maintaining the fact that it's still the same application.
\" },\n { Id: \"Logical Environment\", style: \"height: 300px;\", tipText: \"An Applications Logical Environment typically depicts the primary purpose of the App/Platform deployed binaries/code. While each Application:Footprint may have a wide variety of Logical Environments for which they deploy, it is best to standardize on a more finite list when Managing observability and \"+\n \"requesting Dynatrace coverage. While Elevate accomodates the ability to capture each applications Logical Environment names exactly it is better to standarize on a more finite list of \"+\n \"PROD and NON-PROD environments. It's also very important to maintain a very distinct separation between PROD and NONPROD environments since the EOT will often send Dynatrace Agent Data to \"+\n \"different environments depending on PROD and NON-PROD. We also do not want Dynatrace Davis AI blending traffic and activity for the two when evaluating baselines, performance and Problems.
\"+\n \"If none of the Logical Environments listed properly represent the need then a new one can be created by navigating into EOB->Applications->(Choose the Footprint) and finally under the Footprint profile it can be added accordingly.