Architectural Governance Page 1

K NOWLEDGE
M ANAGEMENT

A RCHITECTURAL G OVERNANCE
G OVERNANCE , P LAN , M ETHODOLOGY ,
R EQUIREMENTS & D ESIGN

Status: Pubic Release (site neutral)

July 2008
Version 1.0

Prepared by:
Architecture Team:
Steven D. Wright

© 2008 Knowledge Management. All Rights Reserved. PAGE 1

 Architectural Governance Page 2

Report Control Sheet

1. Project Digital Publishing Project

2. Report Type Strawman Proposal; if approved: IT Policy
3. Version Version 0.1
4. Date of Publication April 12, 2004
5. Authors Steve Wright
6. Approvers
7. Additional Reviewers
8. Draft Distribution Digital Publishing Development Team
9. Final Distribution Public
10. Last Modified 7/3/2008 11:22:00 PM
11. Internal Revision 4
12. Document Location C:\Documents and Settings\Steve\My Documents\My
Templates\Architectural Governance.docx

AMENDMENT HISTORY
Version Status Date Comments
0.1 Draft 4/12/04 Internal documents

0.5 Release various Adapted and released as guidance to several

companies under contract.
1.0 Release 6/3/08 Blended two

© Copyright 2008 Steven D. Wright d.b.a. Knowledge Management. All rights

reserved. No part of this publication may be reproduced, stored in a retrieval system or
transmitted in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior written permission of Steven Wright.

© 2008 Knowledge Management. All Rights Reserved. PAGE 2

 Architectural Governance Page 3

Table of Contents
REPORT CONTROL SHEET .................................................................................................................... 2
TABLE OF CONTENTS ............................................................................................................................. 3
EXECUTIVE OVERVIEW ......................................................................................................................... 4
WHAT IS ARCHITECTURE? ................................................................................................................... 5
THE ARCHITECTURE TEAM ................................................................................................................. 6
RESPONSIBILITIES OF THE ENTERPRISE ARCHITECTURE TEAM ................................................................... 6
ARCHITECTURAL ROLES ............................................................................................................................. 7
RESPONSIBILITIES OF EACH ARCHITECT ..................................................................................................... 8
Chief Architect ...................................................................................................................................... 8
Applications Architect ........................................................................................................................... 8
Data Architect ....................................................................................................................................... 8
Information Architect ............................................................................................................................ 9
Internet Architect .................................................................................................................................. 9
Network Architect ................................................................................................................................10
System Architect ...................................................................................................................................10
Security Architect .................................................................................................................................10
Process/Methodology Architect ...........................................................................................................11
Project Architects (PA) ........................................................................................................................11
ARCHITECTURAL STANCE ..................................................................................................................13
ARCHITECTURE DEVELOPMENT PROCESS .................................................................................................13
ARCHITECTURAL FOUNDATIONS ...............................................................................................................14
APPLICATION STACK .................................................................................................................................14
ARCHITECTURAL LAYERS .........................................................................................................................16
Ubiquitous Services .............................................................................................................................17
NON-FUNCTIONAL QUALITY REQUIREMENTS .............................................................................18
Business Qualities ................................................................................................................................18
User Qualities ......................................................................................................................................19
Administrator Qualities .......................................................................................................................19
Qualities of Service ..............................................................................................................................21
Software Life-Cycle Qualities ..............................................................................................................22

© 2008 Knowledge Management. All Rights Reserved. PAGE 3

 Architectural Governance Page 4

Executive Overview
The governance of enterprise architecture is based on an understanding of
the strength and integrity intrinsic in the people and technologies used in
the business while also understanding the weakness and opportunities for
miscommunication that is extrinsic between these same people and
technologies when applied to business goals.
In each of the sections that follow we will answer:
 What is an Enterprise Architecture?
 What are the various roles of an Architecture Team?
 How is an Enterprise Architecture developed and communicated,
including selection of technologies, standards and design patterns?
 What are the many competing “system qualities” that must be
balanced preliminary to any determination of an architecture?

© 2008 Knowledge Management. All Rights Reserved. PAGE 4

 Architectural Governance Page 5

