Overview

UAM defines a number of "gates"—milestones where reviews of deliverables are done by various management fora. These are not UAM deliverables, they are external to the development of IT architectures, but are generally inputs to UAM. These fora are therefore excellent opportunities for IT architects to participate and provide guidance and advice, and to also get feedback. Most of these deliverables and fora are business management-related documents and business planning.

Each gate is defined below, followed by a presentation of the gates in the context of UAM inputs and outputs. Note that within your organization the names of these fora and documents may be quite different—adapt the gates as required (i.e., combine, eliminate, and change as needed).

There are three scenarios where IT-related governance has been defined. They are:

1. Enterprise Planning - all IT-related enterprise planning, from the development of business needs through to the pre-project definition of a business case. This includes gates 0-2.
2. IT Projects - once a project charter is defined and the projects starts there are a number of points in the development process where IT architects need to be involved. This scenario includes gates 3-6.
3. IT Evolution - the evolution of the IT within the enterprise needs to be managed, through a change management process. This scenario includes gate 7.

See: Roadmap: Governance.

Gate 0

A Business Need has been defined. It is now reviewed, updated as required, and approved. A Business Need describe a required change to the business; to business processes, services, or other aspects.

The IT architect can provide valuable input during the review of the need for the business change. Their intimate understanding of the technology and it architecture enable them to provide valuable advice regarding the issue, but also valuable input on possible solutions or opportunities. Many opportunities are available for IT technologies to not only support the business, but provide enhancements—to productivity and in many other areas. IT architects are in a position to provide valuable input when clarifying Business Needs.

Gate 1

A Business Opportunity has been defined. It is now reviewed, updated as required, and approved. The Business Opportunity is where the first notions of possible solutions to the Business Opportunity are documented.

Part of the solution may require changes to business processes or other aspects. But more Opportunities also require a technology component. This is where the IT architect provides advice on the possible solutions, and in the context of the current IT environment within the enterprise. Pros and cons are identified for each solution, and one is recommended. The architect may also identify opportunities for the application of new technologies, enhancing the business possibilities.

Gate 2

A Business Case has been defined. It is now reviewed, updated as required, and approved. A Business Case outline and describes a project to implement the Business Need/Opportunity. A BUsiness Case may also identify the need to update or change existing processes or systems.

The resources required in terms or time, people, and dollars, are included in a Business Case. Therefore, a solutions has been identified and agreed (from the BUsiness Opportunity) and these resource implications analyzed and itemized. IT architects are the obvious source for this type of analysis and solution documentation. Most Business Cases these days will involve IT implementations, and therefore an understanding of the solution architecture and implications on existing systems is needed to provide comprehensive advice. Business Cases need IT architect input at the very least, and perhaps they should author them.

Gate 3

A Project Charter or project requirement has been defined. It is now reviewed, updated as required, and approved.

The Project Charter is a statement of the scope, objectives, and participants of a project. It is a critical document to ensure that everyone involved in a project is aware of its purpose, objectives, and their role. It also includes specific on resources, both people and dollars. Therefore an IT architect that understands the proposed solution and how it fit into the enterprise provides crucial input for this review. The IT architect would also be able to clearly identify the stakeholders and other participants that need to be involved.

Gate 4

The IT architecture for a project has been defined, or is under development. This review ensures that the proposed design fits in with current systems and enterprise standards. The detailed design is reviewed, updated as required, and approved.

This is typically more of an on-going involvement by IT architects during the system detailed design. IT architects provide guidance and advice on the current IT architecture, and how the new/revised system fits into this wider context. Also, the detailed design choices are reviewed to ensure that they are compatible with enterprise standards (both technology and usage patterns) and that the solution is complete (i.e., all function and non-functions requirements are addressed). 

Gate 5

The system is being implemented. This review ensures that the resulting system fits in with current systems and standards. The implementation (design documentation) is reviewed, updated as required, and approved.

This is typically more of an on-going involvement by IT architects during the system implementation. A final review is too late to change or influence the implementation! Detailed design choices are reviewed to ensure that they are compatible with enterprise standards (both technology and usage patterns) and that the solution is complete (i.e., all function and non-functions requirements are addressed).  

Gate 6

The system has been designed and built. Now the system is transitioned to operations, which requires the review of all documentation on the system.

This review ensures that the documentation, including the IT architecture, accurately captures the as-built result. This review may require updates to the IT architecture or to ADs. IT architects ensure that the resulting system does indeed implement the approved architecture, and that it is compatible with current and future enterprise architectures and standards.

Gate 7

A change is needed to a system in operation. This review of a Change Request ensures that the requested change fits in with current systems and standards.

This review is equivalent to that for the Business Case. The Business Case sets the stage for an implementation project, as does the review of a Change Request. Once a Change Request is approved, the next step is to define and implementation project; to define a Project Charter, after which the normal project-related reviews kick-in. 

Gates in the Context of Inputs and Outputs

UAM processes define IT architectures, but these architectures cannot be done independently of the enterprise's short and long-term goals, standards, and strategies as defined in these documents. The following illustrates the main Work Products in UAM along with these external inputs. It also shows the approximate dependency relationships between them and the "gates" where they are reviewed and approved.

There are many more detailed Work Products defined (e.g., Business Process Model), but the above illustrates the important relationships. Note that the view is that the "Project Charter", which defines the general scope and objectives of an implementation project, is deemed to be external. This includes projects to define IT architectures, which managers of IT architects define.

In addition to this overview of UAM inputs and outputs, the following figure summarizes the important involvement of IT architects in defining system architectures. The various project management artifacts are listed, along with the "gates" or reviews of these artifacts. IT architects participate in these reviews.