Issue 1

{{post_terms.hashtags}}

The Future of Information Technology – Part 3: Model and Event Driven Architecture (2008-2017)

Though it is largely an abstract concept, enterprise architecture (EA) has shaped, is shaping, and will continue to shape information technology. This four-part article traces the author’s observations and predictions about the current and future state of information technology, and the role that EA will play in that evolution. Part 3 looks forward to resolving the business issues and shortcomings of SOA, by discussing the next wave in the creation of a more perfect IT architecture, the embryonic Model and Event Driven Architecture (MEDA). It will discuss the business and technical challenges inherent in this migration from SOA to MEDA. In addition, it will suggest several potential business and technical issues that may arise as a result of the implementation of a MEDA.

Comparing the Department of Defense Architecture Framework and the Zachman Enterprise Architecture Framework

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.

When Enterprise Architecture Meets Government: An Institutional Case Study Analysis

This study investigates the systemic challenges facing enterprise architecture programs in government. Drawing upon the institutional theory lens from the political science field, a Danish case study is used to explore why public agencies implement enterprise architecture programs and the challenges they face when governing these programs at different levels (vertically) and different functions (horizontally) of government. The analysis shows that enterprise architecture is not just a technical issue, as economic and political facts are equally important when establishing interoperable e-government services. The findings suggest that implementing enterprise architectures in government challenges the way information systems are organized and governed in public agencies. Interoperability challenges in government arise because there is no overall coordination of different information systems initiatives in the public sector and because public organization have no economic and/or immediate political incentives to share data and business functionality with other organizations in their enterprise architecture programs.

Providing Deep Business Value: A Supply Chain Case Study

Enterprise Architecture (EA), born in the private sector under fractured proprietary process methodologies, has matured into a serious discipline thanks to the funding strengths of the Federal Government and the dedication of many practitioners. Application of this systems engineering discipline has come about under the shadow of a federally-induced mandate, but with mixed results. The United States Office of Management and Budget’s primary focus on Information Technology (IT) has results in an inappropriate association of EA as an “IT thing” and has caused EA to lose credibility among business leadership. The author argues that EA can be about more than IT and more than a necessary evil. It can actually provide deep business value and provide a structure for breaking down and managing complex problem. From personal experience in applying EA to a private sector e-commerce solution for supply chain management, the author presents elements of an e-business approach that others can leverage to help craft an operational EA that generates more than expensive shelf-ware. EA can become crucial in day-to-day operations and can be used within executive ranks to drive business decisions.

Assessment of a Government Agency’s Enterprise Architecture Program

The purpose of this article is to evaluate the Enterprise Architecture (EA) program for an Anonymous Federal Agency (AFA), a title chosen because actual situations from a federal agency EA program are used in this article, some of which are sensitive in nature. The evaluation methodology used in this article is based of the United States Government Accountability Office’s EA Management Maturity Framework (EAMMF) and its five stages of EA program maturity. In 2005, AFA’s current capability to utilize their EA received the lowest EAMMF rating (Stage 1) overall, with only some EA areas being at Stage 2. The AFA could improve their EA program by (1) avoiding Anne Lapkin’s “seven worst EA practices”; (2) involving stakeholders from throughout the AFA enterprise, not just from information technology; (3) education, involving, and requiring leadership’s participation (business and technical); and (4) remembering that developing EA documentation is an important aspect of the EA program, but may not be the best way to affect cultural change and use of the EA in planning and decision-making. Involving stakeholders is the most important element in using EA to improve agency performance.