What is Architecture?
ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural
Description of Software-Intensive Systems, provides the following
definition for architecture:
Architecture is defined by the recommended practice as the
fundamental organization of a system, embodied in its components,
their relationships to each other and the environment, and the
principles governing its design and evolution. This definition is
intended to encompass a variety of uses of the term architecture by
recognizing their underlying common elements. Principal among
these is the need to understand and control those elements of system
design that capture the system’s utility, cost, and risk. In some cases,
these elements are the physical components of the system and their
relationships. In other cases, these elements are not physical, but
instead, logical components. In still other cases, these elements are
enduring principles or patterns that create enduring organizational
structures. The definition is intended to encompass these distinct, but
related uses, while encouraging more rigorous definition of what
constitutes the fundamental organization of a system within
particular domains.
Here is my definition for Enterprise Architecture:
Enterprise Architecture is the set of decisions that must be made at
the enterprise level before specific applications are designed and
built in order to provide conceptual integrity and sanity across the
enterprise’s systems. Architecture includes a decomposition of the
systems into separate orthogonal viewpoints along with the enforced
rules that enable this clean decomposition and isolation of design
viewpoints. This is done so functional (application requirements)
and non-functional (system qualities) and other aspects of the
application system may be defined and built by independent
specialists in their specific field. An architecture not only divides
the system, it also divides the roles and responsibilities of those who
work with the system into separate organizational concerns and
disciplines that are conceptually tractable and can be effectively
managed.
An architecture must also incorporate trade-offs aware that attempts
to optimized every desired feature is not possible and can result in
systems that do not function effectively.

© 2008 Knowledge Management. All Rights Reserved. PAGE 5

 Architectural Governance Page 6

The Architecture Team

Architects are divided into Enterprise Architects and Project Architects
(PA).
Enterprise Architects are focused at the IT enterprise level and
connectivity between multiple applications. Enterprise Architects are
geared to be more proactive, less reactive; more strategic, less tactical.
Enterprise Architects provide guidance to the Project Architects who
apply enterprise standards and guidelines at the project level.
Project Architects are focused at the project level and working with the
developing vendor to design and implement the project. PAs report to
Project Managers, but have a dotted-line responsibility to the Enterprise
Architects in order to maintain consistency and interoperability across
systems.

Responsibilities of the Enterprise Architecture Team

 Responsible for translating business requirements into systems
qualities and thence into repeatable design strategies and patterns
that enable those qualities (e.g. adaptability, scalability,
availability, non-repudiation, reusability, etc.).
 Responsible for enterprise application integration (EAI). This
includes defining the opportunities for integration, selecting the
tools, specifying the shared data & code resources, defining the
interfaces and data-flows, and monitoring the success of said
integration.
 Compiles or designs architectural models of current and proposed
systems across the enterprise for use internally and in conjunction
with Technology Partners. The models are of two types:
o Enterprise Models that depict the entire enterprise and its
inter-relationships.
o Reference Models that depict recommended & approved
technologies & designs, which can serve as a template for
future projects.
These models cover the following viewpoints:
o API Stack of blessed Open Standards and Proprietary
Technologies (expanded OSI 7-Layer Model)
o Application Map
o Data Flow Diagram
o Business Process Models (from the Business Process
Group)
o Logical & Physical Data Schema

© 2008 Knowledge Management. All Rights Reserved. PAGE 6

 Architectural Governance Page 7

o Hardware Infrastructure Diagram

o Network LAN & VLAN Infrastructure Diagram
o Also, where needed to clarify application requirements,
Unified Modeling Language (UML) diagrams, viz.: Use
Case, Class, Package, Object, Sequence, Collaboration,
State-chart, Activity, Component and Deployment
Diagrams.
 Establishes the Design Repository and Metadata Repository for
integrating all aspects of these models, and provides oversight of
its use in conjunction with integrated Tool sets.
 Perform design reviews across the organization. (Note: not code
reviews.)
 Leads the evaluation of vendor software targeted for possible
integration into the systems or environment, including strategic
applications, tools, and utilities.
 Defines the IT design methodology, development process
methodology and best practices.
 Surveys external emerging developments, and evangelizes new
technologies, standards and methodologies that will have a positive
impact on the company's bottom-line and quality of service.
 Participates in external standards body work that defines IT
standards in the health community.

Architectural Roles
The Architecture team is divided into a number of roles based on an
orthogonal “separation of concerns”:
 Chief Architect
 Applications Architect
 Data Architect
 Information Architect
 Internet Architect
 Network Architect
 Systems Architect
 Security Architect
 Process Architect
 Project Architects (PA)

All but the last role comprise the Enterprise Architects. Each role (with
the exception of the PA) is focused on issues at the enterprise level and
across all projects. Due to the shortage of resources many architects hold
more than one of the positions described below. In some cases there

© 2008 Knowledge Management. All Rights Reserved. PAGE 7

 Architectural Governance Page 8

already exists a central department within the company that has an

enterprise focus on one of these roles. In this case the Enterprise Architect
may reside in this team and be matrixed into the Architecture team. By
this means all architectural work is coordinated across all dimensions and
projects.

