The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an "enter prise-specific" ADM. From time to time even Enterprise Architects need to develop architectures. Those can have such different scopes as :
- An architecture for a single system that consumes an effort of maybe only a few person years
- Clusters of systems that support a single business process, spanning maybe 5-7 IT systems. Such projects may consume 10 to 50 person years.
- Architecture for the application landscape of a whole company. This will never be implemented in a single project a may take almost a decade to complete.
- Template Architectures and architectures for application frameworks that serve as the template for a family of applications, like e.g. all customer facing web applications of an enterprise.
Figure tg.03 Architecture Development Cycle
TOGAF proposes a cyclic process for architecture development (see Figure tg.03). What you have to do here is quite straight forward for any software architecture professional. Phases within the ADM are as follows:
- The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for a new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles. When using an iterative process for architecture development, the activities within the Preliminary phase may be revisited a number of times, alongside related activities within the Architecture Vision phase, in order to ensure that the tailored framework is suitable to address a specific architecture problem.
- Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes infor mation about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals. Normally, the business principles, business goals, and strategic drivers of the organization are already defined else where in the enterprise. If so, the activity in Phase A is involved with ensur ing that existing definitions are current, and clarifying any areas of ambiguity. Otherwise, it involves defining these essential items for the first time.
- Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision. A knowledge of the Business Architecture is a prerequisite for architecture wor k in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).
- Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.Information Systems Architecture focuses on identifying and defining the applications and data considerations that support an enterprise’s Business Architecture; for example, by defining views that relate to infor mation, knowledge, application services, etc.
- Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project. Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios.
- Phase E: Opportunities and Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Phase E concentrates on how to deliver the architecture. It takes both a corporate business and technical perspective to rationalize the IT activities, and logically group them into project work packages within the IT portfolio and also within any other portfolios that are dependent upon IT. This is a collaborative effort with key enter prise stakeholders from business and IT (those who develop and implement/run the infrastr ucture) to assess the organization’s business transfor mation readiness, identify opportunities and solutions, and identify all implementation constraints. Focus on business value, flexibility, co-ordination, and compromise will be keys to success.
- Phase F: Migration Planning addresses the for mulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan. The Implementation and Migration Plan is part of a family of plans issued by enterprise management frameworks that have to be closely co-ordinated to ensure that business value is delivered and that the resources are made available to complete the necessary work. This phase ensures that all concerned agencies outside of the enterpr ise architecture world are aware of the scope and import of the Implementation and Migration Plan and its implications with respect to their activities.
- Phase G: Implementation Governance provides an architectural oversight of the implementation. To enable early realization of business value and benefits, and to minimize the risk in the transfor mation and migration program, the favored approach is to deploy the Target Architecture as a series of transitions. Each transition represents an incremental step towards the target, and each delivers business benefit in its own right.
- Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. When changes are identified, change management will determine whether to for mally initiate a new architecture evolution cycle.
- Requirements Management, as indicated by the "Requirements Management" circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process. It is important to note that the Requirements Management circle denotes, not a static set of requirements, but a dynamic process whereby requirements for enterpr ise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases.