Article

{{post_terms.hashtags}}

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.

A Principles-Based Enterprise Architecture Framework

The increasing importance of Enterprise Architecture is driven by requirements for seamless inter-operation between business, rapidly changing market, and ever-changing information and systems technologies. Enterprise architecture defines the overall design structure of the business and the information and technical infrastructure that supports the business, based on defined principles and models that guide the planning and designing, building and operating the enterprise and its strategic choices. This article highlights the importance of a principles-based enterprise architecture framework as a design imperative for business service groups, information management teams, and application and technology solution groups; as as a foundation for achieving interoperability, integration, and alignment of an organization’s systems (business, information, technology) across an enterprise.

Enterprise Architecture as a Context for ERP Implementation

This article examines how Enterprise Architecture (EA) can provide the planning, documentation, and standards context for the implementation of Enterprise Resource Planning (ERP) systems. This article also serves to establish a foundation for further research and discussion on the relationship between EA and ERP systems. ERP systems implementations can include the simultaneous or sequential introduction of new or upgraded applications software in a number of functional areas across an enterprise. EA integrates strategic, business, and technology planning across the enterprise, as well as providing standards and configuration management capabilities that support the ongoing transition from current to future architectures. In that EA documents and links an enterprise’s strategic goals, business processes, and technology solutions, ERP applications are part of EA. The authors argue that the selection and implementation of ERP applications should therefore be based on the strategic priorities, business requirements, and technology standards that the EA documents. EA can help to lower the risk of ERP implementation failure by providing a clear view of current and future technology operating environments and ways in which the ERP application can (or cannot) help to meet strategic goals and business requirements. Therefore, ERP implementations should be done in the context of EA during, and after the implementation to identify obstacles to success, the impact on existing processes and resources, and most importantly, to document lessons learned, which will promote the success of future initiatives.

Service Oriented Architectures: The State of Play in Australia

The notion of Service Oriented Architectures (SOA) has received considerable attention in the commercial literature over the past two years, but a consistent definition of what an SOA really is, and what it does, has yet to emerge, and almost no empirical research has been conducted to find out what SOAs means to the IT practitioners charged with implementing them in businesses and government organizations. This study attempts to address this gap by reporting on the results a qualitative research study conducted to ascertain what service-oriented architectures meant in practice to the IT practitioners working on them in 23 large Australian organizations. The findings are then used to draw some conclusions on how SOAs can be expected to evolve in the organizations in the future.

CMM-Based EA: Achieving the Next Level of Enterprise Architecture Capacity and Performance

Typically, organizations start their enterprise architecture (EA) journey using non-integrated point-applications including documents, spreadsheets, and databases. While this approach to EA is initially easy and convenient, it inevitably leads to continuous reconciliation, the inefficient use of scarce resources, and eventual frustration. This is because point application tools lack the power to maintain the consistency of multiple EA models across EA teams and organizations. As a result, accurate cross-enterprise EA analyses are typically time and resource intensive, or are impossible to effectively perform. Moving from point tools EA to the capabilities of Capability Maturity Model (CMM)-based EA is more than a simple technology issue. The purpose of this article is to help organizations understand the potential benefits and dimensions required to implement CMM-based EA effectively. CMM-based EA is flexible enough that it can be successfully applied to the civilian and defense government programs.