Responsibilities of Each Architect

Chief Architect
 Coordinates and facilitates the activity of the Enterprise Architects
and Project Architects with existing projects; removing road-
blocks where necessary.
 Takes proactive escalation of probable system problems or design
flaws to upper management before serious impact on ROI.
 Assures the complementary synthesis of all standards, models,
designs and methodologies recommended by the Enterprise
Architects.
 Acts as evangelist of the work and recommendations of the
architecture team.
Applications Architect
 Selects the paradigm and technology for application program-to-
program communication (APPC) among the components.
 Determines the overall priority ranking of each of the possible
system qualities (cost, reusability, robustness, etc.) so the other
architects can design models that enforce the “balance of
concerns”.
 Responsible for defining the application tiers, frameworks,
components types and interfaces. Also, creates the first-draft
graphical template of UML design models used by the Project
Architects.
 Specifies and provides ownership of reusable application
components or reusable application code.
Data Architect
 Sets Data Policy and the technical solution for the management,
storage, access, navigation, movement, and transformation of data.
 Specifies recommended DBMS and ETL tools and technologies
for structured and unstructured content.
 Creates and maintains the Metadata Repository.
 Creates a semantically rich business model of the enterprise
problem domain that:
o Is independent of any technology solution
o Defines the Content of the business

© 2008 Knowledge Management. All Rights Reserved. PAGE 8

 Architectural Governance Page 9

 Compiles and maintains the Enterprise Schema across all

applications.
 Enforces principles of good canonical data design.
 Examines and enforces opportunities to provide data reuse,
balancing the issues of centralization and replication.
 Ensures the preservation of strategic data assets as applications and
technologies de jure come and go.
 Reviews the policies and work of the Data Base Administrators.
Information Architect
Because there already exists a central Web Hosting team the Information
Architect may reside in this team and be matrixed into the Architecture
team.
Richard Saul Wurman, the father of information architecture, describes the
role in these words: “The individual who organizes the patterns inherent
in data, making the complex clear.” “A person who creates the structure
or map of information which allows others to find their personal paths to
knowledge.” “The emerging 21st century professional occupation
addressing the needs of the age focused upon clarity, human
understanding, and the science of the organization of information”
 Defines the visual roadmap seen by the customers of the company
with emphasis on making it easy for customers to find the needed
data to make appropriate decisions regarding their medical care
and management.
 Establishes branding policy and holds the UI templates.
 Establishes the personalization policy with a goal to building
customer loyalty and relationship enrichment.
 Defines the recommended dialog flow for long-running
transactions and “speech acts” in coordination with the Business
Process Group.
Internet Architect
 Monitors the emerging standards for B2B & B2C internet
interaction and sets the standards and technologies to be used by
the enterprise. These include the existing HTML, applet & XML
standards, and the emerging web services and semantic net
standards.
 Coordinates with the other architects on issues dealing with the
quality flaws of the existing standards, especially security, session
state and long-running transactions.
 Builds a composite reference model to be used on internet-based
applications, incorporating the models provided by the system
architect, network architect, security architect, and applications
architect.

© 2008 Knowledge Management. All Rights Reserved. PAGE 9

 Architectural Governance Page 10

Network Architect
Because there already exists a central Network team the Network
Architect may reside in this team and be matrixed into the Architecture
team.
 Focuses on the lower-level transport protocols and the standards
and technologies for enabling systems qualities via network
command-and-control structures.
 Evaluates and selects the enterprise’s networking hardware.
 Manages the network topology.
 Establishes network operation center (NOC) command-and-control
structures for auto-discovery, event monitoring, trouble ticketing.
 Facilitates the upgrade to the Web-Based Enterprise Management
(WBEM) standard of the Distributed Management Task Force
(DMTF) and select the appropriate Common Information Model
Object Manager (CIMOM) for tracking the state of the enterprises
assets.
System Architect
 Focuses on the standards and technologies for enabling systems
performance qualities, such as availability, scalability,
recoverability, etc.
 Evaluates and selects the enterprise’s server hardware, operating
system, job control.
 Supports the Applications architect in selecting the application
framework.
 Balances the quality issues cost vs. robustness, and hardware
architecture, such as share-nothing n-tier vs. share-all symmetric
multi-processing (SMP).
 Monitors performance benchmarks provided by the Transaction
Processing Council (TPC).
 In conjunction with the Project Architect (PA) sizes the application
and selects the hardware and configuration to use.
 Participates in the drafting of Service Level Agreements (SLA).
 Establishes a process to monitor existing systems for performance
problems and drafts system migration plan if necessary.
Security Architect
 Monitors security guidelines, such as HIPAA.
 Establishes and enforces the Security Policy and Trust Model for
