This is next lecture of Enterprise Architecture course.

Today, we're going to study how

TOGAF actually evolves enterprise architecture and which method it uses. The lecture is
dedicated to Architecture Development Method or ADM. This is a complex approach to
company development. An initial definition of ADM by TOGAF is a method for
development and IT architecture that meets the business needs of an organization.
Actually, this is much more. ADM can be utilized for different types of projects but can
be tailored to different organizational needs. The ultimate goal of this method is to
provide a framework for blending different organizational activities. It consists of eight
stages and continuous process of requirements management and it is iterative in nature.
This means that company development is dynamic and can be organized through a
variety of iterations. This is the structure of ADM. It is designed as a circle with
requirements management in a center. To move in the circle, we have to define
preliminary of enterprise architecture. After that, we can start the development circle and
go through it as many times as we need throughout the whole life cycle of the company.
Requirements management here indicates importance of continuous monitoring, that
changes are still desirable, and discover needs of different stakeholders. Now, we can
consider all the phases in more details based in TOGAF standard. ADM preliminary
phase is about defining how we do architecture in the enterprise concept. There are two
main aspects; defining the framework to be used and defining the architecture principles
that will inform any architectural work. At this phase, we mainly have to define the
architectural footprint for their organization, the people responsible for performing
architectural work, where they are located and their responsibilities. We also need to set
up and monitor a process of architectural design and development and other
organizational aspects. Phase A is called architectural vision. It starts with receipt of
request for architectural work from sponsoring organization onto the architecture
organization. On this stage, we mainly need to validate the business principals, business
goals, and strategic business drivers. The stage includes definition of the key business
requirements and what is more, analysis of impact. Analysis of potential impact on other
processes and ongoing projects and is one of the key tasks of this phase. Phase B is called
business architecture. A knowledge of the business architecture is a prerequisite for
architectural work in any other domain, data applications technology. In practical terms,
the business architecture is also often necessary as a means of demonstrating the business
value of subsequent technical architectural work to key stakeholders. A variety of
modeling tools and techniques may be employed including activity models, use case
models, and others. In terms of outcomes, we need to remember that the following set of
artifacts needs to be described; baseline and target architecture and gap analysis. Phase C
is called information systems architecture and consists of two sub phases which are; data
architecture and application architecture. Data architecture step is dedicated to definition
of major types and sources of data necessary to support the business. They have to be
understandable by stakeholders, complete, and stable. This step is not concerned with
database design. The goal is to define the data entities relevant to the enterprise, not to
design logical or physical storage systems. We can use here models of entities, attributes
and relationships. As with any type of architecture, we have to create baseline
architecture model, target, and perform gap analysis through a set of steps. Applications
architecture step is designed to define the major kinds of application system necessary to
protect the Data and support the business. Again, it is not concerned with applications
design system. The goal is to define what kinds of application systems are relevant to the
enterprise and what these applications need to do in order to manage data and to present
information to the human and computer actors in the enterprise. The applications are not
described as computer systems, but as logical groups of capabilities that manage the data
objects. This step also includes a revision of qualitative criteria of applications such as
security, availability, performance, and costs. In terms of outcomes, we need to
remember that the following set of artifacts need to be described; baseline and target
architecture and gap analysis. Phase D is called technology architecture. An organization
creating or adapting a technology architecture may already mandate the use of the list of
approved supplier’s products for their organizations. The list will be an input to the
definition of the organization specific architecture framework. The architecture can then
be used as procurement tool to govern the future growth and development of their
organization's IT infrastructure. This phase includes a revision of baseline architecture,
baseline data architecture, and baseline application architecture to develop target
technology architecture. Phase E is called opportunities and solutions. Phase E identifies
the parameters of change, the measure phases along the way, and the top-level projects to
be undertaken in moving from current environment to the target. The output of Phase E
will form the basis for implementation plan required to move to the target architecture.
This phase attempts to identify new business opportunities arising from the architectural
work in previous phases. The output of this phase are implementation and migration
strategy, high-level implementation plan, and impacts analysis. Phase F is called
migration planning. The objective of phase F is to solve the various implementation
projects into priority order. Activities includes accessing the dependencies costs and
benefits of the various migration projects. The prioritized list of projects will go to form
the basis of the detailed implementation plan and migration plan. Issues requiring special
consideration may include; parallel operations, choices of proceeding with phased
migration by subsystem or by functions, the impact of geographical separation and
migration, and others. Most organizations find that the change of architecture has too
much impact on the organization to be undertaken in a single phase. Migration often
requires consideration of a number of technical issues, not the least which are those
associated with the means of introducing change to operational systems. Phase G is
called implementation governance. It is here that all the information for successful
management of the various implementation projects is brought together. Note that in
parallel with phase H, there is the execution of organizational specific development
process, where the actual development happens. Phase G establishes the connection
between architecture and implementation organization. Here we design and monitor the
following project characteristics; name, description, objectives, scope, deliverables,
constraints, measures of effectiveness, acceptance criteria risks, and issues. Phase H is
called architecture change management. The goal of an architecture change management
process is to ensure that changes to the architecture are made in a cohesive and
architectured way. ADM is a powerful tool itself and can be applied to manage company
developments. But with linkage to ArchiMate, it becomes possible to support it with
visual representation. By visual representations, we mean here, a set of comprehensive
models for each design task. For preliminary phase and architectural description of
architecture vision on ArchiMates provides motivation layer with classic indicate color.
ArchiMate has its specific elements for designing models for phases B, C, and D and
even provides a set of objects to create implementation and migration models. With the
use of ArchiMate, it is possible to visualize strategy on initial stages, create baseline and
target architectures, and model interrelated sets of projects and work packages. Another
important aspect of ADM is tailoring. As we already mentioned in the beginning of our
lecture, Architecture Development Method is not always about IT implementation. It can
be adapted for example to re-organizational projects, meaning changing organizational
structure of the company and its processes. In addition, structure of the phases and its
number is linked to company maturity. Not all the companies may create architecture
vision, for example, provide governance. Some companies might require ADM to be
integrated with any other framework used within the company, for example, Zachman
Framework. Recall, we already mentioned architecture governance but like we'd to
emphasize that ADM is any methods which is aiming to become a corporate standard,
have to be monitored by top management. Managers have to check that it is strictly
applied along all the phases and all artifacts are designed correctly.