Quality Management Activities For Enterprise Architecture: Author: Tanja Ylimäki Date: 4.5.2006 Status: Final

QUALITY MANAGEMENT
ACTIVITIES FOR
ENTERPRISE ARCHITECTURE
AISA Project Report
Version: 1.0 Date: 4.5.2006

Author: Tanja Ylimäki Status: Final
Summary
During the past few years enterprise architectures (EA) have gained much attention of
ICT people. EA is suggested to be the approach for controlling the complexity and
constant changes of the business environment of an organization, enabling a true
alignment between the business vision, business requirements and information
systems.
EA studies have mainly focused on the development and modeling of EA, whereas the
quality and assessment aspects of EA have only recently gained attention. AISA
project aims at scrutinizing the field of quality management of architectures (both at
the enterprise and software level).
This report describes the work done in the second phase of the AISA project. The aim
of the phase was to determine quality management (QM) activities needed in
enterprise architecting. They were derived from general quality management, EA
management and EA development literature and discussed and reviewed in a
workshop participated by the representatives of the co-operating organizations of the
research project.
Based on the literature review and the workshop results QM activities for EA are
suggested to be divided into activities related to 1) the EA governance process, and 2)
the EA development life cycle. QM activities within the EA governance process deal
with e.g. the definition of quality policy, quality objectives, EA mission, vision and
objectives, establishment of EA governance structure, definition of communication
and documentation policies, quality measurement planning, and quality control and
assurance, as well as definition of the actual EA development methodology. QM
activities within the EA development life cycle deal with e.g. definition of the EA
stakeholders and EA requirements, actual EA modeling (from different points of
view), migration planning, implementation (through system development or other
types of projects), quality control and assurance in different phases of the life cycle,
and using the EA as a guide and a mentor, or as a tool for ICT related decision
making.
These activities describe a “vision” or the big picture of what activities could and
should be included in the EA governance and development processes in order to
enable gaining an EA of high quality rather than offering a ready-made practice-
oriented package for quality management of EA to be put into action. Depending on
the organization’s needs and its EA capability and maturity, relevant or priority QM
activities can be determined. Finally, the following conclusions were drawn:
- There is a need to shift from investment decisions driven EA development to EA
governance driven development.
- There is a need to increase the maturity of the EA governance and EA
development processes. The set of QM activities presented in the report can be
regarded as the highest level of EA maturity; if all the appropriate activities are
planned and conducted, the organization should have a more mature EA.
- There is a need to develop metrics for controlling, assessing, and evaluating e.g.
quality, maturity and performance of EA.
Contents
1 INTRODUCTION .................................................................................................................................................... 1
2 QUALITY THINKING............................................................................................................................................ 2
2.1 QUALITY AND QUALITY MANAGEMENT .............................................................................................................. 2
2.2 MANAGING THE QUALITY OF ENTERPRISE ARCHITECTURE ................................................................................. 4
2.2.1 EA Maturity vs. EA Quality ........................................................................................................................ 4
2.2.2 Quality Management of EA......................................................................................................................... 5
3 QUALITY MANAGEMENT ACTIVITIES WITHIN THE EA GOVERNANCE PROCESS......................... 8
3.1 QUALITY POLICY AND QUALITY OBJECTIVES ..................................................................................................... 8
3.2 DEFINITION OF ARCHITECTURAL STARTING POINTS ........................................................................................... 8
3.3 ESTABLISHING THE EA GOVERNANCE STRUCTURE ........................................................................................... 10
3.4 DEFINITION OF COMMUNICATION, DOCUMENTATION AND REVIEW POLICIES ................................................... 10
3.5 DEFINITION OF RISK AND CHANGE MANAGEMENT STRATEGIES ....................................................................... 11
3.6 QUALITY MEASUREMENT PLANNING ................................................................................................................ 11
3.7 QUALITY CONTROL AND QUALITY ASSURANCE OF EA PROCESSES .................................................................. 12
3.8 RESOURCE MANAGEMENT ................................................................................................................................ 13
3.9 DEVELOPMENT OF EA METHODOLOGY ............................................................................................................. 14
4 QUALITY MANAGEMENT ACTIVITIES WITHIN THE EA DEVELOPMENT LIFE CYCLE .............. 15
4.1 QM ACTIVITIES FOR EA INITIALIZATION – SCOPE, STAKEHOLDERS AND REQUIREMENTS ................................ 15
4.2 QM ACTIVITIES FOR EA DEVELOPMENT ........................................................................................................... 16
4.2.1 EA Modeling ............................................................................................................................................. 16
4.2.2 Migration Planning .................................................................................................................................. 16
4.2.3 Quality Control and Quality Assurance ................................................................................................... 17
4.3 QM ACTIVITIES FOR EA REALIZATION ............................................................................................................. 17
4.3.1 Implementing the Plans ............................................................................................................................ 18
4.4 QM ACTIVITIES FOR EA USAGE ........................................................................................................................ 19
4.4.1 Continuous Tracking for Changes ............................................................................................................ 19
4.5 QM ACTIVITIES FOR EA IMPROVEMENT ........................................................................................................... 20
5 CONCLUSIONS..................................................................................................................................................... 21
REFERENCES ............................................................................................................................................................... 23
Information Technology Research Institute QM Activities for EA 1
AISA Project
Tanja Ylimäki 4.5.2006
1 Introduction
During the past few years enterprise architectures (EA) have gained much attention of
ICT people. EA is suggested to be the approach for controlling the complexity and
constant changes of the business environment of an organization, enabling a true
alignment between the business vision, business requirements and information
systems.
EA studies have mainly focused on the development and modeling of EA, whereas the
quality and assessment aspects of EA have only recently gained attention. AISA
project aims at scrutinizing the field of quality management of architectures (both at
the enterprise and software level).
This report presents the results of the second phase of the AISA project’s first year.
The phase aimed at determining the quality management (QM) activities for EA. The
phase consisted of the following steps:
1. Identification of the activities related to quality management.
2. Identification of the activities related to enterprise architecture governance.
3. Integrating the quality management activities into the enterprise architecture
governance.
4. Workshop/focus group interview of the representatives of the user and
service provider organizations (Krueger and Casey 2000) to review, discuss,
and validate the QM activities for EA.
5. Analysis, consolidation and reporting of the results of the workshop/focus
group interview and the literature review.
The QM activities for software architecture were studied with the help of a similar
process, and the results are reported in a separate document (Hämäläinen 2005).
The remainder of this report is organized as follows. In the next section, we represent
the basic ideas of quality management both in general and in the field of EAs. The
sections three and four describe the results of the literature review and workshop, and
the last section concludes the report.
AISA Project
2 Quality Thinking
In this section the main concepts for quality and quality management both in general
and in the field of EA are briefly described.
2.1 Quality and Quality Management

