Pin Me

Engineering Environments

written by: Hans • edited by: Michele McDonough • updated: 3/14/2012

Engineering Environments are often described as a boy toy for System Operators or as a tool to legitimate decisions that don’t have any real background. Another saying is, that EE’s are only for big players, not for small companies. This article describes the idea of EE’s as a useful strategy tool.

  • slide 1 of 3

    Engineering Environments Defined

    The engineering environment (EE) sums up all hardware and software systems, network infrastructure and peripheral equipment required to do the daily work as well as project based activities.

    The basic engineering environment (BEE) defines all the EE components required to do daily work and to be the basis of running systems that are not project specific. The advanced engineering environment (AEE) defines all the additional components that are necessary to do the specialized project work and thus are project specific. The third part is the individual engineering environment (IEE) that defines all the components required by the individual co-worker that does not have to be project specific, but are to support the individual way of doing the things that have to be done. The last one is optional and should only be used when no other way is possible.

    Benefits from using EE's

    The goal of creating and defining EE’s is to predict stability, performance and other quality features of the systems used as well as costs (TCO), availability (time), and service amount required to maintain or adapt the system. A very useful side effect is the reduction of errors during the development process by avoiding external problems as follows:

    1.Reduce errors caused by administration of the system (different configurations lead to different behavior of systems, that may be recognized as findings).

    2.Reduce errors caused by compatibility problems among the co-workers machines.

    3.Ensure that all tools that have to be used are tested, quality approved, licensed in an economic way (smart licensing strategies are difficult but safe a lot of money).

    4.Ensure that the interaction of all system parts works properly and the whole system is adjusted for the actual projects needs at its best.

    5.Ensure that each EE is saved as an image to enable service guys to restore it in case of crashes within the guaranteed time span (internal and external SLA’s) and in a defined way.

    6.Images of an EE enable archiving for later access onto a project freeze for further development in an immediately running system, that ensures a fast project start when small changes have to be done that don’t include porting the legacy system.

    7.Enable the project management and the company's management board to establish a sustainable and economically efficient strategy for licensing, upgrading and reusing software licenses, hardware components and process definitions.

  • slide 2 of 3

    Basic Principles of Usage of EE's

    1. Only integrate what has been tested completely and has undergone a detailed QM-Check.

    2. Integrate a system in the order of BEE – AEE – IEE only and test each stage.

    3. Don’t allow individual updates, updates are applied in the central configuration services where the EE’s are created, tested and QM approved. Installation of updates to the EE’s follows a detailed planning that is part of the project plan, service planning (see ITIL). Milestones are a good time for updates.

  • slide 3 of 3

    Simple Process to Create EE’s

    When starting a project in the phase IP (e.g. Initiating a Project), all resources are determined and approved. The EE’s define the technical resources answering the following goal questions:

    Which tools are required?

    1. What is the goal of the project?

    2. Which ways do we want to go to reach that goal?

    3. What are the conditions and constraints for parameters like costs, techniques, technologies, restrictions by law, customer’s state of mind and individual situation and others that have to be kept in mind?

    4. Which requirements are fulfilled by available tool that already exist in the company, which alternative tools, newer versions or better usage (enabled by trainings) of the actual tools can be done?

    5. What did we learn from best practices and lessons learned that were required in former projects with reference to the tools used there (see Project Review)?

    6. What exactly is the business case one tool, tool set or EE will be used for?

    7. Will there be other business cases that can make (re)use of the actually defined EE, single tools or special configuration details?

    Which tools are available?

    1. Make a list of all developer requirements referring to the actual level of the EE (a BEE will be used for a longer time than an AEE or IEE, thus has other requirements)

    2. Find out the available tools at the company

    3. Perform a web based search for tools

    4. Go to fairs, attend presentation events, follow recommendations, review articles in good journals or at communities like Bright Hub.