Home Resources White Papers

White Papers

Architecture-Driven Standard Software Solution Selection Methodology
The Method described in this paper defines a streamlined approach of using enterprise architecture to support standard software solutions selection.
ARIS for DoDAF
The DoD Architecture Framework defines a common approach for Department of Defense (DoD) architecture description development, presentation, and integration. This paper describes in detail how ARIS enables an integrated DoDAF architecture. It presents each DoDAF product description and shows an ARIS model type that can be used to represent the product.
What Are the Issues in Documenting, Managing, and Improving Business Processes?
The key benefits that enterprise business process documentation, management and improvement can deliver to an organization are presented. The critical role of senior executives and implications around tool selection are specifically emphasized.
Condition-Based Maintenance and the Product Improvement Process (Part I - Requirements)
Our hypothesis is that Condition Based Maintenance (CBM) and PLM integration is achievable through composite application design. To test this hypothesis, we design a composite application within the context of a Small Business Innovative Research (SBIR) project that is sponsored by the US government. This paper motivates the problem from the strategic level to the requirements definition level.
Comparison and Evaluation of Business Process Modeling & Management Tools
This paper compares and evaluates several business process modeling (BPM) tools against criteria which are critical to an enterprises’ business process optimization, and its adoption of emerging technologies and methodologies—including Enterprise Resource Planning (ERP) and Enterprise Architectures (EA). The evaluation criteria are applicable to the methodologies, standards, and network-centric work environments of modern enterprise business applications.
Enterprise Integration in Practice: The EII Data Integration Solution
This paper discusses what Data Integration is, the context as to why Data Integration is important, EII’s unique approach to Data Integration, and the critical prerequisites required to achieve Data Integration.
Defining and Documenting Standard Software Requirements: The EII/IDS Gap-Fit Methodology
A gap-fit analysis from a business process orientation provides an understanding of how the software would enable the end-to-end business, as opposed to comparing static functions within stovepipes. This paper presents an approach that has been used in several large organizations to provide a Business Process Oriented Gap-Fit Analysis. This is a more natural approach to gap-fit analysis, since the analysis is relative to the organization’s business processes, as opposed to functional stovepipes.
Enterprise Integration in Practice: The EII Management Integration Solution
Management Integration is a key component of the EII Solution Framework. The Solution Framework is focused on reducing the complexity, cost, and cycle times of enterprise transformation projects or other large-scale and complex endeavors. Our Management Integration solution complements the Process and Data Integration levels of our Solution Architecture Framework, and when all levels are focused on a particular implementation project, the benefits are significant. This paper complements other papers that we have written on the other Solution Framework levels by addressing all of the Management Integration methods that are critical to successful enterprise transformation projects. Our approach, which is enabled by our product implementation methodologies, ensures that projects meet senior management expectations for success.
Enterprise Integration, Inc. Problem and Solution Set
EII specializes in Enterprise Integration, a term that means different things to different people. We are often asked by our customers, precisely what do you mean by Enterprise Integration and what does it mean to provide Enterprise Integration solutions? We have found that the easiest way to answer this question it to describe the types of problems that we are often asked to solve and the solutions that we provide. Our solutions are enabled by technology, but our competitive advantage is in our ability to scope and solve problems from a business process prospective.
Enterprise Data Integration
To achieve true enterprise integration, EII developed a complete solution framework. This paper describes data integration as a key component of the EII Solution Framework.
Enterprise Integration in Practice: The EII Process Integration Solution
Process Integration is a key component of the EII Solution Framework. The Solution Framework is focused on reducing the complexity, cost, and cycle times of enterprise transformation projects or other large-scale and complex endeavors. Our Process Integration solution complements the Management and Data Integration levels of our Solution Architecture Framework, and when all levels are focused on a particular implementation project, the benefits are significant. This paper complements other papers that we have written on the other Solution Framework levels by addressing Process Integration methods that are critical to successful enterprise transformation projects. Our approach, which is enabled by our product implementation methodologies, ensures that projects meet senior management expectations for success.
Enterprise Services Oriented Architectures and End-to-End Business Process Execution
This paper describes our appraoch for delivering logistics capability from the Original Equipment Manufacturer (OEM) to the customer using using end-to-end solutions.The paper provides a review of the service-oriented concepts and how emerging methodologies,methods, and tools are used to support the implementation of composite applications, as well as the limitations or working in a mixed legacy/modern environment.
ERP Gap-Fit Analysis from a Business Process Orientation
A gap-fit analysis from a business process orientation provides an understanding of how the software would enable the end-to-end business, as opposed to comparing static functions within stovepipes. A description of the problem follows. This paper presents an approach that has been used in several large organizations to provide a Business Process Oriented Gap-Fit Analysis. This is a more natural approach to gap-fit analysis, since the analysis is relative to the organization’s business processes, as opposed to functional stovepipes.
Establishing Process Ownership by Aligning SAP and DoD Business Processes
This paper shows how the US Army can establish process ownership for Army core processes, while remaining consistent with SAP business process definitions. In short, we show how to map SAP processes to Army processes in the architecture, and establish business process ownership for both. The approach allows DoD executives to understand how DoD processes will be implemented in SAP, while simultaneously developing the cross-module scenarios that can be imposed on the implementation.
Federated Architectures
The concept of a Federated Solution Architecture has its origin in the cross-functional management literature where there exist the need to manage or monitor across organizational units. If cross-functional business processes are aligned, an alignment of information systems and data is also possible. The federated solution architecture approach is best for those organizations that do not have a fully centralized top-down approach to architectural planning, but maintain their architectures in individual organizational components.
Implementing SAP from End-to-End Business Process Scenarios
Business processes extend across functional and organizational boundaries. In this “real world,” supporting information systems must be implemented using an end-to-end viewpoint to ensure a true business process orientation. Recent technology developments now enable solution implementations that are aligned with business processes. This paper presents a methodology for implementing composite solutions that span the enterprise. Given a heterogeneous IT landscape composed of both SAP and non-SAP components, a generic order execution scenario is used to derive a company-specific reference model. The model is documented in the IT architecture where business objects are mapped into a composite solution. Commercial products that are used to illustrate the methodology include SAP NetWeaver and ARIS Process Performance Manager and modeling tools. An overview of the key components that are critical to the understanding of reference model approach is given.
Innovation and Transformation Using Product Lifecycle Management Enabled by Netweaver
We demonstrate how critical PLM components were designed for organizational innovation and business transformation using SAP NetWeaver technologies. Our main contribution is demonstrating the importance of designing integrated versus best-of-breed solutions when implementing complex solutions.
Interfaces for Enterprise Solutions
In virtually all sectors, management is seeking increased value from their organization’s business processes. Moving information through the enterprise (internally and externally), from person to person, in as little time as possible facilitates streamlining business processes and reducing costs. This minimal transfer time or zero-latency enterprise concept is a key driver for the current popularity of integrating disparate applications across the extended enterprise.
Product Lifecycle Management in Defense Organizations: Challenges and Opportunities
Product Lifecycle Management (PLM) presents many unique challenges in defense organizations. These challenges relate culture, organization, processes, data, and others. While some of these characteristics are not unique to defense organizations, some are specifically unique. This paper identifies and describes the challenges, and then presents an approach to requirements definition and solution design that addresses the described challenges. A closed-loop PLM model requires that the government take ownership of the product, post production, and assume every aspect of product support. This would include supply, procurement, maintenance, operations, engineering, configuration and fleet management functions.
Public Sector Enterprise System Implementation: Understanding Private Sector Differences
Much has been written about critical success factors (CSFs) for Enterprise System implementation success in the private sector. These CSFs are well known, and we have little to add to that discussion. Our focus is on CSFs for public sector enterprise software implementations, and our research concludes that there are differences. These differences are described in this paper, but we note the following. The private sector CSFs apply to the public sector as well, but there are additional factors that apply only to the public sector. The conclusion of our research is that public sector success is more difficult to achieve, and that government acquisition rules must be revised to align with the CSFs.
Relationship Between Business Process and Data in the SAP Standard Software Solution
This technical note uses a simple example to show the relationship between business process and data in the SAP solution. Business process functions are organized and managed inside SAP in a strict functional hierarchy. This hierarchy can be presented in the ARIS Business Architect at all levels, with SAP master data attached at the lowest. This removes ambiguity about data sources and allows data to be managed relative to the scope of SAP solution.
SALE Architecture Alignment
The key aspects of using architectural alignment to effectively capture the business processes and data requirements between two business domains to support Business Blueprinting Phase of an SAP Enterprise Resource Planning implementation are presented. The resulting requirements documentation is described and its added benefit of guiding the testing and training activities for system realization are addressed in specific.
Service-Oriented Concepts for Engineering Managers
It is impossible to discuss Service-oriented Architecture (SOA) without a common understanding of service-oriented concepts. This paper defines critical concepts that are necessary for engineering managers to make business decisions relative to SOA or SOA-related investments. Managers often have limited understanding of SOA, and for some reason, technologists seem to have difficulty explaining the concept using terminology and analogies that managers can understand. This paper addresses the long-standing communications gap between managers and technologists as they attempt to evaluate how SOA or SOA-related investments can add business value.
Solution Architecture Alignment for Logistics Portfolio Management
Architecture alignment is a key component of large-scale enterprise integration effort. To date, one of the largest logistics-oriented SAP implementation landscapes is in the process of being deployed by the US Army. Once fully deployed, the system is designed to streamline the entire US Army logistics value chain. Hence, along with the traditional systems and process requirements necessary to deploy an SAP solution, the Army must align with many non-SAP programmes and initiatives. To meet these goals, the concept of ‘architecture alignment’ becomes critical, for it provides a common enforcer of standards from which a high-level strategic and management oriented view of the eventual solution can be driven to the implementation level. This paper describes the process of aligning programmes and initiatives with solution architectures, along with the conceptual SALE (Single Army Logistics Enterprise) architecture model used to drive the alignment process.
Solution Architectures
Architectures may be used to manage the alignment of commercial software with organizations in the same way that a construction engineer would use a blueprint to mange and monitor the construction of a building. The blueprint, or construction architecture, acts as a standard for comparison used to manage, monitor, and test all construction activities in order to assure the design specifications have been met. Similarly, Solution Architectures can be applied to commercial enterprise software projects to manage, monitor, and test all implementation activities. Solution Architectures are necessary in order to reach reasonable assurance that the solution is acceptable.
Splitting the SAP Instance: Lessons on Scope and Business Processes
We investigate how SAP Blueprinting methodologies, driven by questionnaires and interviews can be misleading if cross-functional business processes and organizational alignment are not considered as part of the project scope. In the private sector, the implementing organization usually owns all of the business processes within its domain. In the public sector, this is not always the case, and leads to a split integration instance.. A “split instance” occurs when multiple standard software solutions are implemented in a domain that requires a single instance. Our research hypothesis is that the “split instance” problem is political, and driven by the desire of senior management to preserve organizational stovepipes. We test our hypothesis by performing an analysis of two US NAVY implementations: The Naval Air Systems Command and the Naval Supply Command. The only solution to the “split instance” problem is to realign the two solutions into a converged value chain that can be efficiently enabled by the SAP software.
The Evolution of SAP Implementation Environments: From Value SAP to Solution Manager
This paper describes the evolution of SAP implementation methodologies and tools. In particular, it describes Value SAP, with a focus on the Accelerated SAP (ASAP) implementation methodology and its evolution as a part of SAP’s new Solution Manager tool. The paper discusses some problems associated with the ASAP methodology when applied to complex enterprises, and also describes how some of these problems are addressed with the Solution Manager. The paper also describes how Solution Manager can be improved by combining it with the ARIS for MySAP methodology and associated ARIS Toolset.
The Navy ERP Architecture
This paper presents the design of the US Navy’s enterprise resource planning (ERP) architecture, which takes the as-configured baseline across multiple ERP projects, and transforms it into a converged to-be integrated solution. The result is an architecture-based instance consolidation that’s unique; for the Navy solution is the first architecture-driven instance consolidation.
The n-Tier Hub Technology
During 2001, the Enterprise Engineering Laboratory at George Mason University was contracted by the Boeing Company to develop an eHub capability for aerospace suppliers in Taiwan. In a laboratory environment, the core technology was designed, developed, and tested, and now a large first-tier aerospace supplier in Taiwan is commercializing the technology. The project objective was to provide layered network and application services for transporting XML-based business transaction flows across multi-tier, heterogeneous data processing environments. This paper documents the business scenario, the eHub application, and the network transport mechanisms that were used to build the n-tier hub. Contrary to most eHubs, this solution takes the point of view of suppliers, pushing data in accordance with supplier requirements; hence, enhancing the probability of supplier adoption. The unique contribution of this project is the development of an eHub that meets the needs of Small and Medium Enterprises (SMEs) and first-tier suppliers.
U.S. Army Logistics Process Automation Based on SAP NetWeaver Technology
The Army logistics system is a complex series of processes, organizations, doctrines, procedures, and automated systems. Historically, the system has been separated into two management levels: wholesale, which typically includes Army Materiel Command (AMC), Defense Logistics Agency (DLA), and the industrial base; and retail, which includes all customer organizations at theater and below. Doctrinally however, the system is segregated into three levels: strategic, operational, and tactical. In recent years, decisions have been made to enable these domains using commercial standard software whenever appropriate. This paper describes and architecural planning approach for desinging a standard software solution that combines the two management levels of Army logistics. [A version of this paper was published in Business Process Automation, A.-W. Scheer, et al. (Editors). Berlin: Springer-Verlag, 2004.]