Quality (of a product, service, etc.) has, for example, the following characteristics
(Lecklin 2002; Dale 2003):
- conformance to agreed and fully understood requirements,
- fitness for purpose or use, and
- customer satisfaction: the product or service satisfies customer expectations and
understands their needs and future requirements in a cost-effective way.
Why we should care about quality? Dale (2003) presents various points why quality is
perceived to be important. Examples of these are as follows:
- quality is a primary buying argument for the ultimate customer
- quality is a major means of reducing costs
- quality is a major means for improving flexibility and responsiveness
- quality is a major means for reducing throughput time.
Juran (Juran and Godfrey 2000) introduces his “Trilogy of Quality Management”,
which defines that managing for quality makes extensive use of three managerial
processes: 1) quality planning, 2) quality control, and 3) quality improvement.
They are similar to the parallel processes long used to manage for finance:
- Financial planning which prepares the annual budget.
- Financial control which consists of evaluating actual financial performance.
- Financial improvement which aims to improve financial results; e.g. cost-
reduction projects, new facilities to improve productivity, new product
development to increase sales, acquisitions, or joint ventures.
Quality planning can be defined as a “structured process for developing products
(both goods and services) that ensures that customer needs are met by the final result.
The tools and methods of quality planning are incorporated along with the
technological tools for the particular product being developed and delivered” (Juran
and Godfrey 2000).
Quality planning has to deal with the quality gaps depicted in Figure 1 by providing
processes, methods, tools and techniques for closing each of the component gaps and
thereby ensuring that the final quality gap is at a minimum.
The quality control process is “a universal managerial process for conducting

operations so as to provide stability – to prevent adverse change and to maintain the
status quo” (Juran and Godfrey 2000). To maintain stability, the quality control
process evaluates actual performance, compares actual performance to goals, and
takes action on the difference. According Juran quality control’s relation to quality
assurance can be described as follows: “Each evaluates performance, each compares
AISA Project
performance to goals, each acts on the difference. However, quality control has as its
primary purpose to maintain control (or stability), performance is evaluated during
operations. Quality assurance’s main purpose is to verify that control is being
maintained, performance is evaluated after operations.”
Customer Expectations
Understanding gap
Understanding the needs
Design gap
Design of product
Quality
gap Process gap
Capability to deliver design
Operations gap
Actual delivery
Perception gap
Customer Perception of Delivery
Figure 1. The quality planning deals with the quality gaps (Juran and Godfrey 2000).
Quality improvement process is clarified with the definition of the term

improvement. It can be seen as an “organized creation of beneficial change; the
attainment of unprecedented levels of performance” (Juran and Godfrey 2000).
Furthermore, improvement usually takes place project by project and step by step.
Total Quality Management (TQM) is a “management philosophy embracing all

activities through which the needs and expectations of the customer and the
community, and the objectives of the organization are satisfied in the most efficient
and cost effective way by maximizing the potential of all employees in a continuing
drive for improvement” (Dale 1994), or “the vast collection of philosophies, concepts,
methods, and tools now being used throughout the world to manage quality” (Juran
and Godfrey 2000).
Dale (1994, 21) describes the TQM to evolve through four stages:
- Inspection: Activities such as measuring, examining, testing, gauging one or
more characteristics of a product or service and comparing these with specified
requirements to determine conformity.
- Quality control: The operational techniques and activities that are used to fulfill
requirements for quality.
- Quality assurance: All those planned and systematic actions necessary to
provide adequate confidence that a product or service will satisfy given
requirements for quality.
- Total quality management is the fourth and the highest level and it involves the
application of quality management principles to all aspects of the business,
including customers and suppliers.
Quality management is not a separate part of the organization, it is more or less
integrated into the management system of an organization to enable systematic
deployment of the management’s strategies and declarations of will throughout the
organization (Lecklin 2002). Quality management also includes and deals with the
organizational parts, responsibilities, procedures, processes and resources needed to
improve quality (Lillrank 1998).
AISA Project
2.2 Managing the Quality of Enterprise Architecture

In this section we will briefly discuss the quality management of enterprise
architecture. We start by revising the definitions for EA and the quality of EA.
An Enterprise Architecture, EA, is generally seen as a blueprint which identifies the

focal parts of the organization (such as people, business processes, technology,
information, financial and other resources) and its information systems, as well as the
means how these different parts collaborate to achieve the desired business objectives
(Hoogervorst 2004; Kaisler, Armour et al. 2005). An ideal EA provides a holistic,
enterprise-wide and consistent view of the organization instead of a looking at it from
the single application or system point of view (Kaisler, Armour et al. 2005; Lankhorst
2005).
During the previous step of the AISA project we defined the following preliminary
definition for the quality of EA (based on Lecklin 2002; Dale 2003): an Enterprise
Architecture has a good quality if it conforms to the agreed and fully understood
business requirements, fits for the purpose (which is to gain business value through
EA), and satisfies the various stakeholder groups’ (e.g. the top management, IT
management, architects, developers) expectations in a cost-effective way and
understands their current needs as well as their future requirements. Cost-
effectiveness is a multifaceted issue, though. It may refer, for example, to the
investment costs or the life cycle costs of information systems, depending on the
decision that is usually made by the top management.
The quality of EA is, however, more than merely the quality of the implemented EA
indicating that it is successfully used (e.g. EA conformant information systems are
being developed and used to support the business operations). It may also refer to the
quality of EA artifacts and documentation, the quality of the EA development process,
or the quality of EA governance (process).
Why we should strive for an EA of high quality? Generally, EA provides e.g. a means
of reducing information systems investment costs, life-cycle costs or throughput time,
or a means of eliminating redundancy of, for example, systems and information. It
also is an important means for improving flexibility and responsiveness of the
business providing tools to manage the complexity of the business, as well as the
complexity of the systems. More specifically, if the EA has also high quality these
benefits are more likely to be reached.
2.2.1 EA Maturity vs. EA Quality

In EA efforts – conducted both by the practitioners and the academia – different
(capability) maturity models and maturity assessments (GAO 2003; NASCIO 2003)
have gained more attention than “traditional” quality thinking, possibly because they
provide rather simple tools to assess the stage of the EA programs and to enhance its
maturity, and thus, quality. The maturity models also have their roots in the field of
quality management (Fraser, Moultrie et al. 2002). One of the earliest maturity models
is the Crosby’s Quality Management Maturity Grid (QMMG) which indicates that an
organization’s quality management evolves through five levels of maturity:
AISA Project
uncertainty, awakening, enlightenment, wisdom, and certainty (Fraser, Moultrie et al.
2002). The Capability Maturity Model (CMM) for software – and especially its
improved version, the Capability Maturity Model Integrated (CMMI) for systems and
software engineering (Chrissis, Konrad et al. 2003) – is one of the best known. The
software process maturity can be defined as “the extent to which a specific process is
explicitly defined, managed, measured, controlled, and effective” (Paulk, Curtis et al.
1993).
Maturity as a word means “ripeness” and it conveys the notion of development from
some initial state to some more advanced state (Fraser, Moultrie et al. 2002). It also
indicates that there may be several intermediate states on the way to the maturity.
Similarly, quality improvement evolves step by step. In this report, the maturity
models are considered as one means or approach of advancing the quality of EA,
while the EA quality management may encompass a wider range of activities. Quality
models also provide at least initial quality measurement systems for EA.
2.2.2 Quality Management of EA

Quality management of EA is about defining and conducting all those activities that
are needed to reach an EA of high quality and, thus, it relates to the same perspectives
than the quality of EA. There is a need to manage e.g. the quality of EA governance
process, EA development process, EA artifacts or specification, and the implemented
EA that is used.
How to piece together these different perspectives of EA quality management? We

