Case

Consistent with its goal of providing a management planning tool in the context of complex information technology, Enterprise Architecture (EA) unifies a broad range of documentation artifacts from different disciplines. Each of these artifacts is expressed in the language of its native discipline. By inclusion in an EA framework, the artifacts constitute the nouns of the EA language used to describe strategy and its transition to business capabilities. EA frameworks define paths through which decisions and facts flow in the course of pursuing an enterprise level initiative. The dimensions of an EA framework expose the boundaries that occur along these paths. When boundaries are crossed as detail is added and refined, transformations occur. Transformations are the verbs of the EA language. EA frameworks go to great lengths to describe their nouns and organize them into understandable dimensions as a form of dictionary to guide the practitioner. Yet the verbs that are equally important contributors to the quality of an enterprise initiative receive less attention. Like artifacts, transformations also have properties that can be tailored for efficiency. As a complement to EA artifacts, design and selection of EA transformations must also receive consideration when selecting an EA framework for a specific purpose. Fortunately for EA transformation analysis, a transformation is bracketed by the set of input and output artifacts involved. Thus it is instructive to use the extensive artifact descriptions from an EA framework to make value judgments regarding the choice of transformation techniques. Combined with known transformation techniques and transformation theory, an EA practitioner can tailor a framework for both artifact and transformation efficiency. Following an introduction that establishes transformation principles, this paper looks at a series of well-documented EA frameworks as means of illustrating the extent to which their dimensional structure and artifacts support efficient transformations. The analysis reveals the range of explicit support for efficient transformations within the EA documentation. Where transformations are not explicitly discussed as part of the methodology, characteristics of each framework that might form the basis for tailoring a transformation strategy within the framework are discussed. To conclude, a brief summary of transformation theory is presented in the form of a meta-model and a procedure for evaluating EA transformations.

This article examines the impact of information technology (IT) governance and enterprise architecture (EA) on the integration of Sarbanes-Oxley Act – Section 404 compliance programs during mergers and acquisitions (M&A). The interrelation between these topics was identified based on a review of current literature within the respective fields. Based on this review, the author proposes that the implementation of a centralized governance structure has a significant impact on the success of Sarbanes-Oxley Act – Section 404 compliance during M&A transactions. This hypothesis is tested using a case study approach, in which a suitable information governance structure is identified, and an EA implementation methodology is defined for the integration of compliance programs of the acquiring and target companies. The finding was that centralized IT governance is more likely to achieve or maintain Sarbanes-Oxley 404 compliance during M&A activity, and that EA is useful to establish this type of governance.

Much has been written about the “Digital Divide” where less affluent citizens are (or will be) left out of current or new technologies due to availability factors and the increasing cost of participation. Relatively little has been written about one important aspect of the Digital Divide that relates to the transformation of the electronic payment receipt process, and how participation in many online e-payment processes requires the use of a credit card or debit card. The nature of these transactions has the effect of excluding citizens who primarily use cash and/or personal bank checks from participation. This directly impacts not only the digital divide but also the return on investment of these e-payment solutions to the government entity providing them. The City of Denton, Texas has worked to address this “technomic” divide by developing equitability in payment options by replacing package enabled re-engineering with enterprise architecture as the planning approach for service delivery.

This article describes the Methodology for Business Transformation v1.5 and how it can be used as a step-by-step approach for developing architecture. The recent publication of OMB’s Federal Enterprise Architecture (FEA) Practice Guidance clearly articulates the inter-relationships between the three architecture levels: enterprise, segment, and solution. This article introduces the MBT v1.5 as a practical approach to developing these architecture levels with executive and mission area leadership, participation, and buy-in. This article is written to encourage federal and private sector architecture practitioners to use the MBT in their own organizations. The MBT is feely available as an open-source methodology . It is available at www.doi.gov/ocio/architecture/mbt.

To promote a better understanding of two leading approaches to enterprise architecture, this case study provides an analysis and comparison of the Department of Defense Architecture Framework (DoDAF) and the Zachman Enterprise Architecture Framework (ZEAF). The case study includes a history of the DoDAF and ZEAF, a summary of both approaches, and the results of a survey of IT professionals in the Department of Defense regarding the strengths, weaknesses, and usefulness of each approach. The survey found that a majority of the respondents believes the strengths of the DoDAF are that it distills information into manageable pieces, it provides a logical approach, and it is comprehensive. Some reported strengths of the ZEAF are it is an intuitive approach, easily adaptable, and well known. Some of the observed drawbacks of the DoDAF are it is cumbersome, inflexible, and unchangeable. Additionally, while the DoDAF has a schema to support the documentation of operational requirements and design decisions can be traced using the DoDAF architecture, it does not provide modeling capability for software configuration. The survey also found some drawbacks of the ZEAF are it is overly simplistic and lacks cognitive/business direction. For example, the ZEAF does not prescribe design tradeoffs, design rationale, or documentation of architecture decisions. None-the-less, both the DoDAF and ZEAF were found to be excellent tools that can be used to provide structure to the development of a holistic view of an enterprise.

Frameworks help people organize integrated models of their enterprises. This organization helps ensure interoperability of systems and helps control the cost of developing systems. The Zachman framework for enterprise architecture is a six by six classification schema, where the six rows represent different perspectives of the enterprise and the six columns illustrate different aspects. To ensure a complete and holistic understanding of the enterprise architecture, it is necessary to develop models that address the perspectives and aspects that constitute the rows and columns, respectively, of the framework. In this paper, a Zachman framework is populated with models for Baseball. These models should be easy to understand without a steep learning curve. Most of the cells in this example are filled with quantitative simulatable models that have been published in peer-reviewed journal papers. The other cells are filled with simple thought models. Jacques Barzun (1954) wrote, “Whoever wants to know the heart and mind of America had better learn baseball, the rules and realities of the game. From the perspective of the Zachman framework, the way to lean Baseball is to define the models within the framework, as presented in this paper.