This article discusses the implementation of the Japanese version of the Sarbanes-Oxley Act (J-SOX) that will occur in 2008 and the important role that enterprise architecture (EA) could play in that implementation. J-SOX enforcement will provide a compelling driver for information technology (IT) system replacements or upgrades that will have a big impact on the IT industry and might serve to establish a stronger EA presence in Japan. However, the successful use of EA methods requires fundamental changes in how executives and managers think about the enterprise, and as such this represents a significant change in corporate culture and governance that will not happen by itself. J-SOX compliance could be the driving force to facilitate EA’s use in Japan because enterprises will need to simultaneously transition to enterprise-level thinking and increase their agility to keep up with changing business requirements and comply with J-SOX.
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.
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.