started with a rough depiction of the relation between the different management
activities in an organization. EA as a holistic view to the enterprise co-operates with,
and to some extent integrates into, the different management activities, such as
business management, IT governance, systems development and quality management
(see Figure 2), that are all needed in order to run the business successfully.
Business
Management (e.g.strategy
management, strategy execution)
IT Governance,
Quality Enterprise IT delivery
Management Architecture & support
Systems
Development
(IT implementation)
Figure 2. EA co-operates with other management activities in an organization.
Another view is presented in Figure 3. The ultimate aim of the TQM is to integrate
quality management into the business management, the every day operations of the
enterprise. The degree of this integration is dependent e.g. on the line of business or
the size of the organization. In the manufacturing organizations there may be a
separate department or team responsible for the quality management whereas in the
information-centric businesses quality issues may be more integrated with the
business management. The EA governance also aims at being integrated into the
business management, as well as into the quality management to ensure reaching an
EA of high quality which is effectively utilized in an organization.
AISA Project
TQM Aspect: Business-Driven EA:

Integrating quality Integrating
management EA governance
into Business into business
business Management management
management
EA
Quality Governance/
Management Management
EA Quality Aspect:
Integrating (some) quality management (tasks)
into EA governance
Figure 3. The management triangle: integration is needed e.g. between the quality
management, enterprise architecture and business management.
Next, the relationship between the EA governance process and EA development

process needed to be clarified. EA governance (sometimes also called as EA
management or EA program management) can be defined as “the practice and
orientation by which enterprise architectures and other architectures are managed and
controlled at an enterprise-wide level” (The Open Group 2002). Architecture
governance also refers to “how an organization makes decisions, set priorities,
allocates resources, designates accountability, and manages its architectural
processes” (Baker and Janiszewski 2005). As depicted in Figure 4, EA governance is
seen as a continuous process controlling and guiding the actual EA development work
that is suggested to be conducted incrementally and iteratively in several development
cycles (see e.g. Perera 2005).
EA
EAGovernance/
Governance/EA
EA(Program)
(Program)Management
Management
Example of
development
Cycle; incremental
& iterative
EA development EA development EA development

Cycle 1 Cycle 2 Cycle 3
time
Figure 4. EA governance controls and guides the EA development cycles.
Because we did not want to restrict ourselves to any particular EA development

methodology, we identified the main generic EA development life cycle steps to
depict the EA development process. The generic EA development life cycle includes
the steps of initialization, development/planning, realization, using/maintaining, and
improving the EA (Grossman and Sargent 1999; CIO Council 2001; The Open Group
2002). Depending on the actual methodology used to develop an EA the precise
content (phases, activities, tasks and outputs) of these generic steps will vary. In
Figure 5 the generic steps within a single EA development life cycle are depicted
together with EA governance process that should initiate before the first EA
development cycle.
AISA Project
Within this context we suggest that the QM activities for EA are integrated into
1. the EA governance process, and
2. the EA development life cycle.
Quality management of the EA artifacts is included in the QM activities that are
integrated into the EA development life cycle. In the next sections we will discuss the
two levels of EA quality management in more detail.
(EA) Quality Management

EA Governance / EA (Program) Management
Generic EA Development Life Cycle:
Initialize Develop/Plan Realize Use/maintain Improve
Output Output Output Output Output
EA Specification
time
Figure 5. EA quality management is integrated into the EA governance process and

the EA development life cycle.
AISA Project
3 Quality Management Activities within the EA Governance Process

In this section we will describe the quality management activities that are integrated
into the EA governance process.
3.1 Quality Policy and Quality Objectives

Quality policy can be defined as the principles guiding the everyday business
functions derived from the values of the organization, indicating for example the
significance of the quality for the enterprise and how this can be seen in customer
relationships or in the actions of both the staff and the management (Lecklin 2002).
Quality objectives can be defined as the measurable goals for quality efforts (Lecklin
2002). For example, the share of the satisfied customer to be over 70 %, or the total
time spent on orders (from receiving an order to the delivery of goods or service) not
exceeding 7 days are strategic quality objectives (Lecklin 2002).
Quality management tasks related to the quality policy and quality objectives are as
follows:
- Define the quality policy (Lecklin 2002; Kartha 2004) for EA or follow the
existing quality policy of the organization and its guidelines.
- Define the measurable quality objectives (Lecklin 2002; Kartha 2004) for EA
based on e.g. the business objectives (Chrissis, Konrad et al. 2003) or strategic
quality objectives of an organization (Lecklin 2002). The quality objectives may
relate e.g. to
o the EA governance process,
o the EA development process and the actual method used,
o the EA specification consisting of the artifacts produced during the
development process, and
o the implemented EA, the EA conformant information systems
supporting the business operations that are used in the organization.
3.2 Definition of Architectural Starting Points

Architectural starting points are the essential issues that need to be considered,
communicated and agreed upon in the beginning of the EA journey. Quality
management activities related to the architectural starting points are as follows:
- Identify the key EA stakeholders (adapted from Juran and Godfrey 2000; Kartha
2004) to be able to involve them in the EA approach and development as early as
possible in order to reach their commitment (see e.g. IAC 2005). It should be
considered whether also their primary needs should be charted on a rough level at
this point.
- Define vision, mission, objectives, principles and scope for EA (Grossman and
Sargent 1999; The Open Group 2002; IAC 2005). EA objectives can be divided
into long, middle-long, and short term objectives (van der Raadt, Hoorn et al.
2005). An example of a short term goal is communicating the added value of
AISA Project
architecture to senior and middle management. Improving the quality and structure
of information systems and infrastructure is typically a long-term goal. It should be
noticed that when the short-term goals are emphasized, middle-long and long term
goals will be influenced negatively (van der Raadt, Hoorn et al. 2005).
Furthermore, the problem of prioritization has to be dealt with. As van der Raadt et
al. (2005) put it: “Clearly assigning priority to either the quality of architecture
products or the availability of resources, such as time and money, may prevent
many problems. Architects prioritize quality because they are responsible for the
quality of a design. Management, however, is more likely to prioritize the use of
resources because they are responsible for finishing projects within time and
budget. In practice this difference in responsibilities and prioritizing often results in
tension between the two groups. The choice of prioritizing quality has a negative
correlation with the use of time and money, and vice versa.”
It is also important to determine the intended use of the architecture, which can be
business process reengineering, systems acquisition, system-of-systems migration
or integration, user training, interoperability evaluation, or any other intent (CIO
Council 2001). In the AISA Workshop it was brought up that architecture may also
be the tool to reveal issues the organization is skating around, issues that are
ignored or unable to be discussed and solved. Hence, the purpose of the
architecture, as well as, vision, mission, scope etc. are closely tied to the
organization’s strategic plans, and they should be compliant with the business
vision, mission, strategies and objectives. Architecture principles can be defined as
the rules that govern the architecture process, affecting the development,
maintenance and use of the EA (The Open Group 2002). Additionally, in the AISA
Workshop it was pointed out that architecture visions describe the characteristics of
an ideal architecture. In practice, however, many constraints (time, money, skills
etc.) exist and the ideal architecture turns out to be “the realistic architecture”, the
best one developed with the restricted resources.
- Define the architecture approach or framework to provide a formal structure for

