Artifact: Technical Environment |
This artifact is an inventory of an enterprise’s existing technology resources and related management aspects.
Domains: Requirements
Purpose
This artifact provides the basic data and information that is used to: Provide a base point against which new initiatives (for example an IT strategy assessment, an enterprise architecture engagement or development of one or more IT based business systems) can be defined Provide a basis for subsequent assessments of the IT environment for functional and technical quality Provide a basis for identifying gaps between the defined environment and future required environments Provide a basis for subsequent assessments of the effectiveness of: IT management, processes, policies, and plans Development policies and practices Accessibility policies and practices System management policies and practices Security and privacy policies and practices Give valuable insights into possible areas of key requirements, for both technical improvements to the IT infrastructure and the application portfolio. Provide a baseline for understanding the system changes necessary for new IT-based business solutions. These insights are key inputs to subsequent planning activities in support of strategic business directions and goals.
Description
Main Description | This artifact provides: An inventory of an enterprise’s installed applications, data, computing and network infrastructure, and the current security architecture indicating the existing or planned security zones, secure channels, or network security zones and trust levels. The current status of all of the non-technical, management aspects of the overall technical environment, including: The IT/IS/IT security organization(s), roles, and responsibilities The existing IT strategy, policies, and plans (including skills acquisition and sourcing options) Security policies, standards, and processes Development policies and practices System management policies and practices These details about the technical environment are summarized into a form that can be readily used as input to many future architecture, design, and infrastructure delivery and management activities, along with observations on current known IT/IS deficiencies, concerns, and user satisfaction with IT. It should be noted that this artifact is NOT intended for documenting the results of an assessment of the current technical environment. The artifact can be restricted in scope (for example, to the part of the technical environment affected by the introduction of a new package or system).
Brief Outline | The IT Environment typically includes the following sections: #### Introduction Describes the scope and context of the IT environment, and includes any other overview information that is of relevance. #### Hardware Usually production environments, but may include development and test environments as well (if this is relevant). Includes CPUs, peripherals, specialist devices (including hardware used by users who have disabilities), and communications hardware. #### Software This includes: Technical Software: Including systems software, middleware, and systems management software Application Software and Databases: Including assistive technology software Application Development Environment: Including development, test, and run-time systems. #### Management Processes This includes: An IT organization chart, including roles and responsibilities A model or list of recognized IT management and governance processes High-level process diagrams (where appropriate) A matrix of IT management processes and owners or participants
Key Considerations
The following general guidance is recommended: Aim to gather all of the inputs and information needed for a single project at the same time, regardless of the artifacts that will be defined. Plan the information gathering as a joint exercise between all interested parties, and agree on the tools and techniques to be used, especially as some information gathering activities will cross organizational boundaries. When gathering environment information, go beyond the classical information and determine if any limiting environmental situations exists (such as noisy plant floors, extra bright areas where it is hard to see a screen, or pervasive devices with small, text-only screens). Verify the IT Environment by review with the client sponsor and appropriate senior executives. It may also be appropriate to hold a peer and quality assurance review (a peer who has accessibility skills may be necessary in complex IT situations).
Tailoring
Impact of not having | Without a comprehensive understanding of the enterprises environment, it is likely that IT strategy, IT planning, architecture definition, transition planning, architecture assessment, and system and infrastructure design activities will not be soundly based. In particular: The same information will be required by different project tasks over time, and will be gathered separately and repetitively. The information will not be considered when developing alternatives and planning work, and issues will not be discovered until the cost of addressing them has increased. Interfacing and transitional issues associated with the introduction of a new package or system may be overlooked, or their impact underestimated.
Reasons for not needing | Potential reasons for not needing this artifact are: There is no existing systems or IS/IT organization, or the current environment can be completely disregarded (in other words, it is being replaced). The information has already been gathered as part of a previous IT assessment activity, and it is readily available in a form suitable for use in a future assessment. In this instance, time should still be allowed for reviewing the completeness of this material.
Representation Options | The IT Environment artifact is usually produced in the form of a report, but may also be delivered in presentation format, or may exist as one or more models created using a modeling tool. #### Notation The notation of the IT Environment is usually in the form of text with supporting tables and diagrams. Diagrams may be informal, or created using formal modeling notations such as the Unified Modeling Language 2 (UML 2).
© Copyright IBM Corp. 1987, 2009. All Rights Reserved. © Copyright ABC Corp. 2009. All Rights Reserved. Includes materials licensed from IBM and Eclipse. See IBM copyright and Eclipse copyright .