Administrators to follow in delegating and granting application
privileges.
 Establishes and enforces the Security Model, technologies and
standards for system architects and designers.

© 2008 Knowledge Management. All Rights Reserved. PAGE 10

 Architectural Governance Page 11

 Tracks warnings of new types of security threats and assures that

the systems in place guard against these threats.
 Establishes the systems for discovering, tracking and convicting
abusers of security and system integrity.
 Performs periodic security audits on existing systems.

Process/Methodology Architect
While the other architects are focused on what the system should contain,
the process architect is focused on how the application should be designed
and built.
 Reviews and selects the Design Methodology and Modeling
Language. Methodologies may be based on the Zachman, Rational
Unified Process (RUP), Catalysis, RM-ODP, Iconix, SAADAM,
etc. The modeling language should incorporate the Business
Process Model (BPML) and the Unified Modeling Language
(UML).
 Reviews and selects the Process Management Methodology. It is
recommended that the new iterative methodologies from the Agile
Alliance be reviewed for adoption, esp. Feature-Drive
Development (FDD).
 Defines roles & responsibilities and creates a template Project Plan
for modification by Project Managers.
 Selects CASE & IDE tool & Design Repository.
 Communicates the above to the development teams, and is
enforced by the Project Architects (PA).
 Manages the education of the PAs.

Project Architects (PA)

 Responsible for translating application requirements and business
process models (BPM) into component and interface
specifications.
 Ensures that the Technology Partners and development teams
adhere to the principles established by the Enterprise Architects.
 Designs first-draft graphical UML & ER models that are delivered
to the software development & DBA teams.

© 2008 Knowledge Management. All Rights Reserved. PAGE 11

 Architectural Governance Page 12

The activities of the Project Architect (PA) can be contrasted with the
Project Manager (PM) as shown in the following table:

Topic Project Manager Project Architect

Software Organize project; manage Organizes team or technology
Development resources, budgets, schedules partner around design; manages
dependencies
Requirements Negotiate with marketing; Review requirements; emphasis on
emphasis on business process functionality and system qualities
and user interface
Personnel Handle hiring; performance Interview candidates; provide input
issues appraisals, salary; motivate on technical capabilities of staff;
employees motivate development team
Technology Introduce new technologies per Recommend technology, standards,
architect’s recommendations training, tools
Quality Ensure quality of product Ensure quality of design and
operational control characteristics
Metrics Measure productivity, size, Ensure design goals are met,
quality volumetrics do not exceed scale

© 2008 Knowledge Management. All Rights Reserved. PAGE 12

 Architectural Governance Page 13

Architectural Stance
Architecture Development Process
The most fundamental decision that must be made is a ranking of the
nonfunctional “qualities” that the systems must support (e.g. availability,
security, non-repudiation, etc.). From this follows a determination of open
standards and design patterns (frameworks) that will be incorporated into
future applications. Next the vendors and products are selected that
support the open standards. The set of products must integrate well with
each other and align their API Stack to support the design pattern of the
selected Application Stack (e.g. n-tier with clearly defined nodes). The
tools used by the developers are selected to code, test and debug the
application, and then the tools used to design the application is selected
with the goal of using clear models to generate clean code for rapid
application development (RAD) and model-driven architecture (MDA).
The modeling process must conform with the selected development
methodology for designing robust code that conforms to the business
requirements. Requirements, models, code and test data is kept in a
version-controlled Reuse Library that supports traceability and impact
analysis showing precise time & budget slippage of a change in
requirements. When complete, the above process may iterate to take
advantage of low-hanging fruit where it is found that a product has a
particularly good synergy with other products.
These factors that influence application and development architecture can
be show as:

Management Methodology Architectural Qualities

Design Methodology Standards & Patterns

Design Development Application

Tools Tools Stack

Requirements, Design, Code, QA Repository

© 2008 Knowledge Management. All Rights Reserved. PAGE 13

 Architectural Governance Page 14

Architectural Foundations
Previous architectural decisions at the enterprise level come into play
when designing the architecture for new applications.
  Application Stack that depict recommended & approved
technologies, frameworks and products in support of corporate
standards.
  Reference Models that depict recommended & approved
design patterns.
  Enterprise Models that depict the entire enterprise used to
design interfaces between existing applications and the new
application.

Target Architectures
Architecture Development Method

Application
Reference Enterprise
Stack
Model Model
(standards)

Business Requirements & Service Qualities

Application Stack
The Application Stack can be represented as a matrix that shows
 the design tiers (layers) for the application,
 the open standards API Stack selected,
 the API stack of vendors and products blessed by the company (for
volume purchase and training),
 the design and development tools used to model the design and