representing the EA (CIO Council 2001; The Open Group 2002; GAO 2003; IAC
2005). An organization may choose an existing EA framework, such as the
Zachman framework (Zachman 1987), TOGAF (The Open Group 2002), or FEAF
(FEAF 1999), and apply it as such or modify it to better fit to the organization’s
needs, or totally define an organization specific framework.
- Define architecture terms and concepts to form the common terminology and
language used in architectural discussion in the organization, or at least within the
architecture team (see e.g. Ylimäki and Halttunen 2005).
AISA Project
3.3 Establishing the EA Governance Structure

In order to be able to manage the EA development efficiently governance structures
need to be defined. Establishment of EA and its governance require a lot of co-
operation between the actual EA team (see Section 3.8 Resource Management), the
business management, and other key stakeholders (maybe even entire organization).
The quality management activities related to the establishment of the EA governance
structure are as follows:
- Establish and maintain the organizational policy for planning and performing the
EA governance process (adapted from Chrissis, Konrad et al. 2003). This activity
can be integrated into the definition of the architecture principles described above.
- Define and establish the EA governance structure (CIO Council 2001; The Open
Group 2002; Curran 2005; IAC 2005; van der Raadt, Hoorn et al. 2005) including
at least the processes, activities, tasks, roles, responsibilities, and authorizations
needed. Organizational structure may consist of e.g. a governance board, an
architecture board or a program management office.
In the next subsections we suggest some of the processes or activities that are needed
in successful EA governance.
3.4 Definition of Communication, Documentation and Review Policies

Quality management activities related to communication, documentation and review
issues are as follows:
- Define and establish the communication strategy
o Develop a marketing strategy and the communications plan in order to
keep the senior executives and business units continually informed and
to disseminate EA information to stakeholders (CIO Council 2001;
IAC 2005).
o Provide for feedback and discussion (The Open Group 2002; IAC
2005). Feedback channels from different stakeholder groups were seen
as an important part of the communication also in the AISA Workshop
discussion. They enable e.g. the architecture to take the technological
constraints into consideration as early as possible or the collection of
lessons learned about the effectiveness of both the EA governance and
development processes.
o Communicate, communicate, communicate in order to gain and
maintain top-management commitment and organizational buy-in.
- Define and establish the documentation policy
o Develop a documentation plan (Kartha 2004), which should include
e.g. what and how will be documented about the EA governance
process, and the EA specification.
o Ensure that the documentation policy is followed (e.g. through quality
control).
o Provide for reports of EA progress (The Open Group 2002; GAO
2003).
AISA Project
- Define and establish the review policy
o Define how the outcome of the EA governance and development
processes is reviewed, validated, or approved. Develop a review plan.
o Review, validate and approve the outcome of the EA governance and
development processes to determine EA product accuracy and
completeness in e.g. 1) internal reviews conducted by the EA core
team, 2) subject matter experts’ or the domain owners’ assessments of
the EA products for accuracy and completeness (CIO Council 2001;
GAO 2003). Notice that reviewing occurs at several points in the
development process.
3.5 Definition of Risk and Change Management Strategies

Quality management activities related to the risk and change management strategies
are as follows:
- Define the risk management strategies (OMB FEA Program Management Office
2005). In the AISA Workshop it was suggested that risk management is needed at
least at the level of how to deal with technological risks or the ever changing
business environment. The following steps may be utilized (Rajput 2004): 1)
Understand and define the risks (and e.g. the extent, likelihood, significance of
each risk), 2) assess risks, and 3) manage risks utilizing one or more of the possible
strategies, such as avoidance, monitoring, improved response, transferring
(reducing impact), or assumption (acceptance).
- Define the change management strategies (OMB FEA Program Management
Office 2005). This includes at least the following two levels:
o Plans to deal with the cultural change (Dale 2003).The adaptability of
an organization’s culture is an important determinant of business
success (Hermansen and Caron 2003). Typically, an organizational
culture has formed through shared group dynamics over years, and
these cultural patterns are difficult to change. It may even become a
constraint on business strategy (Hermansen and Caron 2003).
o Definition of the maintenance policy to enable governance of the
evolution of the EA (The Open Group 2002), i.e. definition of how to
deal with change requests related to e.g. the EA specification, or the
EA governance and development processes.
3.6 Quality Measurement Planning

Before any evaluation, assessment, or measurement can be conducted measurement
planning must be done or at least initialized (Juran and Godfrey 2000; Kartha 2004):
- Identify controls needed (Juran and Godfrey 2000):

o Define what are the things that will be measured e.g. about the EA
governance, the EA development process, the EA artifacts, the
implemented EA/the EA in use, or the customer satisfaction.
o Define why measurement is needed and conducted, where, how and by
whom will the measurement results be used.
o Define when measurement will be conducted (the milestones).
o Define how the measurement will be conducted and by whom.
AISA Project
o Define the metrics for e.g. the EA quality, EA maturity, and EA
objectives, such as business value added by the EA, EA program
maturity metrics, EA program impact metrics, EA usage, EA
completeness (IAC 2005). In the AISA Workshop it came up that
metrics for EA measurement are difficult to determine, because the
time frame for measurement is longer – years rather than months – than
in the system development projects. The effects of the EA program will
be seen, say, after five years. Within this time the business
environment may have totally changed (e.g. through mergers and
acquisitions), and it is very difficult to analyze the actual benefits or
defects of the EA efforts.
- Set standards for control (Juran and Godfrey 2000), set levels at which the
processes are out of control and define actions needed in such cases. This was seen
essential also in the AISA Workshop discussion. It is necessary for an organization
to determine the minimum acceptable level for EA processes and artifacts etc.
There is no need to reach an EA that is 100 % perfect, it just needs to be good
enough (see also Ambler 2005). It was also brought up that the minimum
acceptable level of e.g. EA processes may be different at different EA maturity
levels. A slogan of “just in time, just enough” was suggested to represent the
ability of doing things well enough indicating maturity, at least to some extent.
Furthermore, it came up in the AISA Workshop that the organization should
encourage the architecture team as well as other stakeholders to exceed this
minimum level, possibly through some kind of a rewarding system. On the other
hand, it is important to discuss what the risks of not even reaching the minimum
level of EA processes and artifacts are.
- Optimize self-control (Juran and Godfrey 2000), measure workers’ output, and
give feedback on their performance. In the AISA Workshop it was considered
important that EA should not dictate the system development team how to
implement the systems needed, but rather to guide and motivate the system
development team by providing them e.g. design patterns or piloted solutions that
ease their work, but do not harness their creativity.
Finally, the above issues of the measurement planning are documented into an (initial)
evaluation plan.
3.7 Quality Control and Quality Assurance of EA Processes

