Volume 5


Book Summary: An Introduction to and Extended Review of Coherency Management

Available in July 2009, the new book, Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance discusses a more outcome-oriented way to envision the practice of Enterprise Architecture (EA). The book is edited by Gary Doucet, John Gøtze, Pallab Saha and Scott Bernard, and commenced with the publication of an article in the May 2008 edition of JEA that captured the essential elements of what Coherency Management is all about. This article also formed the basis of a solicitation that went out to Enterprise Architecture leaders throughout the world as the editors looked for others to contribute to the book. The result is a work that covers a wide spectrum of current EA theory and practice throughout the world, with Coherency Management as an organizing principal.

A Need for Formalization and Auditing in Enterprise Architecture Approaches and Programs

This article discusses two important improvements that are needed in Enterprise Architecture (EA) programs: (1) formalization in EA approaches and (2) auditing of EA programs. Formalization occurs through the implementation of six elements that are foundational to any EA approach: governance, methodology, framework, artifacts, repository, and best practices. Auditing is accomplished through an approach-neutral process that evaluates completeness, consistency and utilization to promote transparency, accountability, maturity, and value. The article provides context through a discussion of the background of EA, the growing popularity of EA programs in the public and private sectors, and the mixed record of value the EA programs have produced for different stakeholder groups, some of whom tend to view a formalized architecture as expensive to develop, light on returns, and a threat to project or system-specific interests. Auditing is discussed as a best practice that should be considered as an essential aspect of any EA program, just as auditing is integral to most quality assurance approaches and is the impetus for several influential federal laws that seek to improve accountability, accuracy, and service delivery. The article concludes with an introduction of the EA Audit Model (EA2M) as a method to support the formalization and maturation of EA programs.

How to Restart an Enterprise Architecture Program After Initial Failure

This article discusses a number of common causes of Enterprise Architecture (EA) Program failures, which in total may be as high as 40% of all public and private sector efforts, due in general to poor execution and a failure to deliver value to the business. The author cites seven areas to address in restarting an EA Program after initial failure, which include: not understanding what EA is; unclear leadership; insufficient resources; the scope is too big; lack of perceived value; lack of use; and competition with other best practices. By mapping the positive and negative results of a failed initial EA Program to the seven common failure areas, an organization can develop an “Organization-Specific EA Implementation Strategy” (OSEAIS) to guide a restart. The OSEAIS provides a comprehensive vehicle for ensuring a common understanding, communication, training, committed leadership, resources, governance, and value delivery. When combined with a mature, proven EA framework and approach, the OSEAIS can provide a reliable method for ensuring the successful re-start of an EA Program.

System Architecture Concerns: A Stakeholders’ Perspective

This article is based on a research on identifying different stakeholders’ concerns for system architecture and design. It explores if the different stakeholders’ need for system architecture information is related to their concerns. It addresses two important research questions on system architecture descriptions, namely, 1) Do all stakeholders have different needs for information on system architecture concerns? and 2) How much of similarities and differences exist between the stakeholders’ need for such information. The authors analyze if the system architecture information needs of the stakeholders’ can be addressed by providing different views to different stakeholders. Based on the findings of their research, the authors propose a two-view architecture framework, Summary view and In-Depth view, which can help development projects that are required to generate stakeholder specific architecture views. The findings of the study suggest that the information needs of different groups of stakeholders for system architecture are driven by their own need to get their tasks of system realization completed.