generate/edit the source code and debug the application, and
 administrate and manage the application in the operational
environment.

© 2008 Knowledge Management. All Rights Reserved. PAGE 14

 Architectural Governance Page 15

Here is a partial example of an Application Stack. (This is not a

recommendation of these technologies.)

Layer Open Standard Technology Dev. Operations

Stack Tool Management
Communi- TCP/IP, HTTP, Apache Smarts, Remedy
cation HTML, SSL
Application Java, J2EE WebLogic, JSP, Eclipse Smarts, JMX,
WDK Remedy
Data XML, XML EJB, SQLJ
Access Schema Documentum
Storage Relational, SQL, Oracle ERwin BMC
XML
Operating Unix Solaris Tckl Smarts
System
Security LDAP NDS, Netegrity

For multi-tier systems the applications layers are spread over multiple
hardware systems, each with their own stack, with the application
connected across systems by communication protocol stacks offering a
wide array of features in support of the robustness of the application. This
can be graphically represented as API stacks that abstract the hardware
horizontally and the application over hardware nodes vertically.
Here is an example of a 3-tiered application represented across the top of
the stack and the hardware interfaces across the bottom of the stack. The
invocation and abstraction of the hardware goes down the stack, while the
transparent communication protocol is shown touching the relevant
components:

© 2008 Knowledge Management. All Rights Reserved. PAGE 15

 Architectural Governance Page 16

Architectural Layers
Application Architecture is an abstract system specification consisting
primarily of functional components described in terms of their behaviors
and interfaces and component-component interconnections.
Each layer in the stack serves as an abstraction to the layer above it. Each
layer on the stack must have a set of well defined interfaces that are on the
same level of abstraction (that serves some specific purpose). Each layer
is responsible for its own sanity check, and typically trusts each of the
other layers to do the same unless the data is coming from an external
source. Not every layer is used in every transaction. For example, a
simple HTML interaction only goes down through the top several layers
and then returns. Batch loading from a legacy system may skip several
layers. However, if everyone develops their application along a layered
architecture then they only have to worry about communication between
the layers immediately above and below them. If their layer is sometimes
skipped then they must provide a transparent module so the design rule
that layers only interact with the layers immediately above and below
them remains in effect with few exceptions. Specifying a sequence for top
to bottom control flow prevents the problem of cyclic deadlock among
objects. Implementation via purchased software packages (even crossing
multiple layers) is permitted as long as “wrappers” are coded that can
integrate the packaged within the overall architecture and as long as
essential administrative control features are present for each layer (e.g.
scalable configuration).
Breaking the application architecture into a many layered onion facilitates
the adaptability of an application while adding to its complexity. Here is
an example that calls out most of the possible layers, starting from the
customer interface down to the persistent storage:

Customer Customer Applications Browser, Java applet, Legacy system

& Applets
Communications HTTP, ftp, telnet, 3270, EDI, VPN, fax

Access Security, Certification, Firewall, Encryption,

Session Closure, Connection Context

Presentation Native Presentation Layout XML to: HTML, Character, Record

layout, EDI (via Templates+Rules), Validation

Generic Presentation Semantic XML to Layout XML

Transaction Workflow Processing Commerce Events, State Table, Workflow,

Job Initiation, Temporal & Priority Control

Application Context

© 2008 Knowledge Management. All Rights Reserved. PAGE 16

 Architectural Governance Page 17

Application Logic Custom application-specific code goes here

Data Business Object Metadata markup, DB Data Semantic XML,

Semantic Navigation Ontology, Context, KQML, Semantic Undo

Enterprise Schema Data Dictionary, Referential Integrity

Data Distribution Heterogeneous navigation, Scale Redirection,

Legacy Redirection

DB Transaction Stored Procedures, ACID

Data View SQL, Dataset

Physical Data Stores Index/Cluster Architecture, Bloom Filter,

Encryption, RAID

Ubiquitous Services
Transparently supporting each layer of the communicating objects in the
above diagram are the following facilities:

System Framework Reusability, Interoperability, Accountability,

Initiallization

(Communicating Objects) The above layers go here

XML Dataware Business Object Access

Middleware Scalability, Messaging, Load Balancing,

Management Monitor, Fail-over, Restart

Directory / Security DNS, LDAP, X.500

Operating System, System Administration

Network Protocol
Hardware, Wire, Disks

© 2008 Knowledge Management. All Rights Reserved. PAGE 17

 Architectural Governance Page 18

Non-Functional Quality Requirements