After the quality control and assurance is planned, the plans need to be put into action.
The following activities are needed in conducting quality control and assurance of EA
processes – both the EA governance process and the EA development process (the
method):
- Refine or update the evaluation plan (e.g. what, when, how, who, and metrics) if
needed.
- See that the quality policies and objectives are met by conducting the steps defined
the evaluation plan. The following general steps of quality control and assurance can
be exploited (adapted from Juran and Godfrey 2000; Chrissis, Konrad et al. 2003):
AISA Project
o Evaluate the performance of EA governance or EA development
processes, related artifacts, customer satisfaction (are the stakeholders’
requirements met etc.) using the defined metrics.
o Compare the performance with the (quality) goals or requirements
defined for EA governance, EA development processes, related artifacts,
or customer satisfaction.
o Take appropriate actions on the difference, e.g. adjust the processes, or
the artifacts (GAO 2003).
o Provide constructive feedback to facilitate continuous improvement
(Stylianou and Kumar 2000).
o Document the evaluation and the actions taken in an evaluation report.
3.8 Resource Management

Resource management deals with issues like assignment of personnel, training,
awareness and competency. Activities needed in resource management are as follows:
- Establish the initial EA team

o Assign the chief architect to take responsibility for leading the
development of the EA work products and support environment (CIO
Council 2001; GAO 2003). She/he will serve as the technology and
business leader for the development organization, ensuring the
integrity of the architectural development processes and the content of
the EA products. She/he should also be friend and liaison to the
business line units and ensure that business unit processes are
emphasized in the EA. Furthermore, the chief architect is responsible
for ensuring that the EA provides the best possible information and
guidance to IT projects and stakeholders, and that systems
development efforts are properly aligned with business unit
requirements. (CIO Council 2001)
o Architecture team should also include IT experts (such as systems,
data, infrastructure and security systems architects), business line
experts, and technologists (CIO Council 2001; GAO 2003).
Participants should have an understanding of the current business and
technical environment and the strategic business objectives envisioned
in the EA (CIO Council 2001).
o Assign responsibility and authority for the team (CIO Council 2001).
The EA core team is responsible for all activities involving the
development, implementation, maintenance, and management of the
architecture.
o Identify the thought-leader, which may be e.g. the CIO, or
organizational head, project manager, technical team lead, or the chief
architect on the project. “The thought leader is someone who is
respected throughout the organization for their leadership abilities, and
who becomes the “go-to” person for explanations or problems” (IAC
2005). Thought leader is the one to explain the vision and purpose of
EA to the stakeholders and even sell the concept.
- Assign, or at least try to estimate other resources (like funding/budget, schedule,
rooms, tools etc.) needed for the EA program or for a development cycle (IAC
AISA Project
2005). In the AISA Workshop scheduling issues were considered almost more
important than budgeting issues. It is necessary that the “right people have enough
time to do the right things”. On the other hand, EA budgeting was regarded as a
difficult task. It is easier to estimate the ICT expenses than the EA expenses,
because it is still somewhat unclear what EA is all about and which issues can be
regarded as “pure” EA issues. Usually, there is no historical evidence to rely on
while making the EA budgets. Therefore, they are mainly based on rough estimates
or good guesses.
- Train people performing or supporting the EA management and development
processes (adapted from Chrissis, Konrad et al. 2003): Discover their needs,
develop a training plan (including e.g. the content, audience, resources, staffing,
and curriculum design), deliver the training content to the audience and evaluate
the effects of training (Juran and Godfrey 2000).
3.9 Development of EA Methodology

A defined EA methodology will be needed to provide a common set of procedures for
developing an EA, and to help ensure consistency in the procedures used across the
organization for developing and maintaining the EA (GAO 2003). Some more or less
detailed EA development processes or methods exist (e.g. CIO Council 2001; Popkin
Software 2002; The Open Group 2002), but it is typical that organization specific
methods are defined and used. Activities needed in the EA method development are as
follows:
- Develop the process (Juran and Godfrey 2000): Define, document and establish the
EA development process; its phases, activities, inputs, and outputs (CIO Council
2001; GAO 2003). The method also needs to be documented, understood and
consistently applied by the EA team (GAO 2003). It should be noticed that the QM
activities within the EA development life cycle (presented in the next section) are
actually activities that need to be considered while defining or applying the EA
method. These activities should be integrated into appropriate steps of the method.
- Select appropriate modeling language(s), techniques (can be done as part of the EA
development process definition) to enable e.g. standardized EA output and
consistent EA views.
- Select appropriate (automated) tools to develop and manage EA (CIO Council
2001; GAO 2003; IAC 2005). The choice of tools is based on the organization’s
needs and the size and complexity of the architecture (see e.g. Rudawitz 2003).
- Provide appropriate training related to the EA methodology, modeling languages
and tools to ease the method adoption in the architecture team (for example as part
of resource management activity as described above).
AISA Project
4 Quality Management Activities within the EA Development Life

Cycle
In this section we describe the QM activities that are integrated into the EA
development life cycle. While we did not want to restrict ourselves to any particular
EA development method, we used the generic EA development life cycle steps to
depict the EA development process. When the actual EA development methodology
will be defined, the activities presented in this section, are integrated into appropriate
phases of the method.
4.1 QM Activities for EA Initialization – Scope, Stakeholders and

Requirements
In the EA initialization step the scope, stakeholders and EA requirements need to be
clarified. The following activities are needed:
- Define or refine the scope, mission, vision, objectives, and principles of EA
(Grossman and Sargent 1999; The Open Group 2002; IAC 2005).
- Define the depth of the EA. “Care should be taken to judge the appropriate level of
detail to be captured based on the intended use and scope of the EA and executive
decisions to be made using the EA. It is important that a consistent and equal level
of depth be completed in each view and perspective. […] It is equally important to
predict the future uses of the architecture so that, within resource limitations, the
architecture can be structured to accommodate future tailoring, extension, or reuse”
(CIO Council 2001). Importance of predicting the future changes was considered
essential also in the AISA Workshop. This is where the business management’s
perspectives may collide with the architecture team’s perspectives; business
management may want a low-cost “quick and dirty” solution for a particular
problem at hand, while the architecture team is trying to develop a long-range EA
plans to be able to respond to the future changes.
- Identify both the internal and external stakeholders for EA, as well as all relevant
standards, regulations, and policies that may affect the EA (adapted from Juran and
Godfrey 2000).
- Discover the stakeholders’ needs (adapted from Juran and Godfrey 2000):
o Plan to collect the business’ needs and other stakeholders’ needs.
o Collect architectural requirements, stakeholder needs, expectations, and
constraints. Some requirements can also be rather implicit; such
requirements are known, but seldom documented, and hence, easily
ignored. In the AISA Workshop a best-practice was suggested; an architect
goes through all the requirements gathered and marks those that are
architecturally significant. Definition of the architectural requirements is
very much based on the expertise of the architect or any other person
conducting the EA requirements gathering and analysis.
o Analyze and prioritize the needs, requirements, and constraints.
Requirements may be conflicting or ambiguous. In the AISA Workshop it
AISA Project
was pointed out that architecture can also be seen as a tool to discover and
reveal these inconsistencies.
o Translate the needs into EA requirements or into the language of the EA
team and finally, document the EA requirements. In the AISA Workshop it
was pointed out that the time frame of the (business) requirements can be
rather short. The architecture team should be mature enough to be able to
translate these short-term requirements into long-term architectural
requirements.
- Communicate in a continuous manner in order to gain and maintain the top-
management commitment and organizational buy-in. Take the characteristics of the
organization culture into account in a way the communication is conducted (e.g.
the language and communication means used).
4.2 QM Activities for EA Development

