Article

Enterprise architecture (EA) is based on the principle that integrating strategic, business, and technology planning optimizes the use of information resources across non-technical disciplines and organizational lines. It offers a practical ability to make technical architecture a reflection of business intent. Achieving this top-down effect requires a clear entry point into EA for strategic decisions and efficient communication that translates strategic ideas into the EA components that drive on-going system development. Language differences along the architectural progression are barriers to implementing an EA program as a strategic initiative. The term friction captures the effect of language gaps on the quality of communication throughout the scope of EA. Friction is a primary determinant of the relevance of information-based capabilities to operational performance and its corresponding business outcomes. Minimizing friction is a primary goal of EA governance, achieved by a combination of EA repository assessment, tool selection, and methodology integration that harmonizes business intent across EA related disciplines. Analyzing the transformations that occur at communication boundaries suggests ways to overcome friction. Most possible solutions are limited by the fundamentally different skills required of specialized practitioners on either side of a boundary. Short of converting strategists into enterprise architects or vice versa the most practical compromise lies in adopting two dominant characteristics when expressing business strategy, tactics, and capabilities– a high degree of structure and semantics that require minimal translation along the system development path. This article defines friction and identifies its sources in an EA program. It outlines techniques for assessing the friction profile of an EA repository. Based on this profile, it suggests EA governance techniques that reduce friction and thus improve the usefulness of EA artifacts as enablers of effective communication along the strategy – implementation continuum. This article also identifies service strategy and design as an existing, mature, and technically relevant discipline that exhibits low friction across a long span of EA activities. The Information Technology Infrastructure Library (ITIL) makes a detailed and compelling case that business service management is a primary strategic asset1. The corresponding service management lifecycle provides a useful pattern for assessing the efficiency of transforming a business service into its architectural counterpart in the form of service oriented architecture (SOA). This indicates that service orientation is a useful point of departure for design of a tangible strategy for minimizing friction in an EA program.

The increasing complexity of enterprise information systems makes it very difficult to prevent local failures from causing ripple effects with serious repercussions to other systems. This article proposes the use of Enterprise Architecture models coupled with Bayesian Belief Networks to facilitate Failure Impact Analysis. By extending the Enterprise Architecture models with the Bayesian Belief Networks we are able to show not only the architectural components and their interconnections but also the causal influence the availabilities of the architectural elements have on each other. Furthermore, by using the Diagnosis algorithm implemented in the Bayesian Belief Network tool GeNIe, we are able to use the network as a Decision Support System and rank architectural components with their respect to criticality for the functioning of a business process. An example featuring a car rental agency demonstrates the approach.

A senior information technology leader with over three decades of military, government, and industry experience believes that much of our traditional, professional information technology thinking lags contemporary challenges. Information-on-demand and the social networking phenomena create new office worker expectations regarding universal information access and mobility. Yet, many information technology managers remain mired in “network think” and labelled by their organizations as the “office of no.” The author challenges contemporary security and enterprise architecture thinking to go beyond network borders and look for solutions in a “trusted cloud” to address the information needs of users, customers, and partners.

An ontology-driven enterprise architecture framework is presented that provides substantial benefits over conventional representations of traditional architecture domains such as business, data, application, and systems. These benefits range from the tractable synthesis of large and complex domains, improved architecture maintainability and evolution, and more effective analyses of architecture improvement scenarios. An enhanced architecture meta-model is presented, followed by an ontology framework that emphasizes composition via sub-ontologies and normalization. Tools and techniques for ontology persistence, development, testing, reasoning, querying, and visualization that constitute the solution landscape are also discussed. Finally, a set of recommendations provides guidance on selecting the right mix of technologies and tools to compose and interpret enterprise solutions.

Enterprise Architecture is a complex and daunting discipline that touches multiple aspects of an enterprise as well as people participating in various roles throughout the life cycle of the enterprise. The Zachman FrameworkTM for Enterprise Architecture offers a formal and highly structured representation of an enterprise. The Framework’s “Perspectives” correspond to specific stakeholder groups that play different roles in the implementation of an Enterprise Architecture. This article demonstrates that the influence that the Zachman Framework’s Perspectives (rows) have on each other can be used to derive a rational allocation of stakeholders’ skills and time that promotes specifications cohesion throughout the implementation of an Enterprise Architecture. We do so by prescribing upper bounds to stakeholders’ relative degree of involvement based on the level of influence that they exert at any given point in time on Enterprise Architecture artifacts mapped to the Zachman Framework.