The complexity of an application’s functional requirements is not the only
driver of system cost. Often cost and complexity is driven by system
features that are behind-the-scenes and distributed across all functions of
an application, such as “high availability”. These non-functional
requirements have a major impact on the architecture of a system. As it is
not possible to satisfy all requirements simultaneously trade-offs must be
made. Consideration of the selection and weight of each of these qualities
is provided in the following table.
The non-functional quality requirements for the system is ranked below
with a “0” representing a quality that no effort is to be spent on—to—a
“10” representing a quality that must be included even if it means
additional cost and significantly delaying the release of the system. A “1”
represents an optional, nice-to-have, feature. There should be only a few
qualities set at “9” or “10”.

Quality Rank
Business Qualities
Affordability: The ability to build the system with minimum development cost in labor
and tools.
5

Time-to-Market: The ability to build the system in the minimum amount of time and
ahead of competition for the similar functionality.
5

Functionality: The ability of the system to perform all the business tasks it was created
to do per the user’s requirements.
7

Regulatory Compliance: Adheres to governmental regulations. 10

Buildability: Whether or not the architecture can reasonably be built using the budget,
staff, and time available for delivery of the project. Buildability is an often-overlooked
quality attribute. Sometimes, the best architects are simply too ambitious for a project
team to complete given project constraints and environment. The design that casts a
3
solution in terms of well-understood concepts is more buildable than a design that
introduces new concepts.

© 2008 Knowledge Management. All Rights Reserved. PAGE 18

 Architectural Governance Page 19

User Qualities
Usability: How easy it is for the user to understand and operate the system. Usability
can be broken down into the following areas:
Learnability: How quick and easy is it for a user to learn to use the system's
interface?
Efficiency: Does the system respond with appropriate speed to a user's
requests? 2
Memorability: Can the user remember how to do system operations between
uses of the system?
Error avoidance: Does the system anticipate and prevent common user errors?
Error handling: Does the system help the user recover from errors?
Satisfaction: Does the system make the user's job easy?

Gratification: The ability to anticipate the needs of the user and give more than is
asked. Most systems give only what the user specifies and requires the user to expend
significant effort in stating the request. A system with gratification learns the user’s 2
habits and preferences, and intervenes with quick solutions or alternatives when the user
does not appear to making progress.

Localization: The ability easily adapt to multiple languages and locales. 2

Personalization: The ability of a user to adapt the look and feel of the system to their
own taste.
3

Customer Compliance: Adheres to the interfaces, data structures and conventions of

the customer’s systems without requiring modifications of their systems.
8

Accuracy: Ability to provide the right or agreed results or effects with the needed
degree of precision. Includes the ability to resist or correct poor data quality.
8

Mobility: Ability to support mobile devices and cellular communications. 0

Administrator Qualities
Manageability: Can be expressed in terms of how easy it is to monitor a system and
detect operational characteristics related to performance and failures, how easy it is to
configure systems, the processes used for effecting this control, and the degree to which
3
the system can be managed remotely.

Administrability: Can be expressed in terms of how easy it is to configure an

application and detect application characteristics related to functional usage, how easy it
is to configure the application, the processes used for effecting this control, and the 7
degree to which the application can be administered by multiple parties in cooperating
roles.

Data Location Transparency: The business logic layer of the application does not
know the physical location of the data. The data may be distributed to multiple
locations at sites determined by the DBAs and administrators for tuning, fail-over, and
8
storage resource control.

© 2008 Knowledge Management. All Rights Reserved. PAGE 19

 Architectural Governance Page 20

Component Location Transparency: A client does not know where a target server
object resides. It could reside in a different process on another machine across the
network, on the same machine but in a different process, or within the same process. 7
Different components can be distributed over multiple machines, or, copies of the same
component can be distributed over multiple machines.

Implementation Transparency: A client neither knows how a target object is

implemented, what programming or scripting language it was written in, nor the 2
operating system and hardware it executes on. This is also a security issue.

Hardware Virtualization: The application may be moved unchanged as compiled

from the testing to the operational environment and across multiple hardware 1
environments. VMware is an example of such an approach.

Object (Server) State Transparency: When a client makes a request on a target server
object, it does not need to know whether that object is currently activated (i.e. in the
executing state) and ready to accept requests or not. The ORB transparently starts the 3
object if necessary before delivering the request to it. This feature greatly helps
recovery handling for distributed objects.

Communication Mechanism Transparency: A client does not know what

communication mechanism (e.g., TCP/IP, shared memory, local method call, etc.) the
ORB uses to deliver the request to the object and return the response to the client.
2
Multiple communication strategies may be statically or dynamically set.