Activities needed in the EA development step of the life cycle relate to EA modeling,
migration planning, and quality control and assurance.
4.2.1 EA Modeling
EA modeling deals with the following activities:
- Model the current architecture (the as-is architecture) describing the current state of
an enterprise’s architecture (Armour, Kaisler et al. 1999b; CIO Council 2001;
GAO 2003). Model the perspectives defined in the architecture framework, e.g.
business architecture, information architecture, systems architecture and
technology architecture (see e.g. The Open Group 2002).
- Develop the future architectures (the to-be architecture) describing the future state
or the “to be built” state of the enterprise’s architecture within the context of the
strategic direction (Armour, Kaisler et al. 1999b; CIO Council 2001; GAO 2003).
- Ensure traceability between the as-is and the to-be state. “The process of tracing
differences between the current and the future states is maybe the most difficult
steps in the entire EA life-cycle process” (IAC 2005).
- Document the architectural decisions including justifications of the decisions
made.
While modeling the EA, all the defined documentation and communications policies
and strategies should be followed in order to enable reaching a consensus on the EA,
as well as an EA specification of high quality, or at least of acceptable quality.
4.2.2 Migration Planning

Migration or transition planning is about to develop “an incremental strategy for
transitioning the baseline to the target” (CIO Council 2001), to design how to get from
the current situation to the future situation (Armour and Kaisler 2001; CIO Council
2001; GAO 2003). The following activities are needed while planning the migration:
- Identify and define the steps or projects needed. Define scopes and mission
statements for each project and prioritize the projects (adapted from Juran and
AISA Project
Godfrey 2000). Document these definitions and decisions in a migration or
transition plan.
- Do architecture implementation planning (Armour and Kaisler 2001); map
resources (budgets, schedule, people etc.) to the choices made in the migration
planning.
4.2.3 Quality Control and Quality Assurance

Quality control and quality assurance within the EA development step may relate e.g.
to the
- the current EA measuring how aligned or misaligned it is with the organizational
goals,
- the EA artifacts or the EA specification measuring the conformance to the
documentation policy or standards, or
- the “customer” satisfaction measuring the extent to which the stakeholders’
requirements are met.
Issues to evaluate and assess depend on what is defined in the evaluation plan. The
tasks needed in quality control and assurance are as follows:
needed.
in the evaluation plan. The following general steps of quality control and assurance
may be exploited (adapted from Juran and Godfrey 2000; Chrissis, Konrad et al.
2003)
o Evaluate the performance of the current EA, the EA artifacts, the
customer satisfaction etc. using the defined metrics.
o Compare performance with the (quality) goals or requirements defined
for EA artifacts, customer satisfaction etc.
o Take action on the difference, e.g. modify the artifacts.
4.3 QM Activities for EA Realization

EA realization is about to implement the EA as defined in the migration plan. This is
usually conducted in several projects (that may or may not involve information
systems development), and hence, project management activities are needed. In the
AISA Workshop discussion it was underlined that in practice EA mainly focuses on
providing guidance and policies for the individual IT projects that implement the EA
conformant information systems.
AISA Project
4.3.1 Implementing the Plans

Activities needed in implementation are as follows:
- Implement the plans and validate transfer to operations (adapted from Juran and
Godfrey 2000):
o Follow the migration plan and take appropriate actions.
o Refine or update the migration plan if needed.
o Conduct (system) development project(s) to move closer to the to-be
architecture (CIO Council 2001).
o Ensure the compliance of an individual development project to the EA
(The Open Group 2002). This was highlighted also in the AISA
Workshop discussion. Furthermore, CIO Council (2001) suggests that
an enforcement policy may be defined to provide the standards and
process for determining the compliance of systems or projects with the
EA and procedures for resolving the issues of non-compliance. A
project’s technical and schedule compliance is typically assessed in
terms of how it conforms to the content, intent, and direction set by the
EA (CIO Council 2001).
- Provide support for the project team(s) (adapted from Juran and Godfrey 2000),
including e.g. the following tasks:
o Review the team progress,
o Identify and help any problems,
o Coordinate the related projects, and
o Communicate the project results to the appropriate stakeholders.

In the realization phase quality control and quality assurance is needed in order to
ensure that the implementation of the information systems supporting the business
operations is conformant to the EA. The following activities are similar to the quality
control and quality assurance activities for the EA development phase:
- Refine or update the evaluation plan if needed.
are suggested (adapted from Juran and Godfrey 2000; Chrissis, Konrad et al. 2003)
o Evaluate e.g. the customer satisfaction (are the stakeholders’
requirements met), or the conformance of the system development
project to the EA specification (The Open Group 2002). Conformance
was regarded as important issue also in the AISA Workshop
discussion.
for EA, customer satisfaction etc.
o Take action on the difference and steer the project to the right direction.
AISA Project
4.4 QM Activities for EA Usage
EA usage is about 1) using the EA specifications for the purposes it was designed in
the first place; to inform, guide, mentor and constrain the business decisions,
especially those related to IT investments (CIO Council 2001), as well as 2) utilizing
the EA conformant information systems to support the business operations.
4.4.1 Continuous Tracking for Changes

When part or the whole EA has been implemented and introduced within an
organization, it is still important to track for changes that may affect the architecture.
Activities related to tracking for changes are as follows:
- Refine or update the EA models and artifacts if required. These adjustments and
minor amendments do not indicate substantial changes to the EA.
- Continuously track for new business requirements (The Open Group 2002). The
change requests should be handled according to the maintenance policy.
- Continuously track for new stakeholder requirements (adapted from The Open
Group 2002). This kind of change requests should also be handled according to the
maintenance policy.
- Continuously track for new technology opportunities.
- Continuously track for new products or services provided by the vendors and
partners.

Assessment is needed in order to evaluate the effects the EA has on the organization
and the business success. The following activities are similar to the quality control and
quality assurance activities for both the EA development and realization phase:
needed.
are suggested (adapted from Juran and Godfrey 2000; Chrissis, Konrad et al. 2003)
o Evaluate e.g. the usage of the implemented EA; how widely or deeply
it is used in the organization, the business success (the value gained
through EA), or the customer satisfaction to ensure whether all the
stakeholders’ requirements are met.
for EA usage, business success, customer satisfaction etc.
o Take action on the difference e.g. through training and communication.
AISA Project
4.5 QM Activities for EA Improvement

