The EA Glossary

Business Transformation Methodology

Enterprise Architecture is about Business Transformation Enablement, so why not call it that? That's what Government of Canada is doing.

BTEP facilitates change. It provides a disciplined method that will allow us to move our transformation agenda forward, providing design and alignment tools to enable rapid change in business processes and the infrastructure that supports them.

Using a formal, standardized business transformation methodology tailored to the public sector means business goals are defined and described in a language and format government executives and managers understand. This makes the business of planning, designing, managing, communicating and implementing business transformation itself a more efficient process. It supports more rigour and due diligence at the project level, and increases the likelihood that economies of scale, adaptability and enhanced productivity will result from business transformation across the full spectrum of government operations.

The Government of Canada's Business Transformation Enablement Program or BTEP is developing this transformation methodology. As such, the Program is not producing a solution for the transformation of all of the government's business processes and information systems. Rather, it is developing a standardized means by which such solutions can be planned, designed and cost-effectively implemented by departments and agencies.

From: Business Transformation Enablement Program. Executive Overview. September 2004

Open standard

A standard is considered to be open when it complies with all these elements:

• cannot be controlled by any single person or entity with any vested interests;
• evolution and management in a transparent process open to all interested parties;
• platform independent, vendor neutral and usable for multiple implementations;
• openly published (including availability of specications and supporting material);
• available royalty free or at minimal cost, with other restrictions (such as field of use and defensive suspension) offered on reasonable and non-discriminatory terms; and
• approved through due process by rough consensus among participants.

From: The Roadmap for Open ICT Ecosystems, Harvard (2005)

A completely open standard has the following properties:

• It is accessible and free of charge to all
• It remains accessible and free of charge
• It is accessible free of charge and documented in all its details

From: Danish National IT and Telecom Agency, Definition of Open Standards, June 2004

Krechmer (2005) points out that the term Open Standards may be seen from the following three perspectives: 

1. The formal SSOs, as organizations representing the standards creators, consider a standard to be open if the creation of the standard follows the tenets of open meeting, consensus and due process.
2. An implementer of an existing standard would call a standard open when it serves the markets they wish, it is without cost to them, does not preclude further innovation (by them), does not obsolete their prior implementations, and does not favor a competitor.
3. The user of an implementation of the standard would call a standard open when multiple implementations of the standard from different sources are available, when the implementation functions in all locations needed, when the implementation is supported over the userís expected service life and when new implementations desired by the user are backward compatible to previously purchased implementations.

These are the very different views from the creators, implementers and users of standards on what is an Open Standard. Their combined, reasonable, but not simple expectations translate into ten rights that enable Open Standards:

1. Open Meeting - all may participate in the standards development process.
2. Consensus - all interests are discussed and agreement found, no domination.
3. Due Process - balloting and an appeals process may be used to find resolution.
4. Open IPR - IPR related to the standard is available to implementers.
5. One World - same standard for the same capability, world-wide.
6. Open Change - all changes are presented and agreed in a forum supporting the five rights above.
7. Open Documents - committee drafts and completed standards documents are easily available for implementation and use.
8. Open Interface - supports migration and allows proprietary advantage but standardized interfaces are not hidden or controlled.
9. Open Use - objective conformance mechanisms for implementation testing and user evaluation.
10. On-going Support - standards are supported until user interest ceases rather than when implementer interest declines (use).

From Ken Krechmer, International Center for Standards Research, University of Colorado: The Meaning of Open Standards (2005).

An Open Standard is more than just a specification. The principles behind the standard, and the practice of offering and operating the standard, are what make the standard Open.
Bruce Perens: Open Standards: Principles and Practice

Wikipedia on Open standard

Loose coupling

The friction-free linking enabled by web services (or any SOA). Loosely coupled services, even if they use incompatible system technologies, can be joined together on demand to create composite services, or disassembled just as easily into their functional components. Participants must establish a shared semantic framework to ensure messages retain a consistent meaning across participating services.
Loosely Coupled glossary

Loosely coupled is an attribute of systems, referring to an approach to designing interfaces across modules to reduce the interdependencies across modules or components – in particular, reducing the risk that changes within one module will create unanticipated changes within other modules.
John Hagel's weblog

Doug Kaye's comparision table of tightly coupled and loosely coupled.

De-facto Standard

A de facto standard is introduced by a market player and establishes itself as the - or one of the - dominant standards without the backing of official standardisation bodies.
Danish National IT and Telecom Agency, Definition of Open Standards, June 2004

Standards that have become accepted and adopted although not originally defined by consent. Often are more important than standards that have been defined by consent of standards groups.
Commonwealth of Virginia Enterprise Architecture Glossary

Interoperability

Interoperability means the ability of information and communication technology (ICT) systems and of the business processes they support to exchange data and to enable sharing of information and knowledge.
European Interoperability Framework for Pan-European eGovernment Services, January 2004

Interoperability, which means achieving the required coherence in the most effective way, can thus be seen as the most important key for e-government. In the architecture context, interoperability means especially that it is necessary to have common integration principles and standards for exchanging information.
Danish Ministry of Science, Technology and Innovation, White Paper on Enterprise Architecture, June 2003