Security: The ability of the system to resist unauthorized attempts to access the system
and denial-of-service attacks while still providing services to authorized users. Includes
levels of authentication supported, granularity of authorization controls, and techniques
9
utilized to ensure the integrity of resources.

Auditability: The ability to ensure that the previous system states can later be
reconstructed and observed. Includes recording and analyzing activities to detect 9
intrusions or abuses.

Accountability: The ability to ensure that the ultimate causes of the previous system
states can later be identified. The ability to know who did what.
8

Confidentiality: keeping information secret only to those who are authorized to see it. 9
Anonymity: concealing the identity of an entity involved in a process. 3
Privacy: Ability to follow business rules in regard to the rights and responsibilities that
govern the acquisition, disclosure, and use of personal information.
9

Data Integrity: ensuring information has not been altered by unauthorized means. 9
Data Authentication: corroborating the source of data 7
Access Control: restricting access to resources to authorized entities. 8
Non-Repudiation: The ability to provide legally accepted proof that a user executed a
particular transaction, even if they deny having done it. Must be able to discriminate 5
against spoofing and man-in-the-middle attacks.

© 2008 Knowledge Management. All Rights Reserved. PAGE 20

 Architectural Governance Page 21

Qualities of Service
Quality of Service (QoS): The ability to measure and stay within the guaranteed
performance and availability limits for contracted services per SLA.
4

Scalability: The ability for the system to grow linearly by adding hardware as the
number of users and transactions increase beyond initial implementation. For high
scalability you typically need:
Asynchronicity
Statelessness
Parallelism 5
Pipelining
Location Transparency
Load Balancing
GUIDs

Performance: A specification of the workload and the latency or throughput

requirement. The form of the specification will depend on the type of system. In an
interactive system, the form of the specification might be an abstract specification of the
number of users and a deadline for response; in an embedded real-time system, the form
6
of the specification might be a characterization of the input events and an associated
deadline.

Responsiveness: A measurement of the system response time for a functional

requirement.
6

Availability: The amount of time that the system is up and running. It is measured by
the length of time between failures, as well as by how quickly the system is able to
restart operations after a failure. For example, if the system was down for one day out 7
of the last twenty, the availability of the system for the twenty days is 19/19+1 or 95
percent availability. This quality attribute is closely related to reliability. The more 99.9%
reliable a system is, the more available the system will be. The rule of thumb is that
each additional “9” of availability raises system cost ten-fold.

Survivability: The ability to reestablish operations after a catastrophic event that

leaves all existing systems unusable.
8

Reliability: The ability of the system to operate over time. Reliability is measured by
the mean-time-to-failure of the system.
8

Recoverability: The ability to resume operations after a hardware or software fault that
halts the current systems. Is expressed by: 1. Capability to reestablish the level of
performance. 2. Capability to recover the data. 3. Time and effort needed for it.
7
Measured by Mean-Time-To-Repair.

Nomadicity: Having components (or mobile agents) that can survive relocation of the
component and/or automatically discover alternative living peer components in the
event that the peer components it was communicating with fail, or can continue to work
without interruption should related components fail. The DNS internet, Microsoft
1
Outlook/Exchange, and cellular phone system are examples of nomadic systems.
Service Oriented Architecture (SOA) using UDDI can easily be made nomadic.

© 2008 Knowledge Management. All Rights Reserved. PAGE 21

 Architectural Governance Page 22

Autonomic Computing: Autonomic computing derives its name from the autonomic
nervous system and denotes its ability to free our conscious brains from the burden of
dealing with the vital, but lower-level, functions of the body. As used in the software
industry, autonomic computing refers to self-managing systems that are comprised of
four core characteristics:
self-configuration,
self-healing,
self-optimizing, and
self-protecting.

Transactionality: The ability to commit a unit of work or, in the case of an error, roll-
back the data across all tables and stores. To be transactional all of the ACID
constraints (qualities) must be met:
Atomic: all or nothing 8
Consistent: logically correct transformation
Isolated: no concurrency bugs
Durable: survives failures

Software Life-Cycle Qualities

Evolvability: The ability of a system to change over time with minimum phased cut-
over impact.
3

Composability: The ability to sell the system as separate components that can work on
their own or together in harmony.
5

Extensibility: The ability to easily add new data and behaviors to existing code by the
developers.
7

Tailorability: The ability easily adapt the system to the needs of a specific customer.
Includes the ability to re-brand the user interface. Minimizes the effort needed to 6
maintain separate code bases.

Adaptability: The ability to define business processes, business rules and refine data
types by an application administrator dynamically, without needing code revision.
9

Maintainability: The measurement of how easy it is to change the' system to