From the quality management point of view the EA improvement phase aims at
providing plans for continual improvement (Chrissis, Konrad et al. 2003; Kartha
2004) to enable reaching the defined or new business objectives. Improvement may
focus on e.g. the EA governance process, the EA development process (the
methodology), EA artifacts, or EA usage. Activities suggested in this phase are as
follows:
- Plan for continual improvement, plan preventive or corrective actions.
- Evaluate the maturity or the quality of the current EA (program), for example,
o to clarify the current situation, what EA activities have been carried
out, what EA activities should still be considered,
o to find out if there is a need to modify or refine the migration plan,
o to assess the possible inefficiencies in the EA governance and
development processes, EA artifacts, or in the EA usage and utilization
(NASCIO 2003), and
o to assess the effects of change requests, such as the effects of new
business requirements, as well as the necessity of a change. Change
impact analysis applied to EA models can be used to see what would
happen if a change occurs, before the change really takes place (de
Boer, Bosanque et al. 2005).
- The EA (governance) team or the top management makes the decision to start a
new EA development cycle or iteration based e.g. on the evaluation results or new
(business) requirements.
- Update or refine the migration plan if needed.
- Plan a new EA development cycle or project taking the changed and new business
and other requirements into account ensuring the compliance of a single project to
the EA.
- Provide the appropriate resources through resource management activity.
- Deal with the cultural change (Dale 2003).
- Train people developing and using the EA (adapted from Juran and Godfrey 2000).
- Communicate, communicate, communicate to reach and maintain both top-
management support and commitment and the organizational buy-in.
As a conclusion, the improvement phase can be regarded as a kick-off for a new EA

development cycle.
AISA Project
5 Conclusions
In this report we presented a wide range of theoretical quality management activities
for enterprise architecture. They were derived from general quality management, EA
management and development literature and discussed and reviewed in a workshop
participated by the representatives of the co-operating organizations of the project.
EA quality management activities were integrated into the EA governance process

and into the generic phases of the EA development life cycle. This report aimed at
describing a “vision” or the big picture of what activities could or should be included
in the EA governance and development processes in order to enable gaining an EA of
high quality rather than offering a ready-made practice-oriented package for QM of
EA to be put into action. Depending, for example, on the organization’s needs,
resources, and maturity level, relevant or priority QM activities can be determined. On
the other hand this big picture of QM activities for EA represents the focal elements
of the AISA research project the way we see them at the moment, but it is likely that
the picture may change and clarify in the course of the research project as the
understanding of the problem area increases.
Even though the study is preliminary and the results should be generalized with care,
some conclusions can be drawn:
There is a need to shift from investment decisions driven EA development to EA

governance driven development. Quarter based economies impede the long-term
thinking that EA requires; it is sometimes difficult to justify the top management that
the investment that seems expensive at the moment will save money in the future.
Thus, it is typical that short-term investment decisions drive the EA development
efforts. While the companies have to deal with these limited resources, both in the
sense of time and money, there is the need to select the most important quality
management activities to start with. In the AISA Workshop the topic of EA
assessment and measurement was emphasized. It can provide one possible starting
point for EA quality improvement. Evaluation of the current state of the
organization’s architecture and its EA capability provides input for the definition of
the organization’s “declaration of will”, as well as to the definition of the top priority
QM activities the organization should start with.
Another point made in the AISA Workshop was the fact that extensive QM processes
can be developed which guide or even force to an ideal output and performance, but
which do not work in practice. Therefore, the QM processes need to be streamlined
and optimized to be as light as possible and easy to be adopted by an organization.
Only then the activities can be conducted effectively and the top management’s
acceptance and commitment as well as the organizational buy-in can be gained.
There is a need to increase the maturity of the EA governance and development

processes. One way to enable the shift from the investment decisions driving the EA
development efforts to more systemized and controlled EA approach is to determine,
deploy and improve the processes for EA governance and development, and, thus,
increase the maturity of EA, as well as the maturity of the organization, its EA
capability. The set of QM activities presented in this report can be regarded as the
AISA Project
highest level of EA maturity; if all these activities are carefully planned and
conducted, the organization should have a more mature EA.
In the previous phase of the AISA project the potential critical success factors (CSF)
for EA were studied (Ylimäki 2005). It can be noticed that the EA quality
management activities focus to the same issues than the CSFs for EA (Figure 6).
Hence, the QM activities presented in this report together with the CSFs for EA could
be integrated into an EA maturity model for business organizations.
Communication &
Commitment
Common Language
Scoping &
Purpose
Governance
Business Driven
Development EA Approach
Methodology Success &
Quality
Assessment/
Tool
Evaluation
Support
EA Model & Training/

Skilled Education
Artifacts Team
Organizational
Project
Culture
Management
Figure 6. Potential critical success factors for EA.
There is a need to develop metrics for controlling, assessing and evaluating e.g.
the quality, maturity and performance of EA. Development of appropriate metrics
and best practices for evaluation and assessment has to deal with the questions like
what the issues that will be measured and evaluated are, how the evaluation results are
used and by whom. In the AISA Workshop it was suggested that descriptive metrics
should be developed. The problem of descriptive metrics is that different
interpretations of the evaluation results may exist. Typically, also the business
management expects to have numeric metrics to base their decisions on. Therefore,
both metrics will be needed.
Furthermore, there is the problem of justifying the architecture’s benefits for an

organization. Issues to resolve are e.g. how to ensure that the business success, or the
decrease in ICT costs is reached because of the EA approach adopted, or how to
justify the need for EA approach to the business management in the first place. One
possible solution to the latter problem was presented in the AISA Workshop: a pre-
EA project can be set up with defined objectives, schedules, milestones, budget and
staffing. Such a project aims at introducing and selling the EA approach to the
organization, especially gaining the top management commitment, possibly
determining the current state of the organization’s architecture – explicit or implicit –
pointing out the most acute problems and defining initial objectives or the future state,
and, therefore, enabling easier rollout of the EA governance and development
processes.
These issues will be clarified in the following steps of the AISA Project starting with
the further description of the current state and the development needs of the
architecture quality management in the participating organizations.
AISA Project
References
Ambler, S. W. (2005). "Agile Enterprise Architecture." 18.8.2005, from