Interoperability is the ability of a system or process to use information and/or functionality of another system or process by adhering to common standards.
European Public Administration Network's eGovernment Working Group report Key Principles of an Interoperability Architecture, June 2004.

The ability of government organisations to share information and integrate information and business processes by use of common standards.
New Zealand E-government Strategy, Dec 2001

The ability of different operating and software systems, applications, and services to communicate and exchange data in an accurate, effective, and consistent manner.
US H.R. 2458 - the E-Government Act of 2002

The ability of information systems to operate in conjunction with each other encompassing communication protocols, hardware software, application, and data compatibility layers.
ICH Glossary

Conway's Law

"Organizations which design systems are constrained to produce system which are copies of the communication structures of these organizations"
Conway, M.E. "How do Committees Invent?", Datamation, (14) 4, April 1968. pp28-31.

For investments in enterprise architecture to pay off, they must be based on a clear understanding of the organization. Whatever approach you choose to implement your enterprise strategy, an understanding of Conway's Law can help to make your alignment efforts successful.
Conway's Law Revisited: Successfully Aligning Enterprise Architecture, May 1, 2002, David Dikel and David Kane.

Organizational politics is essential to the effectiveness of an architect. Architectures have many and diverse stakeholders. Often they are used across organizational boundaries, by other projects, divisions, and even other companies. To gain and maintain the sponsorship of management and the enthusiastic support of other key influencers, you need to do a good deal of influencing yourself.
Organizational Politics - Architect Competency Elaboration, Bredemeyer Consulting 2002.

The rule that the organisation of the software and the organisation of the software team will be congruent; originally stated as "If you have four groups working on a compiler, you'll get a 4-pass compiler".
Melvin Conway, an early proto-hacker, wrote an assembler for the Burroughs 220 called SAVE. The name "SAVE" didn't stand for anything; it was just that you lost fewer card decks and listings because they all had SAVE written on them.
Free Online Dictionary of Computing

In any organization there is one person who knows what is going on. That person must be fired. (source)

Cunningham's Wiki on Conway's Law

Problem, context, forces, solution, resulting context and design rationale.
Bell Labs, 1995

Framework

A logical structure for classifying and organizing complex information.
[Federal Enterprise Architecture Framework]
ICH Glossary

Illustration of the various architecture elements, used as a guide for assisting governments as they create enterprise architectures for their organizations.
Government Enterprise Architecture Framework (GEAF) Terminology

a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise's systems.
John Zachman, creator of The Universal Framework.

The NASCIO Tool-Kit presents four Frameworks:

• Enterprise Architecture Framework


• Architecture Governance Framework


• Business Architecture Framework


• Technology Architecture Framework

NASCIO Enterprise Architecture Development Tool-Kit v2.0, July 2002

Principle

A statement of preferred direction or practice. Principles constitute the rules, constraints and behaviors that a bureau, agency or organization will abide by in its daily activities over a long period of time.
NASCIO Enterprise Architecture Development Tool-Kit v2.0, July 2002

Principles establish the basis for a set of rules and behaviors for an organization. There are principles that govern the EA process and principles that govern the implementation of the architecture. Architectural principles for the EA process affect development, maintenance, and use of the EA. Architectural principles for EA implementation establish the first tenets and related decision-making guidance for designing and developing information systems.
A Practical Guide to Federal Enterprise Architecture, Chief Information Officer Council, Version 1.0, February 2001. Includes sample architectural principles.

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.
TOGAF "Enterprise Edition" Version 8.1, Part IV, 2002

An architectural principle is a fundamental rule that applies to a large number of situations and variables. Architectural principles include "separation of concerns", "generic interface", "self-descriptive syntax," "visible semantics," "network effect" (Metcalfe's Law), and Amdahl's Law: "The speed of a system is determined by its slowest component."
Architecture of the World Wide Web, W3C, December 2003

A good analogy for the development of the Internet is that of constantly renewing the individual streets and buildings of a city, rather than razing the city and rebuilding it. The architectural principles therefore aim to provide a framework for creating cooperation and standards, as a small "spanning set" of rules that generates a large, varied and evolving space of technology.
Architectural Principles of the Internet, IETF, June 1996

Guiding Principles for Enterprise Architects, Ruth Malan and Dana Bredemeyer, May 2004

Line of Sight

The indirect or direct cause and effect relationship from a specific IT investment to the processes it supports, and by extension the customers it serves and the mission-related outcomes it contributes to.
FEAPMO Performance Reference Model (PRM)

This "line of sight" is critical for IT project managers, program managers, and key decision-makers to understand how and to what extent technology is enabling progress towards outputs and outcomes. The PRM captures this "line of sight" to reflect how value is created as inputs (such as Technology) are used to help create outputs (through Processes and Activities), which in turn impact outcomes (such as Mission and Business). This structure builds from the concepts of the value chain, program logic models, and the theory of constraints. Guiding the entire PRM are "Strategic Outcomes," which represent broad, policy priorities that drive the direction of government (such as to Secure the Homeland or Expand E-Government). Conversely, the PRM is also structured to allow the desired outcomes an organization seeks to achieve to determine the outputs and technology needed.
From NBC.gov glossary