incorporate new requirements. The two aspects of' modifiability are cost and time. If a
system uses an obscure technology that requires high-priced consultants, even though it
3
may be quick to change, its maintainability can still be low.

Portability: Measures the ease with which the system can be moved to different
platforms. The platform may consist of hardware, operating system, application server 7
software, or database server software.

Reusability: The ability to reuse portions of the system in other applications.

Reusability comes in many forms. The run-time platform, source code, libraries, 2
components, operations, and processes are all candidates for reuse in other applications.

© 2008 Knowledge Management. All Rights Reserved. PAGE 22

 Architectural Governance Page 23

Integrability: The ability to make the separately developed components of the system
work correctly together as a whole. This in turn depends on the external complexity of
the components, their interaction mechanisms and protocols, and the degree to which
responsibilities have been cleanly partitioned, all architecture-level issues. Integrability
also depends upon how well and completely the interfaces to the components have been 6
specified. Integrating a component depends not only on the interaction mechanisms
used (e.g., procedure call versus process spawning) but also on the functionality
assigned to the component to be integrated and how that functionality is related to the
functionality of this new component's environment.

Interoperability: Integrability measures the ability of parts of a system to work

together; interoperability measures the ability of a group of parts (constituting a system)
to work with another external system. The integrability of a system depends on the 7
extent to which the system uses open integration standards and how well the API is
designed such that other systems can use the components of the system being built

Testability: The ease with which software can be made to demonstrate its faults
through testing (probability that the software will fail on its next test, given that it has at
least one fault). How easily the system can be tested using human effort, automated
testing tools, inspections, and other means of testing system quality. Good testability is
3
related to the modularity of the system. If the system is composed of components with
well-defined interfaces, its testability should be good.

Variability: How well the architecture can handle new requirements. Variability
comes in several forms. New requirements may be planned or unplanned. At
development time, the system source code might be easy to extend to perform new 3
functions. At run-time, the system might allow pluggable components that modify
system behavior on the fly. This quality attribute is closely related to modifiability.

Subsetability: The ability of the system to support a subset of the features required by
the system. For incremental development, it is important that a system can execute
some functionality to demonstrate small iterations during product development. It is the
property of the system that allows it to build and execute a small set of features and to 7
add features over time until the entire system is built. This is an important property if
the time or resources on the project are cut. If the subsetability of the architecture is
high, a subset of features may still make it into production.

Conceptual Integrity: The ability of the architecture to communicate a clear, concise

vision for the system, also know as Architectural Style. Fred Brooks writes, “I am more
convinced than ever. Conceptual integrity is central to product quality. Having a system
architect is the most important single step toward conceptual integrity…. After teaching
a software engineering laboratory more than 20 times, I came to insist that student
teams as small as four people choose a manager and a separate architect” (Brooks
1995). Kent Beck believes that metaphors are the most important part of the eXtreme
Programming methodology (Beck 1999). The metaphor is a powerful means of
providing one or more central concepts for a system. The metaphor provides a common 5
vision and a shared vocabulary for all system stakeholders. The metaphor provides a
means to enforce conceptual integrity. When the design of the system goes outside the
bounds of the metaphor, the metaphor must change or new metaphors must be added;
otherwise, the design is going in the wrong direction. If any of these design decisions
are made without the concept feeling right, the conceptual integrity of the system will
be lost. Sometimes the system metaphor is an architectural pattern, such as MVC or
Blackboard. These architectural patterns provide a common metaphor for system
developers or others who understand the patterns.

© 2008 Knowledge Management. All Rights Reserved. PAGE 23

 Architectural Governance Page 24

Non-obsolescence: If the system is intended to have a long lifetime, modifiability and

portability across different platforms become important, as well as rejection of
technologies that may become obsolete and vendors that may go out of business.
Building in the additional infrastructure (such as a portability layer) to support 6
modifiability and portability will usually compromise time to market. On the other
hand, a modifiable, extensible product is more likely to survive longer in the
marketplace, extending its lifetime.

Installability: The capability of the software product to be installed in a specified

environment.
7

Co-existence: The capability of the software product to co-exist with other

independent software in a common environment, sharing common resources.
1

Replaceability: The capability of the software product to be used in place of another

specified software product for the same purpose in the same environment.
2

Standards Compliance: Adheres to external open standards. 7

The following qualities are absent from this list and may be added later if needed: flexibility,
understandability, deployability, configurability, degradability, accessibility, demonstrability,
footprint, simplicity, stability, timeliness, schedulability, openness, seamlessness, safety, trust,
Error, Multi-Undo, feedback, empowerment

© 2008 Knowledge Management. All Rights Reserved. PAGE 24