Introduction

IT Architecture within an enterprise involves multiple processes, with the path chosen depending upon the context, scope and objectives.

One can do "simple" architectures leveraging existing information, as-is architectures that define a current system, and to-be architectures that define target architectures. The architecture can also be focused on a specific aspect of interest (e.g. "location", namely the IP network, storage and servers). This roadmap describes a suggested approach to the practical use and application of UAM in the enterprise for various uses and objectives.

IT Architectures may also be define at multiple levels within the enterprise, from the enterprise level (i.e. EA) down to project level and everything in-between. This context does not affect the usage of UAM, these typical uses all follow the standard UAM IT architecture development processes.

Guidance is provided for the following IT architecture situations and objectives:

• Define a to-be architecture;
• Define an as-is IT architecture;
• Define a "simple" architecture;
• Define a focused IT architecture (e.g., the IT enterprise network).

Define to-be Architecture

This is the typical approach for IT architecture development. THe UAM processes may be used as defined, but adapted to the situation and needs to your particular enterprise. This adaptation simply involve the integration of the UAM define milestones into the existing enterprise processes and reviews. Development of the actual perspectives, views, and models follows the UAM processes. See: Delivery Process: IT Architecture Delivery. 

Define as-is Architecture

An as-is  IT architecture is defined to document an existing operational system that does not have an associated IT architecture. Therefore, it is based upon existing development, training, operations, and other documentation. The architecture is defined at the Technical level, unless there is major re-work of the system needed, in which case the Logical level would also be defined. Note that this architecture is defined in a bottom-up fashion, since all of the documentation that exists is at the Technical level. UAM defines an activity specifically for this bottom-up approach; see: Activity: Document an Existing Architecture and Phase: Document Existing Architecture.

Define Simple Architecture

A "simple" architecture is not necessarily smaller or simple. A simple architecture is defined in an expedited fashion by exploiting existing IT architectures and other documentation. This architecture is typically defined to address an important issue or opportunity. This approach typically is also combined with the "focused" approach ... to quickly define a solution to an issue, or the approach to exploiting a business opportunity.

The only difference between the to-be approach, and this fast-track approach is the level of effort applied to researching the system and solutions (e.g., no workshops may be held, just small focus groups or meetings with stakeholders), along with the type of documentation used in developing the architecture (i.e., existing documentation).

Define Focused Architecture

A focused architecture defines a subset of a complete perspective. This focus, defined by the objectives of the IT architecture, is typically on on aspect for the IT architecture. It may be any aspect, Entity aspect or Location aspect for example, or even a combination of aspects. A typical focus is on the Locations aspect, specifically to define the enteprise's IP network infrastructure and associated technical standards.

The only difference between the to-be approach, and this focused approach is the level of effort applied to researching the other aspects of the system. The same activities, types of documentation, and processes are used in developing the architecture, but aspects out-of-scope are not defined or are only simply defined.