http://www.agiledata.org/essays/enterpriseArchitecture.html.
Armour, F. J. and S. H. Kaisler (2001). "Enterprise Architecture: Agile Transition and Implementation." IT
Professional(November-December): 30-37.
Armour, F. J., S. H. Kaisler, et al. (1999b). "Building an Enterprise Architecture Step by Step." IT Professional(July-
August): 31-39.
Baker, D. C. and M. Janiszewski. (2005). "7 Essential Elements of EA." Enterprise Architect Retrieved 17.6.2005,
from http://www.ftponline.com/ea/magazine/summer2005/features/dbaker/.
Chrissis, M. B., M. Konrad, et al. (2003). Cmmi: Guidelines for process integration and product improvement,
Addison-Wesley Professional.
CIO Council (2001). The Practical Guide to Federal Enterprise Architecture, version 1.0, Chief Information Officer
Council.
Curran, C. (2005). "Link IT Investments to Business Metrics." Enterprise Architect 3(1): 16-18.
Dale, B. G. (1994). Managing Quality, Blackwell Publishers.
Dale, B. G. (2003). Managing Quality, Blackwell Publishing.
de Boer, F. S., M. M. Bosanque, et al. (2005). Change Impact Analysis of Enterprise Architectures. Proceedings of the
IEEE International Conference on Information Reuse and Integration, IRI -2005, IEEE: 177-181.
FEAF (1999). Federal Enterprise Architecture Framework, Version 1.1., September 1999, The Chief Information
Officers Council (CIO). URL: http://www.cio.gov/documents/fedarch1.pdf.
Fraser, P., J. Moultrie, et al. (2002). The use of maturity models/grids as a tool in assessing product development
capability. IEEE International Engineering Management Conference. Cambridge, IEEE.
GAO. (2003). "A Framework for Assessing and Improving Enterprise Architecture Management, v. 1.1."
Grossman, I. M. and J. Sargent. (1999). "An IT Enterprise Architecture Process Model." Retrieved 17.10.2003.
Hermansen, E. and J.-P. Caron (2003). Organizational Agility: Kicking the Culture "Crutch". Engineering Management
Conference, IEMC '03. Managing Technologically Driven Organizations: The Human Side of Innovation and
Change, IEEE: 181-185.
Hoogervorst, J. (2004). "Enterprise Architecture: Enabling Integration, Agility and Change." International Journal of
Cooperative Information Systems 13(3): 213-233.
Hämäläinen, N. (2005). Quality Management Activities in Software Architecture Management (manuscript).
IAC. (2005). "Advancing Enterprise Architecture Maturity, version 2.0."
Juran, J. M. and A. B. Godfrey (2000). Juran's Quality Handbook, McGraw-Hill Companies.
Kaisler, S. H., F. Armour, et al. (2005). Enterprise Architecting: Critical Problems. Proceedings of the 38th Hawaii
International Conference on System Sciences, HICSS'05. Hawaii, IEEE Computer Society.
Kartha, C. P. (2004). "A Comparison of ISO 9000:2000 quality system standards, QS9000, ISO/TS 16949 and
Baldridge criteria." The TQM Magazine 16(5): 331-340.
Krueger, R. A. and M. A. Casey (2000). Focus Groups. A Practical Guide for Applied Research, Sage Publications, Inc.
Lankhorst, M. (2005). Enterprise Architecture at Work. Modelling, Communication, and Analysis, Springer-Verlag.
Lecklin, O. (2002). Laatu yrityksen menestystekijänä, Gummerus.
Lillrank, P. H. (1998). Laatuajattelu: laadun filosofia, tekniikka ja johtaminen tietoyhteiskunnassa. Helsinki, Otava.
NASCIO. (2003). "NASCIO Enterprise Architecture Maturity Model, v. 1.3." 2004, from
https://www.nascio.org/publications/index.cfm.
OMB FEA Program Management Office (2005). OMB Enterprise Architecture Assessment Framework Version 1.5,
OMB FEA Program Management Office, The Executive Office of the President, USA.
Paulk, M. C., B. Curtis, et al. (1993). Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-024-ESC-
TR-93-177, SEI.
Perera, D. (2005). "The good and the bad of enterprise architecture." Federal Computer Week Retrieved 12.12.2005,
from http://www.fcw.com.
Popkin Software. (2002). "Building an Enterprise Architecture: The Popkin Process, Version 1.0, Whitepaper."
Rajput, V. (2004). "Strategies for Operational Risk Management." Enterprise Architect(Fall 2004): 6-11.
Rudawitz, D. (2003). "Selecting an Enterprise Architecture Tool - A primer for how and why."
Stylianou, A. C. and R. L. Kumar (2000). "An Integrative Framework for IS Quality Management." Communication of
the ACM 43(9): 99-104.
The Open Group. (2002, the edition 8.1 has been published in December 2003). "TOGAF 8, The Open Group
Architecture Framework "Enterprise Edition"." from http://www.opengroup.org/architecture/togaf/.
AISA Project
van der Raadt, B., J. Hoorn, F., et al. (2005). Alignment and Maturity are Siblings in Architecture Assessment.
Proceedings of the 17th Conference on Advanced Information Systems Engineering, CAiSE 2005. Porto,
Portugal, Springer.
Ylimäki, T. (2005). Towards Critical Success Factors for Enterprise Architecture, 4.10.2005. AISA Project report,
Information Technology Institute, University of Jyväskylä.
Ylimäki, T. and V. Halttunen (2005). Perceptions on Architecture Management and the Skills of an Architect.
Proceedings of the IBIMA 2005 Conference on Information Management in Modern Enterprise. Lisbon,
Portugal.
Zachman, J. A. (1987). "A Framework for Information Systems Architecture." IBM Systems Journal 26(3): 276-292.

Quality Management Activities For Enterprise Architecture: Author: Tanja Ylimäki Date: 4.5.2006 Status: Final

Uploaded by

Copyright:

Available Formats

Quality Management Activities For Enterprise Architecture: Author: Tanja Ylimäki Date: 4.5.2006 Status: Final

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Quality Management Activities For Enterprise Architecture: Author: Tanja Ylimäki Date: 4.5.2006 Status: Final

Uploaded by

Copyright:

Available Formats

QUALITY MANAGEMENT

AISA Project Report

Version: 1.0 Date: 4.5.2006

2.1 Quality and Quality Management

The quality control process is “a universal managerial process for conducting

Customer Perception of Delivery

Quality improvement process is clarified with the definition of the term

Total Quality Management (TQM) is a “management philosophy embracing all

2.2 Managing the Quality of Enterprise Architecture

An Enterprise Architecture, EA, is generally seen as a blueprint which identifies the

2.2.1 EA Maturity vs. EA Quality

2.2.2 Quality Management of EA

How to piece together these different perspectives of EA quality management? We

Figure 2. EA co-operates with other management activities in an organization.

TQM Aspect: Business-Driven EA:

Next, the relationship between the EA governance process and EA development

EA development EA development EA development

Figure 4. EA governance controls and guides the EA development cycles.

Because we did not want to restrict ourselves to any particular EA development

(EA) Quality Management

Generic EA Development Life Cycle:

Initialize Develop/Plan Realize Use/maintain Improve

Output Output Output Output Output

Figure 5. EA quality management is integrated into the EA governance process and

3 Quality Management Activities within the EA Governance Process

3.1 Quality Policy and Quality Objectives

3.2 Definition of Architectural Starting Points

- Define the architecture approach or framework to provide a formal structure for

3.3 Establishing the EA Governance Structure

3.4 Definition of Communication, Documentation and Review Policies

3.5 Definition of Risk and Change Management Strategies

3.6 Quality Measurement Planning

- Identify controls needed (Juran and Godfrey 2000):

3.7 Quality Control and Quality Assurance of EA Processes

3.8 Resource Management

- Establish the initial EA team

3.9 Development of EA Methodology

4 Quality Management Activities within the EA Development Life

4.1 QM Activities for EA Initialization – Scope, Stakeholders and

4.2 QM Activities for EA Development

4.2.2 Migration Planning

4.2.3 Quality Control and Quality Assurance

4.3 QM Activities for EA Realization

4.3.1 Implementing the Plans

4.3.2 Quality Control and Quality Assurance

4.4.1 Continuous Tracking for Changes

4.4.2 Quality Control and Quality Assurance

4.5 QM Activities for EA Improvement

As a conclusion, the improvement phase can be regarded as a kick-off for a new EA

EA quality management activities were integrated into the EA governance process

There is a need to shift from investment decisions driven EA development to EA

There is a need to increase the maturity of the EA governance and development

EA Model & Training/

Figure 6. Potential critical success factors for EA.

Furthermore, there is the problem of justifying the architecture’s benefits for an

Ambler, S. W. (2005). "Agile Enterprise Architecture." 18.8.2005, from

You might also like