Acquisitions Editor: Development Editor: Senior Managing Editor: Managing Editor: Assistant Managing Editor: Copy Editor: Typesetter:

Cover Design: Printed at:

Kristin Klinger Kristin Roth Jennifer Neidig Sara Reed Sharon Berger Larissa Vinci Jamie Snavely Lisa Tosheff Yurchak Printing Inc.

Published in the United States of America by Information Science Reference (an imprint of Idea Group Inc.) 701 E. Chocolate Avenue, Suite 200 Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: [email protected] Web site: http://www.info-sci-ref.com and in the United Kingdom by Information Science Reference (an imprint of Idea Group Inc.) 3 Henrietta Street Covent Garden London WC2E 8LU Tel: 44 20 7240 0856 Fax: 44 20 7379 0609 Web site: http://www.eurospanonline.com Copyright 2007 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or companies does not indicate a claim of ownership by IGI of the trademark or registered trademark. Library of Congress Cataloging-in-Publication Data Enterprise systems architecture in practice / Pallab Saha, editor. p. cm. Summary: This book is a valuable addition to the reading list of executives, managers, and staff in business, government, and other sectors who seek to keep their enterprises agile and efficient as they manage change, implement new business processes and supporting technologies, and pursue important strategic goals--Provided by publisher. Includes bibliographical references and index. ISBN 978-1-59904-189-6 (hardcover) -- ISBN 978--59904-191-9 (ebook) 1. ManagementData processing. 2. Business enterprisesCommunication systemsManagement. 3. Computer architecture. 4. Management information systems. I. Saha, Pallab, 1970HD30.2.E58 2007 658.4038011--dc22 2006033766 British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book set is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher.

Table of Contents

Detailed Table of Contents ................................................................................................................. vi Foreword .............................................................................................................................................. xv Preface ................................................................................................................................................. xx Acknowledgments ............................................................................................................................ xxv

Section I Frameworks and Methodologies Chapter I A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000) / Pallab Saha .................................................................................. 1 Chapter II Extreme Architecture Framework: A Minimalist Framework for Modern Times / Phil Robinson and Floris Gout ......................................................................................................... 18 Chapter III Discovering and Modelling Enterprise Engineering Project Processes / Ovidiu Noran .................................................................................................................................... 39 Chapter IV Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises / Tae-Young Kim, Sunjae Lee, Jeong-Soo Lee, Kwangsoo Kim, and Cheol-Han Kim ........................ 62 Chapter V Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures / Steven J. Ring and Dave Nicholson ..................................................................... 85 Chapter VI Business Process Modeling as a Blueprint for Enterprise Architecture / Joseph Barjis and Isaac Barjis ....................................................................................................... 114 Chapter VII Enterprise Architecture in the Singapore Government / Tan Eng Pheng and Gan Wei Boon ............ 129

Section II Governance and Management Chapter VIII Understanding and Communicating with Enterprise Architecture Users / Steven Thornton.............. 145 Chapter IX Improving Stakeholder Communications and IT Engagement: A Case Study Perspective / Gail L. Verley ......................................................................................... 160 Chapter X The Role of Change Management in IT Systems Implementation / Ron S. Kenett and Sebastiano Lombardo....................................................................................... 172 Chapter XI Managing Enterprise Architecture Change / Tim ONeill, Mark Denford, John Leaney, and Kyle Dunsire ..................................................................................................... 192

Section III Transformation and Value Realization Chapter XII Architecture-Driven Business Transformation / Chris Lawrence....................................................... 207 Chapter XIII Maturity of IT-Business Alignment: An Assessment Tool / Nel Wognum and Fan Ip-Shing ............. 221 Chapter XIV The Integrated Enterprise Life Cycle: Enterprise Architecture, Investment Management, and System Development / Frank J. Armour, Chris Emery, Jonathan Houk, Stephen H. Kaisler, and John S. Kirk..................... 237 Chapter XV Promoting Netcentricity through the Use of Enterprise Architecture / Supriya Ghosh ...................... 253

Section IV Implementation and Deployment Chapter XVI Enterprise Architecture as an Enabler for E-Governance: An Indian Perspective / Raghunath Mahapatra and Sinnakkrishnan Perumal ................................................................... 272

Chapter XVII Federated Enterprise Resource Planning Systems / Nico Brehm, Daniel Lbke, and Jorge Marx Gmez ..................................................................... 290 Chapter XVIII A Network-Based View of Enterprise Architecture / Bala Iyer, David Dreyfus, and Per Gyllstrom ................................................................................ 306 Chapter XIX Enterprise Architecture by a Small Unit in a Federated Organization / Roger Sliva .......................... 320 Chapter XX The Syngenta Architecture Story / Peter Hungerford ........................................................................ 331 Chapter XXI The Use of GERAM for Design of a Virtual Enterprise for a Ship Maintenance Consortium / John Mo ................................................................................................... 351 Chapter XXII Information Systems Architecture for Business Process Modeling / Michel Spadoni and Anis Abdmouleh ............................................................................................ 366

Section V Technology and Service-Oriented Architecture Chapter XXIII Enterprise Architecture within the Service-Oriented Enterprise / Scott J. Dowell ............................. 382 Chapter XXIV A Fundamental SOA Approach to Rebuilding Enterprise Architecture for a Local Government after a Disaster / Zachary B. Wheeler ............................................................................ 400 Chapter XXV Business Networking with Web Services: Supporting the Full Life Cycle of Business Collaborations / Diogo R. Ferreira ............................... 419 Chapter XXVI Enterprise Integration Architecture for Harmonized Messaging / Dat C. Ma, Belinda M. Carter, Shazia W. Sadiq, and Maria E. Orlowska .................................... 434

About the Authors ............................................................................................................................ 455 Index ................................................................................................................................................... 466

Detailed Table of Contents

Foreword ............................................................................................................................................. xv Preface ................................................................................................................................................. xx Acknowledgments ............................................................................................................................ xxv

Section I Frameworks and Methodologies Chapter I A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000) / Pallab Saha .............................................................. 1 The federal enterprise architecture framework (FEAF) is perhaps the most adopted EA framework, especially within the U.S. Government agencies. Either FEAF has been adopted as-is or other frameworks derived from FEAF have been used. FEAF today continues to be the most comprehensive framework available for guidance by agencies. It consists of a full-fledged methodology, several reference models, target architectures, and even a toolkit that facilitates adoption across all agencies. Chapter I evaluates synergies between the comprehensive FEAF against the Generalized Enterprise Reference Architecture and Methodology (GERAM) framework. The chapter discusses the level of completeness in the FEAF based on GERAM requirements and additionally areas where the FEAF goes well beyond GERAM requirements. Chapter II Extreme Architecture Framework: A Minimalist Framework for Modern Times / Phil Robinson and Floris Gout ......................................................................................................... 18 Enterprise architecture is a non-trivial initiative. Organizations usually face difficulty in understanding which of the organization elements they need to be aware of and which of them would be relevant to CIOs and IT managers. Chapter II presents an EA framework that is lightweight and selective to meet

the needs of the organization. The chapter uses the agile approach to develop architectural artifacts. It starts with the need for frameworks and some of the currently popular frameworks. Then it argues why interoperability both at systems and human level is critical followed by a discussion on the relevant architectural views that is derived from the XAF matrix and elements that need to be created. The chapter concludes with a comparison of the proposed framework with other established frameworks from the point of view of simplicity and ease of use. Chapter III Discovering and Modelling Enterprise Engineering Project Processes / Ovidiu Noran .................................................................................................................................... 39 Organizations are usually unclear about the activities and deliverables of an EA program. This situation is further exacerbated by the fact that some of the more popular and emerging architecture frameworks tend to be proprietary. There are open frameworks that often provide a long list of artifacts that are required as part of EA, but do not make any mention under what circumstances, which artifacts are relevant. Chapter III provides a meta-methodology based on existing architecture frameworks that facilitates organizations assess and select architectural elements and artifacts within the context of specific EA program requirements. The proposed approach in the chapter allows organizations to configure their EA programme, instead of doing the whole nine yards for every situation. The chapter illustrates the proposed approach with a real-life case study. Chapter IV Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises / Tae-Young Kim, Sunjae Lee, Jeong-Soo Lee, Kwangsoo Kim, and Cheol-Han Kim ........................ 62 With the intent of being more competitive and agile, organizations are now collaborating at the level of value chains. This entails end-to-end business processes that span multiple organizations. This move toward a new operating model is giving rise to the concept of virtual enterprises (VE). Given the absence of any current architecture methodology, Chapter IV presents a modeling framework that business architects and domain specialists can use to build and configure architectural elements and models specifically for VEs. The chapter uses and improves upon existing modeling standards and practices (like BPMN, UML, MDA) and applies concepts of service-oriented architecture (SOA) to make organizations more responsive to change.

Chapter V Activity-Based Methodolgy for Development and Analysis of Integrated DoD Architectures / Steven J. Ring and Dave Nicholson ..................................................................... 85 The Department of Defense Architecture Framework (DODAF) provides guidelines to DOD commands, services, and agencies in developing their EA both for war fighting operations and business processes. The DODAF is a structured approach that defines architecture views, perspectives, artifacts, reference models, and deliverables. Chapter V presents the DOD defined methodology that uses DODAF to create architecture outputs. Activity-based methodology (ABM) discussed in this chapter is presented as a

step-by-step approach that allows a common reference point for all architectural assets in terms of scope, breadth, depth, and intensity. Several DOD entities have adopted or are in the process of adopting ABM, thereby providing credence to its applicability in practice. Chapter VI Business Process Modeling as a Blueprint for Enterprise Architecture / Joseph Barjis and Isaac Barjis ....................................................................................................... 114 Business architecture is a key component of EA and without doubt drives the rest of the sub-architectures. Target business architecture definition typically consists of target outcomes (i.e., business metrics representing the ends) and target business processes (i.e., representing the means). Thus, process modeling is a critical activity in developing business architecture. Chapter VI presents a Petri-net based methodology, transaction-oriented Petri-nets (TOP) to enterprise process modeling. The chapter starts with a brief background of existing architecture frameworks and discusses the role of business architecture. Then it presents the details of the TOP notation, following which the complete TOP methodology framework is discussed in a step-by-step manner, with examples provided to illustrate each step and their respective output. Chapter VII Enterprise Architecture in the Singapore Government / Tan Eng Pheng and Gan Wei Boon ............ 129 In almost all countries, government is the biggest organization. This is associated with multiplicity of factors that add to the complexity of the operations of any government. Singapore has traditionally ranked very high on e-government readiness and usually within the global top 5. Chapter VII is a discussion of the role of enterprise architecture in the Singapores e-government programmes. The chapter discusses the evolution of the countrys e-government action plans and policies and examines the linkages and roles that EA plays including IT governance and investment planning. The chapter briefly presents the currently ongoing efforts within the government to define reference models that are intended for use by agencies to develop their own EA in alignment with the overall government-wide EA. Within the current e-government plan, the iGOV 2010, EA is one the three key pillars of programme success.

Section II Governance and Management Chapter VIII Understanding and Communicating with Enterprise Architecture Users / Steven Thornton.............. 145 One of the critical success factors in EA programmes is the need to disseminate the EA blueprint within the enterprise. Often EA blueprints are defined and developed by corporate IT departments, but the same is not adequately communicated to the rest of the organization. This creates problems in governing the architecture with the individual locations and business units typically failing to appreciate the need for an organization-wide EA and the need to comply with the same. Chapter VIII discusses current best practices and provides guidelines in communicating EA to the users. The recommended approaches

and practices presented in the chapter are derived from the United States National Institutes of Health (NIH) EA programmes. The intent of this chapter is to educate CIOs and chief architects about the need to communicate EA, recommended approaches, and its key benefits to the EA programme. Chapter IX Improving Stakeholder Communications and IT Engagement: A Case Study Perspective / Gail L. Verley ......................................................................................... 160 Chapter IX continues on the theme of architecture governance and management. This chapter begins with a discussion on the need to improve stakeholder communications and enhance engagement with the users in an EA programme. The chapter presents five steps to involve stakeholders in EA programmes, followed by ten strategies and mechanisms to institutionalize stakeholder involvement. The application of the steps, strategies, and mechanisms presented in the chapter are illustrated through a detailed case study of United States Federal Deposit Insurance Corporation (FDIC). The chapter concludes with a set of lessons learned that organizations can refer to. Chapter X The Role of Change Mangement in IT Systems Implementation / Ron S. Kenett and Sebastiano Lombardo....................................................................................... 172 Often IT systems implementations fail to adequately account for transition management. Given the fact that enterprise systems inevitably lead to redesign and digitization of business processes and associated business rules, it has the capability to trigger large-scale organizational change. As a result, IT implementation programmes must incorporate transition management as a key activity often as a critical success factor. Chapter X presents an integrated holistic approach to IT systems implementation called the better enterprise systems implementation (BEST). The chapter treats IT systems implementation as an organizational development issue and positions the BEST methodology as an approach to manage IT driven organizational change. The chapter then illustrates the application of the methodology through three case studies in Norway and Israel. Chapter XI Managing Enterprise Architecture Change / Tim ONeill, Mark Denford, John Leaney, and Kyle Dunsire ..................................................................................................... 192 Chapter XI is a description of an approach that allows organizations to simulate, predict, and control the emergent properties of enterprise systems from an architectural perspective. The chapter argues that existing methodologies and toolsets are by nature bottom-up and often fail to take into consideration the non-functional requirements of the IT systems from an architectural viewpoint. The chapter begins with a brief discussion of the key non-functional requirements that most IT systems are expected to fulfill. It then presents a five-step methodology that organizations can use to build and evolve their architectures. The chapter concludes with the benefits of the proposed methodology.

Section III Transformation and Value Realization Chapter XII Architecture-Driven Business Transformation / Chris Lawrence....................................................... 207 Chapter XII presents an approach where EA is viewed as a business issue. The chapter starts with a discussion on business transformation that is triggered through EA. The chapter argues that EA is an imperative irrespective of the business condition that an organization might be in and places forth business diagnostics as a key element of any architectural initiative. The chapter illustrates the application of the proposed approach in a financial services organization and discusses business process driven business transformation. The chapter then concludes with a discussion on non-process driven business transformation and why process architecture-based transformation was used as an example. Chapter XIII Maturity of IT-Business Alignment: An Assessment Tool / Nel Wognum and Fan Ip-Shing ............. 221 Most large IT system implementation initiatives are plagued by several factors that often make implementations less than desirable. While factors leading to failure for large IT implementations have been documented and analyzed, the intriguing issue is that organizations seem to repeat the same mistakes over and over again. This necessitates the need for a mechanism that allows planners and managers to evaluate the start-up situation in such projects, including capturing the project dynamics in a coherent manner. Chapter XIII presents such an approach based on better enterprise systems implementation (BEST). In doing this, the two key questions addressed are what problems can be pre-empted and what can be done about them. The chapter then continues to illustrate the proposed approach through several mini-cases derived out of real-life scenarios. The chapter concludes with a discussion on areas for further research. Chapter XIV The Integrated Enterprise Life Cycle: Enterprise Architecture, Investment Management, and System Development / Frank J. Armour, Chris Emery, Jonathan Houk, Stephen H. Kaisler, and John S. Kirk............... 237 Organizations typically tend to consider and implement EA in isolation. However, in reality, EA has the capability to impact several other activities within the enterprise. Chapter XIV explores and discusses the linkages that EA has with IT investment management and system development processes and hence the need for a holistic approach. In doing so, it proposes an integrated enterprise lifecycle (IELC). The chapter starts with a discussion of the IELC and its various components. The chapter positions IELC as a key IT governance mechanism and presents several governance archetypes that are part of the IELC. It concludes with a brief discussion on the proposed move towards IELC by the U.S. Office of Management and Budget (OMB) and U.S. General Accounting Office (GAO) under the Federal Enterprise Architecture (FEA) program.

Chapter XV Promoting Netcentricity through the Use of Enterprise Architecture / Supriya Ghosh ...................... 253 Chapter XV presents U.S. Department of Defense (DOD)s goal of net-centric transformation as an implementation of EA. The chapter argues that to achieve net-centricity, the existence of an integrated architecture provided by the DOD global information Grid (GIG) is a key imperative. The chapter then provides an overview of the key performance parameters to support net readiness (NR-KPP). It details the adoption of net-centric transformation through the use of net-centric data strategy, net-centric IA strategy, service-oriented architecture (SOA), and communications transport strategy. The chapter concludes with a discussion on upcoming and future trends to enable DODs move towards net-centricity.

Section IV Implementation and Deployment Chapter XVI Enterprise Architecture as a Enabler for E-Governance: An Indian Perspective / Raghunath Mahapatra and Sinnakkrishnan Perumal ................................................................... 272 Chapter XVI is a case study on application of EA to develop an efficient and effective e-governance system for citizen services administration by the Government of India. The chapter starts with a background on various e-government initiatives, including a brief discussion on the administrative structure in India. The chapter then puts forth key imperatives that are required for successful e-government programs keeping in mind the Indian context. EA is then presented as one the critical success factors. The chapter continues with a detailed discussion of a proposed framework (derived from the Zachman framework) that facilitates the application of EA in the context of e-government in India. The chapter concludes with a mapping of the earlier presented imperatives to the key elements of the proposed framework. Chapter XVII Federated Enterprise Resource Planning Systems / Nico Brehm, Daniel Lbke, and Jorge Marx Gmez ..................................................................... 290 Chapter XVII presents enterprise resource planning (ERP) system architecture that makes individual business modules reusable through the use of Web services-based shared and non-monolithic architecture. The chapter is based on a practical challenge that enterprises currently face, wherein systems (especially the ERP tools) have proprietary data models, thus limiting their usage and in conflict to their claim of being positioned as enterprise systems. This leads to vendor lock-in. The chapter begins with a background on existing ERP systems with a discussion of their limitations as real enterprise systems. The chapter then presents the federated ERP system approach and discusses how the federated approach addresses the shortcomings of existing siloed ERP systems. The chapter concludes with a discussion on the kind of adoption challenges that the federated approach might face along with a short brief on future trends and research.

Chapter XVIII A Network-Based View of Enterprise Architecture / Bala Iyer, David Dreyfus, and Per Gyllstrom ................................................................................ 306 This chapter moves away from the traditional four sub-architecture-based view of EA and takes a networkbased view that is based on understanding and capturing the dependencies between the elements of the EA. The proposed approach asserts that such dependencies are a factor of time and typically emerge as the architecture evolves. Dependencies that emerge during the design, deployment, and operations of the EA are based on both technical and social factors. The chapter presents a case study of the application of the proposed approach in a financial services company. The chapter concludes with a discussion of the limitations of the proposed approach and presents pointers to how the limitations can be addressed. Chapter XIX Enterprise Architecture by a Small Unit in a Federated Organization / Roger Sliva .......................... 320 Typically, EA programmes tend to consist of large teams that develop and implement the target architecture for a single organization or company. Chapter XIX presents experiences and best practices in developing EA by a small team for a federated organization. A federated structure is typical in many governments where the administrative structure is organized into national/federal entities followed by states, districts, or provinces. Given the federated structure, developing EA presents several practical challenges. The chapter discusses factors to be considered in such a scenario when developing EA in terms of scope, intensity, use of tools, open standards, shared business services and programme governance. Chapter XX The Syngenta Architecture Story / Peter Hungerford ........................................................................ 331 Chapter XX presents the experiences of development and evolution of EA at Syngenta. The key drivers in Syngentas architecture programme are business efficiency, growth, and innovation. The chapter shares the experiences and insights from several business areas. The case studies presented in the chapter include EA initiatives like server rationalization and development of global infrastructure services, integrated go-to-market platform, providing an unified research platform, and building an enterprisewide business intelligence. The chapter then presents a simple framework for EA and discusses the case studies in the context of the framework. The chapter concludes with future trends and discusses a few plausible areas of research. Chapter XXI The Use of GERAM for Design of a Virtual Enterprise for a Ship Maintenance Consortium / John Mo ................................................................................................... 351 Chapter XXI describes the application of the generalized enterprise reference architecture and methodology (GERAM) in analyzing the ANZAC ship alliance (ASA). The chapter discusses the details of the use of GERA in developing and studying a virtual enterprise, especially issues relating to logistics and information architecture management needed to support the operations of ASA as a virtual enterprise. The chapter starts with a brief overview of the GERAM including the key reasons of why it was selected

for use. The chapter then describes ASA as a virtual enterprise including the peculiarities and nuances of a virtual enterprise. The chapter concludes with a description of enterprise engineering programme at ASA, the artifacts, and models developed based on GERAM requirements. Chapter XXII Information Systems Architecture for Business Process Modeling / Michel Spadoni and Anis Abdmouleh ............................................................................................ 366 Chapter XXII is a description of business process modeling capabilities within the CIMOSA application server (CAS). The CAS is an information system for enterprise modeling and designing. The chapter starts with a brief overview of the problems that are faced by organizations in integrating their disparate systems. Then it describes the CAS project, its goals and objectives, and the primary reason for selecting CIMOSA as the reference architecture. Following this, the chapter describes the CIMOSA modeling framework and conceptual model. The chapter then describes the business process modeling aspects with an example of a manufacturing organization including the views and artifacts needed to support the requirements of enterprise systems. . Chapter XXIII Enterprise Architecture within the Service-Oriented Enterprise / Scott J. Dowell ............................. 382 Chapter XXIII elaborates the role of EA in a service-oriented enterprise (SOE). Driven by the need to be adaptable, agile, and responsive to change, organizations are now adopting the SOE paradigm where organizations view themselves as a bundle of services that are available for use through technology enablement. The chapter begins with the issues that enterprise architects need to grapple with, namely, business services, service-oriented solutions, infrastructure services, and IT organization changes. It goes on to compare a traditional enterprise with a SOE. The chapter then discusses the development of strategy in a SOE and its peculiarities. The chapter provides real-life examples on various aspects of service orientation adopted by various organizations. Chapter XXIV A Fundamental SOA Approach to Rebuilding Enterprise Architecture for a Local Government after a Disaster / Zachary B. Wheeler ............................................................................ 400 Chapter XXIV is a case study of the re-establishment of EA for the local government following Hurricane Katrina in Louisiana. The chapter presents an approach to address areas in EA that have not received much attention as part of preparedness, response, and recovery phases. The chapter proposes the use of service-oriented architecture (SOA) paradigm to address some of the key issues. The chapter starts with a brief background of the underlying EA framework that was used in the given situation, followed by a detailed description of the conceptual data model and how a critical portion of the EA was developed. The chapter concludes with a discussion on other technologies that can be used to extend the current solution.

Chapter XXV Business Networking with Web Services: Supporting the Full Life Cycle of Business Collaborations / Diogo R. Ferreira ............................... 419 Integration technologies to support and enable business-to-business collaborations have been around for some time now. However, all existing approaches overly focus on the operational transaction portion of the overall collaboration mechanism. Chapter XXV proposes to use the Web services paradigm as a way to deal with all aspects of business collaborations. The chapter starts with an overview of Web services as an integration platform, followed by a description of the criticality of the life cycle approach in integration. The chapter demonstrates with examples the use of Web services in extending its support of operational aspects alone to the full life cycle of business collaborations, thereby enabling seamless e-business collaborations and trading. Chapter XXVI Enterprise Integration Architecture for Harmonized Messaging / Dat Cao Ma, Belinda Carter, Shazia W. Sadiq, and Maria E. Orlowska ...................................... 434 Most organizations are now characterized by end-to-end cross enterprise business processes that aim to enable value chain integration. Although organizations recognize the need for integration both at the business process and at the system level, very few utilize formal approaches in designing and implementing business rules that are needed to govern cross-enterprise processes. The criticality of the managing business rules in cross enterprise business processes is further driven by the fact that business partners tend to have their own agendas and goals in partnering. Chapter XXVI presents a rule-based enterprise integration approach enabled through messaging technology. The chapter begins with the challenges of large-scale collaborative systems and the evolution of technology solutions to address some of the challenges. The chapter then presents the proposed enterprise integration architecture and an overview of related technologies. Following this, the chapter elaborates the steps in rule design, validation, and deployment and its adoption within the proposed integration architecture. The chapter concludes with a discussion on future developments in the proposed area.

About the Authors ............................................................................................................................ 455 Index ................................................................................................................................................... 466

xv

Foreword

Historically, enterprise architecture has been a non-issue because in the industrial age, it was the industrial products that were growing in complexity and changing and the concept of the enterprise was relatively simple: create a good product and then find a lot of people to sell it to. As we approximate the realities of information age, major changes are taking place in the global marketplace. It is the enterprise that is growing in complexity and the enterprise that is changing. No longer is business as simple as get yourself a good product and then find a lot of customers to sell it to. That is, historically, from the perspective of the enterprise, the market (the customers) is integrated. Increasingly, the concept is, find yourself a good customer and then you (the enterprise) identify the range of products (or services) required to keep that customer a good customer. That is, from the perspective of the customer, the product and/or the enterprise must be integrated to the customers requirement. If the enterprise has to treat each customer as a unique requirement and customize every product or service of the enterprise to the perspective of each customer, it will drive the complexity of the enterprise out of sight and I would suggest that this information age characteristic is quite independent of whether it is the enterprise or the enterprises product or whether the enterprise is public sector or private sector or how big or small the enterprise is. Integration is where the complexity lies. Increasingly, all the parts of the enterprise have to be engineered to fit together to the specification of the customer enterprise-wide. Furthermore, to create complex industrial products that are economically viable, as many parts as possible must be engineered as standard, interchangeable parts, reusable, or normalized. That is, in the information age, the enterprise is going to have to be engineered such that all of the parts fit together enterprise-wide and that everything possible is engineered to be standard and interchangeable (reusable) and that, in order to be lean, no concept should recur, (everything (not only the data) will have to be normalized). A second characteristic of the changing global marketplace is dramatic escalation of the rate of change. The way that dramatic escalation of the rate of change affects products (or enterprises) is in reducing the time-to-market, that is, reducing the time it takes from the point in time an order is placed for a new product until a finished good is produced, in the case of enterprises until a new enterprise-wide, integrated, implemented enterprise, is produced. The information age customer demand is for custom products (integrated to the specification of the customer requirement), mass-produced in quantities of one for immediate delivery, that is, a time-to-market of virtually zero. You might recognize this as the present definition of mass-customization. In short, the known characteristics of the information age are extreme complexity and dramatic escalation of the rate of change. There is a plethora of business and academic literature that argues this case. A survey of 7,000 years of history of human kind would conclude that the only known strategy for accommodating extreme complexity and high rates of change is architecture. If you cant describe something, you cant create it, whether it is an airplane, a hundred storey building, a computer, an automobile or an enterprise. Once you get a complex product created and you want to change it, the basis for change is its descriptive representations. I would suggest that architecture is the total set of descrip-

xvi

tive representations relevant for describing something, anything complex you want to create, which serves as the baseline for change if you ever want to change the thing you have created. You dont need architecture if you want to create a simple object. For example, if all you want is a log cabin, chop down trees and build a log cabin. You dont need architecture. You can see and understand everything all at the same time. On the other hand, if you want a hundred storey building, you cannot see and understand everything all at the same time and you are going to have to have architecture and the architectural representations will be the basis for changing it once it is built. If you want to reduce the time-to-market for creating a complex product, you could engineer the parts, prefabricate them, have them in inventory long before you ever get the order. Then you could reduce the time to market to just the time it takes to assemble the product. If you cleverly engineered the parts such that they could be assembled into more than one finished good, you could build a virtually infinite number of custom finished goods from the same set of prefabricated parts. In other words, you could manufacture custom products, massproduced in quantities of one for immediate delivery. I might observe that although there is no manufacturer that has completely perfected the concepts of mass-customization, the Japanese taught the western manufactures a lot of hard lessons in the last 25 or 30 years and anymore, to get into or stay in a complex industrial product manufacturing business, mass-customization is fundamental and integral to survival. Clearly, my argument is, we will have to apply the same kind of concepts to the enterprise in the information age that we have applied to the industrial products of the industrial age. We will have to produce different, custom manifestations (or implementations) of the enterprise, enterprise-wide, on demand. By mixing the metaphor (industrial products and enterprises), I have tried to encapsulate in a few short paragraphs the underlying argument for enterprise architecture. In the information age, I am quite certain that the question to the enterprise is, how do you intend to deal with extreme complexity and dramatic escalation of the rate of change? I would submit, if the enterprise does not have an enterprise architecture strategy, they are neither going to accommodate extreme complexity nor the escalating rate of change and therefore, I would suggest, it is questionable whether they are going to be able to exist. My opinion is enterprise architecture is the most profound, significant, issue of the information age. The next question is, what is enterprise architecture, what does it look like? We know what architecture is for airplanes. We know what architecture is for buildings. We know what architecture is for computers. We know what architecture is for industrial products because in the industrial age, it was the industrial product that was increasing in complexity and changing. If we hadnt figured out what architecture is for industrial products, we would not have Boeing 747s (airplanes), hundred storey buildings, computers, ocean liners, or Acura Legends (automobiles). We would not have complex industrial products. An observation of architecture for industrial products shows that architecture is architecture is architecture. All industrial products have bills-of-materials. They all have functional specs, they all have drawings, they all of operating instructions, they all have timing diagrams, and they all have engineering design objectives. Each of these sets of descriptions is completely different and varies independently from one another. However, they are all related to one another. Generically, they describe WHAT the product is made of, HOW the product works, WHERE the components are located, WHO is responsible for operation, WHEN do things happen, and WHY do they happen. This classification of descriptive representations has been employed by humanity for thousands of years. It is universal. There is another dimension of classification of descriptions that have to do with the audiences for which the descriptions are prepared and employed. Very complex products will have some scoping or bounding expression for the originators. They all have concept definitions (requirements) for the end owners. They all have logic representations (schematics) for the designers. They all have technology constructs (blueprints) for the builders. They all have production tool configurations for the implementers. These two classifications for descriptive representations are orthogonal and constitute a structured order or schema for descriptions, that is, a framework for architecture, which classifies and defines the set of descriptive representations for anything.

xvii

I spent something over 40 years of my professional life trying to find an answer to the question, What does architecture look like for enterprises? If I have done anything of any value, my contribution has been in the form of a framework, a framework for enterprise architecture, which simply puts some definition around the set of descriptive representations that are relevant for describing enterprises. Anyone who has followed my work would recognize my framework in the previous description of the architecture schema. I simply put enterprise names on the same engineering design artifacts that constitute architecture for industrial products. In 2006, the time of writing this foreword, we do not have experience with producing all of the descriptions (models) for an enterprise that are prescribed by this framework, in fact, we dont even have formalisms for many of them. There is a lot of room for creativity, research and development, and collaboration. Which brings me to Pallab Sahas book this is a very timely and important book. Pallab Saha has assembled substantive discussions about all of the known architecture-related subjects of which we are aware at the moment. The subjects are wide and varied and clearly, there is a lot of creativity and work that needs to be done. I do not think that we will have several hundred years to accumulate experience, develop formalisms, and do all the architectural instantiations that will be required to operate enterprises in the information age. In fact, we may only have several decades to make major progress because at the point in time that the enterprise finds itself in extremis, unable to accommodate any more complexity and unable to cope with the escalating rate of change, that is, at the point in time the enterprise discovers it is imperative to have enterprise architecture to survive, it is going to be to late to start working on it. Pallabs book is timely because tomorrow morning is not too early to start working on enterprise architecture! I hope Pallab Saha starts working on the next book immediately. The next book must integrate and normalize all the subjects of the first book. He would likely find my framework for enterprise architecture helpful if he actually undertook this next endeavor. However, the present book is a good place to start. It is a book that not only systems people should read, but enterprise business people should read as well. In fact, I hope in my brief foreword, I have sufficiently argued that enterprise architecture is an ENTERPRISE issue, not simply a systems issue. Maybe, by the time the next book is ready for publication, the urgency of complexity and change will be so apparent to the business world, they will be more prepared to read it. John A. Zachman Glendale, California 2006
John A. Zachman is the originator of the Framework for Enterprise Architecture, which has received broad acceptance around the world as an integrative framework, or periodic table of descriptive representations for enterprises. Dr. Zachman is not only known for his work on this book, but is also known for his early contributions to IBMs information strategy methodology (business systems planning) as well as to their executive team planning techniques (intensive planning). Dr. Zachman retired from IBM in 1990, having served them for 26 years. He is chief executive officer of the Zachman Institute for Framework Advancement (ZIFA), an organization dedicated to advancing the conceptual and implementation states of the art in enterprise architecture. Dr. Zachman serves on the executive council for information management and technology of the United States General Accounting Office. He is a fellow for the College of Business Administration of the University of North Texas. He serves on the advisory board for the Data Resource Management Program at the University of Washington and on the advisory board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2004 Oakland University, Applied Technology in Business (ATIB), and the Award for IS Excellence and Innovation. Dr. Zachman has been focusing on enterprise architecture since 1970 and has written extensively on the subject. He is the author of the e-book. The Zachman Framework for Enterprise Architecture: A Primer on Enterprise Engineering and Manufacturing. He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker known for his motivating messages on enterprise architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent. Prior to joining IBM, Dr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U.S. Naval Reserve. He chaired a panel on Planning, Development, and Maintenance Tools and Methods Integration for the U.S. National Institute of Standards and Technology. He holds a degree in chemistry from Northwestern University, has taught at Tufts University, has served on the board of councilors for the School of Library and Information Management at the University of

xviii

Southern California as a special advisor to the School of Library and Information Management at Emporia State University, and on the advisory council to the School of Library and Information Management at Dominican University.

*** I congratulate Dr. Pallab Saha and the authors who have contributed to the Handbook of Enterprise Systems Architecture in Practice. This book covers a wide range of enterprise architecture (EA) issues in a way that reflects many aspects of a global EA discussion that has been going on for nearly 20 years. You will find some variance in the approach and lexicon that contributing authors use in many of the chapters, but you will also find a number of common threads that are an indication of both the richness and diversity of thought in the EA community and of the continuing maturity of EA as a management best practice and a career field for business and technology professionals. As such, the Handbook of Enterprise Systems Architecture in Practice is a valuable addition to the reading list of executives, managers, and staff in business, government, and other sectors who seek to keep their enterprises agile and efficient as they manage change, implement new business processes and supporting technologies, and pursue important strategic goals. EA is distinguished from, and yet encompasses, other forms of business, service, systems, data, and technology architecture. EA seeks to be the over-arching framework and methodology for integrating strategic, business, and technology planning across the entire enterprise. In so doing, EA claims to be the highest level of all meta-concepts that guide the analysis, design, and ongoing improvement of enterprises in the public, private, military, academic, and non-profit sectors. This expanded claim arises not from ego, but from necessity, as CEOs, CFOs, CIOs, and COOs seek new ways to envision and transform the enterprises they lead. Architectures exist in the mind of every executive and manager, yet these architectures are mostly held within, as executives are not familiar with EA methods and frameworks that offer ways to take abstract mental images and transform them into a sharable model of the enterprise. The CEO is the ultimate owner of the EA, yet that too is not fully realized. When it is, EA will further contribute to the ongoing success of enterprises in all sectors. This book presents over two dozen articles by leading authors, researchers, and practitioners, who cover various aspects of implementing systems architecture in the context of solving enterprise-level business problems. The approach to EA that I have written about previously centers on a framework with five hierarchical levels (strategic goals, business services, information flows, systems, and infrastructure) and three threads that pervade all levels of the architecture (security, standards, and training). In teaching this and other approaches to EA, I have had the privilege of helping to create several training programs and have delivered EA courses and seminars all over the world. To convey the essential and unique aspects of EA as it is most effectively practiced, I start my lectures with a simple equation: EA = S+B+T that stands for EA equals strategy + business + technology. This is meant to differentiate EA from early stand-alone forms of business architecture, data architecture, systems architecture, and network architecture all of which are active and relevant sub-architectures within an integrated EA. This equation also indicates that strategic priorities drive business requirements, which drive technology solutions including the design, implementation, and operation of information technology systems. EA is not just about technology, it is about designing and improving enterprises in all aspects, doing so through a repeatable and increasingly effective and mature methodology. My next lecture point is to usually say that a complete approach to EA must include an interlocking set of elements, including (1) a detailed step-by-step methodology for establishing the EA program and documenting current and future versions of the EA on an ongoing basis; (2) an analysis and documentation framework that establishes the scope and relationship of the EA; (3) a set of EA documentation artifacts (also known as work products) that cover all areas of the EA as defined by the framework; (4) the selection of a set of proven best practices for doing EA analysis, design, and documentation work, and which cover all areas of the framework; and (5) an online repository for archiving EA artifacts that incorporates automated documentation and analysis tools to the maximum extent possible. Unfortunately, many current approaches to EA do not have all of these elements, and/or the elements are not designed to work together. Examples include a lack of a complete set of

xix

artifacts to cover all areas of the EA framework; artifacts that are not derived from proven best practices, best practices that do not map to all levels of the framework, and a repository design that does not reflect the underlying analysis and design framework and is therefore difficult to understand, navigate, and use. I also point out how EA is but one of a number of areas of business and technology governance that must work together to be effective. These areas of governance include the decision-making processes, standards and policy for strategic planning, capital planning, enterprise architecture, workforce planning, program management, records management, security, systems development, and operations. The final lecture point that I usually present at the beginning of an EA seminar or class is to talk about five areas of value that EA creates for the enterprise: (1) increased alignment of business and technology programs with strategic goals; (2) increased business agility through improved decision-making and reduced cycle time in conducting workflow/dataflow/systems analysis, design, and implementation; (3) the ability to embark on business transformation initiatives and the improved management of change through the visualization of the entire enterprise in the strategic, business, and technology dimensions; (4) increased success in implementing or changing technologies that support key business processes and service/product delivery; and (5) increased ability to control otherwise escalating technology costs through the avoidance of duplication, and better matches between business requirements and technology solutions that extend across more lines of business. While these lecture points and lists are not all-inclusive, they hopefully address important points for students who are first being exposed to the multitude of concepts that EA encompasses. By being the meta-concept for enterprise analysis, design, and improvement, EA has become a rich, complex set of methods that must be effectively integrated and explained to those who sponsor and implement architectures in equally complex and dynamic enterprises. Fortunately, EA has itself become agile and purposeful as it matures and systems architecture is an essential part of this. Again, I congratulate Dr. Pallab and the other authors on the publication of this important contribution to the global EA discourse. I recently had the opportunity to talk with Dr. Pallab while on a teaching trip to Singapore and I can tell you that he not only understands all aspects of EA and systems architecture, but he is a thought leader in business and technology governance as well. His talk with my students about the integration of architecture and investment planning was very informative. I also know that many of the authors are active EA practitioners, teachers, researchers, or consultants and I especially value the opportunity that the Handbook of Enterprise Systems Architecture in Practice has given me to stay current in our evolving discipline through the sharing of their thoughts and best practices.

Scott A. Bernard, PhD August 2006

Scott A. Bernard currently serves as the deputy chief information officer and chief enterprise architect of the Federal Railroad Administration in Washington, DC. He is also an assistant professor for the School of Information Studies at Syracuse University, and a senior lecturer in the Executive Program of the Institute for Software Research International at Carnegie Mellon Universitys Computer Science Department. Dr. Bernard founded and currently serves as president of the Association of Enterprise Architects and is chief editor of the Journal of Enterprise Architecture. Dr. Bernard has nearly 20 years of experience as an information technology (IT) executive and manager including work in the academic, federal government, military, and private sectors. He has held positions as a chief information officer (CIO), senior management consultant, line-of-business manager, network operations manager, telecommunications manager, and project manager for several major systems installations. Dr. Bernards areas of current research, teaching, and consulting include IT-related leadership, e-government policy development, strategic planning, enterprise architecture, systems analysis and design, project management, and capital planning.

xx

Preface
I am not sure exactly when the importance of enterprise architecture (EA) dawned on me. What is clear is that it wasnt a one fine day realization, rather a result of numerous conversations with CIOs, IT managers, CFOs, process managers, and multiple research studies that convinced me that EA is perhaps the most important and the most misunderstood idea in information technology (IT) and a critical emerging discipline to elevate the role of IT organizations in enterprises. Metaphorically, an EA is to an organizations operations and systems as a set of blueprints is to a building. This handbook, unlike any other available today, aims: To provide a comprehensive and unified overview of practical aspects of EA. To integrate EA theory and concepts to field-tested methods, practical strategic issues, and implementation challenges. To illustrate development methods and the process cycle through case studies and detailed examples. To provide insights into the impact of effective EA on IT governance, IT portfolio management, IT risks, and IT outsourcing. To demonstrate the criticality of EA economics and its role in the strategic value of IT

This handbook is a compilation of 26 chapters on enterprise architecture written by practitioners and practicing academics from countries including Australia, France, Germany, India, Israel, Norway, Netherlands, Singapore, South Africa, South Korea, Switzerland, Portugal, United Kingdom, and the United States of America. The authors of these chapters were included in the review process in addition to having their submissions reviewed by a panel of independent reviewers. The handbook has been foreworded by John Zachman, the father of the Zachman Framework; undoubtedly the first formal framework in the discipline of EA and Dr. Scott Bernard, an accomplished EA practitioner who is now also an academic being associated with the Carnegie Mellon University. The chapters in the handbook have been selected with the intention to address professionals with a wide variety of interests and with different levels of EA knowledge. The handbook has a very strong practical orientation and is primarily targeted at: CIOs, IT/IS managers, architects, analysts, and designers seeking better, quicker, and easier approaches to respond to needs of their internal and external customers. Line-of-Business managers concerned with maximizing business value of IT and business competitiveness. CTOs of business software companies interested in incorporating EA to differentiate their products and services and increasing the value proposition to their customers. Consultants and practitioners desirous of new solutions and technologies to improve the productivity of their corporate clients. MIS and IT educators interested in imparting knowledge about this vital discipline. Researchers looking to uncover and characterize new research problems and programs. IT professionals involved with organizational technology strategic planning, technology procurement, management of technology projects, consulting and advising on technology issues, and management of total cost of IT ownership.

xxi

The handbook is structured logically into five parts. Section I on frameworks and methodologies focuses on approaches and mechanisms that organizations use to develop their architecture blueprints. Section II on governance and management shows how organizations initiate and sustain their EA practices. Section III provides insights into how organizations employ EA to drive their transformation programs, gain tighter business-IT alignment, and realize business value out of their IT investments. Section IV consists of descriptions of the adoption of EA in large and small organizations with insights on key practical challenges they face and how the whole EA programmes are sustained. Finally, Section V demonstrates the role of technology, especially service-oriented architecture (SOA) in EA implementation. Section I: Frameworks and Methodologies Section I is a collection of chapters describing approaches and methods used by organizations to plan and develop their EA blueprints. Chapter I: A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000), by Pallab Saha of the National University of Singapore, evaluates synergies between the comprehensive FEAF against the generalized enterprise reference architecture and methodology (GERAM) framework. The federal enterprise architecture framework (FEAF) is perhaps the most adopted EA framework, especially within the U.S. Government agencies. Either FEAF has been adopted as-is or other frameworks derived from FEAF have been used. FEAF today continues to be the most comprehensive framework available for guidance by agencies. It consists of a full-fledged methodology, several reference models, target architectures, and even a toolkit that facilitates adoption across all agencies. The chapter discusses the level of completeness in the FEAF based on GERAM requirements and additionally identifies areas where the FEAF goes well beyond GERAM requirements. Chapter II: Extreme Architecture Framework: A Minimalist Framework for Modern Times, by Phil Robinson of Lonsdale Systems, Australia and Floris Gout, an Independent Consultant based in Australia, presents an EA framework that is lightweight and selective to meet the needs of the organization. The chapter uses the agile approach to develop architectural artifacts. It starts with the need for frameworks and some of the currently popular frameworks. Then it argues why interoperability both at systems and human level is critical followed by a discussion on the relevant architectural views that is derived from the XAF matrix and elements that need to be created. The chapter concludes with a comparison of the proposed framework with other established frameworks from the point of view of simplicity and ease of use. Chapter III: Discovering and Modelling Enterprise Engineering Project Processes, by Ovidiu Noran from Griffith University, Australia, provides a meta-methodology based on existing architecture frameworks that facilitates organizations to assess and select architectural elements and artifacts within the context of specific EA program requirements. The proposed approach in the chapter allows organizations to configure their EA programme, instead of doing the whole nine yards for every situation. The chapter illustrates the proposed approach with a real-life case study. Chapter IV: Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises, by Tae-Young Kim, Sunjae Lee, Jeong-Soo Lee, and Kwangsoo Kim of the Pohang University of Science and Technology, South Korea and Cheol-Han Kim from Daejeon University, South Korea, presents a modeling framework that business architects and domain specialists can use to build and configure architectural elements and models specifically for virtual enterprises (VE). The chapter uses and improves upon existing modeling standards and practices (like BPMN, UML, MDA) and applies concepts of service-oriented architecture (SOA) to make organizations more responsive to change.

xxii

Chapter V: Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures, by Steven J. Ring and Dave Nicholson from the MITRE Corporation, USA and Stanley Harris, Lockheed Martin Corporation, USA, presents the DOD defined methodology that uses DODAF to create architecture outputs. Activity-based methodology (ABM) discussed in this chapter is presented as a step-by-step approach that allows a common reference point for all architectural assets in terms of scope, breadth, depth and intensity. Several DOD entities have adopted or are in the process of adopting ABM, thereby providing credence to its applicability in practice. Chapter VI: Business Process Modeling as a Blueprint for Enterprise Architecture by Joseph Barjis of Georgia Southern University, USA and Isaac Barjis of City University of New York, USA, presents a Petri-netbased methodology, transaction-oriented Petri-nets (TOP), to enterprise process modeling. The chapter starts with a brief background of existing architecture frameworks and discusses the role of business architecture. Then it presents the details of the TOP notation, following which the complete TOP methodology framework is discussed in a step-by-step manner with examples provided to illustrate each step and their respective output. Chapter VII: Enterprise Architecture in the Singapore Government by Tan Eng Pheng and Gan Wei Boon from Infocomm Development Authority of Singapore, Singapore, is a discussion of the role of enterprise architecture in the Singapores e-government programmes. The chapter discusses the evolution of the countrys e-government action plans and policies and examines the linkages and role that EA plays including IT governance and investment planning. The chapter briefly presents the currently ongoing efforts within the government to define reference models that are intended for use by agencies to develop their own EA in alignment with the overall Government-wide EA. Within the current e-government plan, the iGOV 2010, EA is one the three key pillars of programme success. Section II: Governance and Management Section II of the handbook comprises of chapters that are useful to institute and sustain the EA practice within the organization. Chapter VIII: Understanding and Communicating with Enterprise Architecture Users, by Steven Thornton from the National Institutes of Health, USA, discusses current best practices and provides guidelines in communicating EA to the users. The recommended approaches and practices presented in the chapter are derived from the United States National Institutes of Health (NIH) EA programmes. The intent of this chapter is to educate CIOs and chief architects about the need to communicate EA, recommended approaches, and its key benefits to the EA programme. Chapter IX: Improving Stakeholder Communications and IT Engagement: A Case Study Perspective, by Gail L. Verley of the Federal Deposit Insurance Corporation, USA, continues on the theme of architecture governance and management. This chapter begins with a discussion on the need to improve stakeholder communications and enhance engagement with the users in an EA programme. The chapter presents five steps to involve stakeholders in EA programmes, followed by ten strategies and mechanisms to institutionalize stakeholder involvement. The application of the steps, strategies, and mechanisms presented in the chapter are illustrated through a detailed case study of United States Federal Deposit Insurance Corporation (FDIC). The chapter concludes with a set of lessons learned that organizations can refer to. Chapter X: The Role of Change Management in IT Systems Implementation, by Ron S. Kenett of KPA Limited, Israel and Sebastiano Lombardo from the Foundation for Scientific and Industrial Research at the Norwegian Institute of Technology (NTH), Norway, presents an integrated holistic approach to IT systems implementation called the better enterprise systems implementation (BEST). The chapter treats IT systems implementation as an organizational development issue and positions the BEST methodology as an approach to manage IT driven organizational change. The chapter then illustrates the application of the methodology through three case studies in Norway and Israel. Chapter XI: Managing Enterprise Architecture Change, by Tim ONeill, Mark Denford, and John Leaney of the University of Technology Sydney, Australia and Kyle Dunsire from Avolution Pty. Limited, Australia,

xxiii

is a description of an approach that allows organizations to simulate, predict, and control the emergent properties of enterprise systems from an architectural perspective. The chapter argues that existing methodologies and toolsets are by nature bottom-up and often fail to take into consideration the non-functional requirements of the IT systems from an architectural viewpoint. The chapter begins with a brief discussion of the key nonfunctional requirements that most IT systems are expected to fulfill. It then presents a five-step methodology that organizations can use to build and evolve their architectures. The chapter concludes with the benefits of the proposed methodology. Section III: Transformation and Value Realization This section of the handbook focuses on how organizations use EA to facilitate and drive their organizational transformation objectives seeking to enhance alignment between their business and IT functions. Business value of IT being a key point in todays IT organizations is covered in this part by way of how EA is used to realize economic value. Chapter XII: Architecture Driven Business Transformation, by Chris Lawrence of Old Mutual South Africa, South Africa, presents an approach where EA is viewed as a business issue. The chapter starts with a discussion on business transformation that is triggered through EA. The chapter argues that EA is an imperative irrespective of the business condition that an organization might be in and places forth business diagnostics as a key element of any architectural initiative. The chapter illustrates the application of the proposed approach in a financial services organization and discusses process driven business transformation. The chapter then concludes with a discussion on non-process driven business transformation and why process architecture based transformation was used as an example. Chapter XIII: Maturity of IT-Business Alignment: An Assessment Tool, by Nel Wognum of the University of Twente, The Netherlands and Fan Ip-Shing from Cranfield University, United Kingdom, presents such an approach based on better enterprise systems implementation (BEST). In doing this, the two key questions addressed are what problems can be pre-empted and what can be done about them. The chapter then continues to illustrate the proposed approach through several mini-cases derived out of real-life scenarios. The chapter concludes with a discussion on areas for further research. Most large IT system implementation initiatives are plagued by several factors that often make implementations less than desirable. While factors leading to failure for large IT implementations have been documented and analyzed, the intriguing issue is that organizations seem to repeat the same mistakes over and over again. This necessitates the need for a mechanism that allows planners and managers to evaluate the start-up situation in such projects, including capturing the project dynamics in a coherent manner. Chapter XIV: The Integrated Enterprise Life Cycle: Enterprise Architecture, Investment Management, and System Development, by Frank J. Armour from Armour LLC, USA, Chris Emery and Jonathan Houk of the U.S. Architect of Capitol, USA, Stephen H. Kaisler from SET Associates, USA, and John S. Stan Kirk from the U.S. National Science Foundation, USA, explores and discusses the linkages that EA has with IT investment management and system development processes and hence the need for a holistic approach. In doing so, it proposes an integrated enterprise life cycle (IELC). The chapter starts with a discussion of the IELC and its various components. The chapter positions IELC as a key IT governance mechanism and presents several governance archetypes that are part of the IELC. The chapter concludes with a brief discussion on the proposed move towards IELC by the U.S. Office of Management and Budget (OMB) and U.S. General Accounting Office (GAO) under the Federal Enterprise Architecture (FEA) program. Chapter XV: Promoting Netcentricity through the Use of Enterprise Architecture, by Supriya Ghosh from Lockheed Martin Corporation, USA, presents U.S. Department of Defense (DOD)s goal of net-centric transformation as an implementation of EA. The chapter argues that to achieve net-centricity the existence of an integrated architecture provided by the DOD Global Information Grid (GIG) is a key imperative. The chapter then provides an overview of the key performance parameters to support net readiness. It details the adoption of net-centric transformation through the use of net-centric data strategy, net-centric IA strategy, service-oriented

xxiv

architecture (SOA), and communications transport strategy. The chapter concludes with a discussion on upcoming and future trends to enable DODs move towards net-centricity. Section IV: Implementation and Deployment Section IV of the handbook looks at EA from an ongoing implementation and transition perspective through cases both in large and small organization scenarios. Chapter XVI: Enterprise Architecture as an Enabler for E-Governance: An Indian Perspective, by Raghunath Mahapatra of Ernst & Young India, India and Sinnakkrishnan Perumal from the Indian Institute of Management Calcutta, India, is a case study on application of EA to develop an efficient and effective e-governance system for citizen services administration by the Government of India. The chapter starts with a background on various e-government initiatives, including a brief discussion on the administrative structure in India. The chapter then puts forth key imperatives that are required for successful e-government programs, keeping in mind the Indian context. EA is then presented as one the critical success factors. The chapter continues with a detailed discussion of a proposed framework (derived from the Zachman Framework) that facilitates the application of EA in the context of e-government in India. The chapter concludes with a mapping of the earlier presented imperatives to the key elements of the proposed framework. Chapter XVII: Federated Enterprise Resource Planning Systems, by Nico Brehm from the Carl-von-Ossietzky-Universitt Oldenburg, Germany, Daniel Lbke from the University Hannover, Germany, and Jorge Marx Gmez from the Carl-von-Ossietzky-Universitt Oldenburg, Germany, presents enterprise resource planning (ERP) system architecture that makes individual business modules reusable through the use of Web services based on shared and non-monolithic architecture. The chapter is based on a practical challenge that enterprises currently face wherein systems (especially the ERP tools) have proprietary data models, thus limiting their usage and in conflict to their claim of being positioned as enterprise systems. This leads to vendor lock-in. The chapter begins with a background on existing ERP systems with a discussion of their limitations as real enterprise systems. The chapter then presents the federated ERP system approach and discusses how the federated approach addresses the shortcomings of existing siloed ERP systems. The chapter concludes with a discussion on the kind of adoption challenges that the federated approach might face along with a short brief on future trends and research. Chapter XVIII: A Network Based View of Enterprise Architecture, by Bala Iyer of Babson College and David Dreyfus of Boston University, USA and Per Gyllstrom, PFPC Worldwide Inc., USA, moves away from the traditional four sub-architecture-based view of EA and takes a network-based view that is based on understanding and capturing the dependencies between the elements of the EA. The proposed approach asserts that such dependencies are a factor of time and typically emerge as the architecture evolves. Dependencies that emerge during the design, deployment, and operations of the EA are based on both technical and social factors. The chapter presents a case study of the application of the proposed approach in a financial services company. The chapter concludes with a discussion of the limitations of the proposed approach and presents pointers to how the limitations can be addressed. Chapter XIX: Enterprise Architecture by a Small Unit in a Federated Organization, by Roger Sliva from the State of Nevada, USA, presents experiences and best practices in developing EA by a small team for a federated organization. A federated structure is typical in many governments where the administrative structure is organized into national/federal entities followed by states, districts, or provinces. Given the federated structure, developing EA presents several practical challenges. The chapter discusses factors to be considered in such a scenario when developing EA in terms of scope, intensity, use of tools, open standards, shared business services, and programme governance. Chapter XX: The Syngenta Architecture Story, by Peter Hungerford from Syngenta AG., Switzerland, presents the experiences of development and evolution of EA at Syngenta. The key drivers in Syngentas architecture programme are business efficiency, growth, and innovation. The chapter shares the experiences and insights from several business areas. The case studies presented in the chapter includes EA initiatives like server

xxv

rationalization and development of global infrastructure services, integrated go-to-market platform, providing an unified research platform, and building an enterprise-wide business intelligence. The chapter then presents a simple framework for EA and discusses the case studies in the context of the framework. The chapter concludes with future trends and discusses a few plausible areas of research. Chapter XXI: The Use of GERAM for Design of a Virtual Enterprise for a Ship Maintenance Consortium, by John Mo from the Commonwealth Scientific and Industrial Research Organization, Australia, describes the application of the generalized enterprise reference architecture and methodology (GERAM) in analyzing the ANZAC ship alliance (ASA). The chapter discusses the details of the use of GERA in developing and studying a virtual enterprise, especially issues relating to logistics and information architecture management needed to support the operations of ASA as a virtual enterprise. The chapter starts with a brief overview of the GERAM including the key reasons of why it was selected for use. The chapter then describes ASA as a virtual enterprise including the peculiarities and nuances of a virtual enterprise. The chapter concludes with a description of enterprise engineering programme at ASA, the artifacts and models developed based on GERAM requirements. Chapter XXII: Information Systems Architecture for Business Process Modelling, by Michel Spadoni of the Ecole Nationale dIngnieurs de Metz & Laboratory for Industrial and Mechanical Engineering, France and Anis Abdmouleh from Metz University and Laboratory for Industrial and Mechanical Engineering, France, is a description of business process modeling capabilities within the CIMOSA application server (CAS). The CAS is an information system for enterprise modeling and designing. The chapter starts with a brief overview of the problems that is faced by organizations in integrating their disparate systems. Then it describes the CAS project, its goals and objectives and the primary reason for selecting CIMOSA as the reference architecture. Following this, the chapter describes the CIMOSA modeling framework and conceptual model. The chapter then describes the business process modeling aspects with an example of a manufacturing organization including the views and artifacts needed to support the requirements of enterprise systems. Section V: Technology and Service-Oriented Architecture This section of the handbook is a compilation of chapters on the role technology plays in an architectural initiative. Chapter XXIII: Enterprise Architecture within the Service-Oriented Enterprise, by Scott J. Dowell of Shirnia & Dowell LLC, USA, elaborates the role of EA in a service-oriented enterprise (SOE). Driven by the need to the adaptable, agile, and responsive to change, organizations are now adopting the SOE paradigm where organizations view themselves as a bundle of services that are available for use through technology enablement. The chapter begins with the issues that enterprise architects need to grapple with, namely, business services, service-oriented solutions, infrastructure services, and IT organization changes. It goes on to compare a traditional enterprise with a SOE. The chapter then discusses the development of strategy in a SOE and its peculiarities. The chapter provides real-life examples on various aspects of service orientation adopted by various organizations. Chapter XXIV: A Fundamental SOA Approach to Rebuilding Enterprise Architecture for a Local Government after a Disaster, by Zachary B. Wheeler of SDDM Technology, USA, is a case study of the reestablishment of EA for the local Government following Hurricane Katrina in Louisiana. The chapter presents an approach to address areas in EA that have not received much attention as part of preparedness, response, and recovery phases. The chapter proposes the use of SOA paradigm to address some the key issues. The chapter starts with a brief background of the underlying EA framework that was used in the given situation, followed by a detailed description of the conceptual data model and how a critical portion of the EA was developed. The chapter concludes with a discussion on other technologies that can be used to extend the current solution. Chapter XXV: Business Networking with Web ServicesSupporting the Full Life Cycle of Business Collaborations, by Diogo R. Ferreira from the Technical University of Lisbon, Portugal, proposes to use the Web services paradigm as a way to deal with all aspects of business collaborations. The chapter starts with an overview of Web services as an integration platform, followed by a description of the criticality of the life cycle approach in integration. The chapter demonstrates with examples the use of Web services in extending its support of

xxvi

operational aspects alone to the full life cycle of business collaborations, thereby enabling seamless e-business collaborations and trading. Chapter XXVI: Enterprise Integration Architecture for Harmonized Messaging, by Dat Cao Ma, Belinda Carter, Shazia W. Sadiq, and Maria E. Orlowska, University of Queensland, Australia, presents a rule-based enterprise integration approach enabled through messaging technology. The chapter begins with the challenges of large-scale collaborative systems and the evolution of technology solutions to address some of the challenges. The chapter then presents the proposed enterprise integration architecture and an overview of related technologies. Following this, the chapter elaborates the steps in rule design, validation, and deployment and its adoption within the proposed integration architecture. The chapter concludes with a discussion on future developments in the proposed area. In conclusion, I hope that this handbook makes its contribution to the emerging discipline of EA, which is only going to gain importance in organizations. I would like to invite readers to share their comments about the handbook in addition to their success stories that may well spawn of future editions of this Handbook. Dr. Pallab Saha National University of Singapore December 2006

xxvii

Acknowledgments
This handbook is a result of the efforts and support of many people. Without their advice, assistance, and deep involvement, the handbook would not have achieved its current form. I would like to express my gratitude and thank all involved in the collation and review process of this reference book on enterprise architecture. I would like to start with IGI who gave me the opportunity to realize my cherished dream. This handbook allowed me to make significant contributions to an emerging and timely discipline. A special word of thanks to Kristin Roth of IGI who guided me with numerous e-mails and to Dr. Mehdi Khosrow-Pour who motivated me to initially accept his invitation for taking on this project. I would like to specially acknowledge the contribution of the independent reviewers of the chapters, who readily agreed to review despite their own busy schedules, often working on very tight deadlines given by me. Herein goes my sincere thanks to Dr. Hoe Siu Loon of Singapore Telecommunications, Rina Levy of The Mitre Corporation, and Dr. Sam Chung of the University Of Washington (Tacoma). Representing both industry and academia points of view, they provided excellent review comments that improved the overall submission quality. An important part of this handbook is the chapter authors. I appreciate their excellent contributions and want to thank them for assisting me in the review process. Last but not the least, this handbook would not have become a reality without the support of my mother Shrimati Anima Saha, my wife Neeta, and our adorable daughter Anushka (who was born last year as I conceived this book). Above all, I would like to dedicate this book to my father, the late Shri Jagatbandhu Saha. Dr. Pallab Saha Singapore December 2006

xxviii

Frameworks and Methodologies

Section I

A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000)
Pallab Saha Institute of Systems Science, Singapore

Chapter I

ABSTRACT
The federal enterprise architecture framework (FEAF) is perhaps the most adopted EA framework, especially within the U.S. Government agencies. Either the FEAF has been adopted as-is or other frameworks derived from the FEAF have been used. The FEAF today continues to be the most comprehensive framework available for guidance by agencies. It consists of a full-fledged methodology, several reference models, target architectures, and even a toolkit that facilitates adoption across all agencies. This chapter evaluates the synergies between the comprehensive FEAF against the generalized enterprise reference architecture and methodology (GERAM) framework. The intent of the evaluation is to present the level of completeness in the FEAF based on GERAM requirements and additionally discuss areas where the FEAF goes well beyond ISO15704:2000 requirements leading to improvement opportunities in GERAM.

INTRODUCTION
Enterprise architecture (EA) is the discipline of designing enterprises guided with principles, frameworks, methodologies, requirements, tools, reference models, and standards. Managers are becoming architects. Their new roles include designing structure, engineering processes, developing

people, leveraging technology, facilitating learning, and changing the whole (Morabito, Sack, & Bhate, 1999). The manager-architect must design across enterprise boundaries, engineer processes into strategic capabilities, align information technology and business strategies, and integrate the enterprise. In order for the manager to achieve all these, several contending architecture frameworks

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

A Synergistic Assessment of the Federal Enterprise Architecture Framework

are available (Bernus, Nemes, & Schmidt, 2003; Chen & Doumeingts, 1996; Chen, Vallespir, & Doumeingts, 1997). Of the several contending architecture frameworks, this chapter analyzes the federal enterprise architecture framework (FEAF) approach to EA against the generalized enterprise reference architecture and methodology (GERAM) / ISO15704:2000 requirements. The objective of this detailed analysis is to provide prospective users of the FEAF, an understanding of GERAM/ISO15704:2000 requirements, and the extent to which the FEAF-based approach meets these requirements. Several other frameworks have been analyzed against the GERAM/ISO15704:2000 requirements (Noran, 2003, 2005; Saha, 2004a), currently there is no mapping between the FEAF and GERAM and the chapter attempts to address this gap. The key objectives of the analysis presented in this chapter include: (1) map and compare the FEAF-based approach to a common set of EA requirements as specified in GERAM; and (2) identify areas where the FEAF is richer/weaker, with the aim that managers and researchers can take benefit in practice and in identification of newer areas for research, including enhancement of existing frameworks. The key motivations for selecting FEAF for this assessment include: he FEAF is perhaps most implemented T either as-is or in derived form. It may be argued that FEAF is relevant only in the context of United States Federal Government agencies. However, in reality, all of the FEAF documentation is available in public domain and many EA programs around the world take cue from FEAF (localized for specific needs). he FEAF is an embodiment of best practices T and guidelines. An assessment actually has the capability to further the EA discipline and its practice.

he FEAF by design is generic and apT plicable to all agencies, irrespective of the industry they operate in. This makes FEAF application non-industry specific and broad.

BACKGROUND Short Overview of GERAM

Existence of several architecture frameworks provides a recipe for confusion. The overriding goal of the generalized enterprise reference architecture and methodology (GERAM) is to encompass and generalize the common requirements of various EA frameworks and EA reference architectures (Bernus, 2001; IFIP-IFAC Task Force, 1999). The GERAM is not another EA framework or EA reference architecture. GERAM aims to classify prevalent EA frameworks and their associated artifact types (methodologies, reference models, ontologies, etc.). The scope of GERAM (depicted in Figure 1 of Chapter XXI of this handbook) encompasses all knowledge required for enterprise engineering and enterprise integration with the intention of unifying several disciplines such as industrial engineering, management science, control engineering, and information and communication technology to build a coherent organizational design (Bernus et al., 2003). The central component in the GERAM framework is generalized enterprise reference architecture (GERA), which specifies the basic/core concepts to be utilized in an EA initiative. Besides GERA, other components in GERAM identify requirements regarding process methodologies, modeling languages, tools, and enterprise models necessary for architecting the enterprise. The GERAM framework components would form the basis for mapping and analysis of the FEAF-based approach in this chapter.

A Synergistic Assessment of the Federal Enterprise Architecture Framework

Short Overview of the FEAF

Mandated by the Clinger-Cohen Act of 1996, the office of management and budget (OMB) along with the Federal CIO Council developed the federal enterprise architecture framework, which is a business-based framework for government-wide improvement envisioned to facilitate efforts in transforming the U.S. Federal Government to one that is citizen-centered, results-oriented, and market-based (CIO Council, 1999). The framework provides an approach to identify, develop, and specify architecture descriptions of high priority areas that in built on common business areas and designs that span multiple organizations, not limited by organizational boundaries (CIO Council, 1999). The FEAF provides a structured approach to federal organizations to integrate their respective architectures into the federal enterprise architecture (FEA). The federal enterprise architecture (FEA) was commissioned in 2002. According to the CIO Council, the primary objectives of developing the FEAF was to organize federal information on a government-wide scale, promote information sharing among federal organizations, facilitate federal organizations develop their respective architectures, facilitate federal organizations develop their IT investment processes, and serve customer needs better, faster, and cost effectively. In designing the FEAF, eight core components were taken into consideration and elaborated. These components deemed essential to develop and maintain the FEA were architecture drivers, strategic direction, current architecture, target architecture, transitional processes, architectural segments, architectural models, and standards. The scope of the FEAF encompasses all aspects of enterprise architecture development. The business architecture specifies an organizations business strategies, goals, and objectives and links these to business processes that are required to execute the identified strategies. The data architecture describes the structure of an organizations logi-

cal and physical data resources and management of such resources. The technology architecture describes the information technology infrastructure required to support the organizations business processes and information architecture. The application architecture describes the software applications needed to deploy organizations business processes governed by business rules (CIO Council, 1999).

ASSESSMENT APPROACH
The analysis attempts to assess the FEAF in meeting GERAM requirements. In case of the FEAF lacking in certain areas, this chapter provides guidance toward ensuring common understanding of deliverables, and ways to complete it using GERAM requirements as the reference. With this aim, the analysis centers on several aspects, each discussed in detail in subsequent sections.

LIFE CYCLE PHASES

Current literature in EA points to two main perspectives in architectural framework specification: the static perspective representing the structural aspects at a specified point in time and the dynamic perspective capturing the various stages that architecture development goes through (Noran, 2003). An architecture life cycle phase in GERAM usually represents activities and tasks performed during the architecture development process, the inputs and outputs of each activity, and the artifacts (or deliverables) that are developed as part of phase realization. While it is possible to represent phases in a sequential manner, in reality, organizations prefer to develop EA iteratively. The crucial point is that life cycle phases in GERA represent logical groupings of activities performed and artifacts produced, and not the temporal aspects in EA development (IFIP-IFAC Task Force, 1999).

A Synergistic Assessment of the Federal Enterprise Architecture Framework

The FEAF Life Cycle Aspect

While an EA framework like the FEAF provides valuable guidance on the content of enterprise architectures, however, in order for organizations to successfully manage the process of envisioning, developing, deploying, using, and maintaining the EA, the CIO Council in 2001 provided a stepby-step process guide. The processes described represent principles of good EA. The mapping is largely direct. The identification and concept phases in GERA map to obtain executive buy-in & support and establish management structure & control stages in the FEAF process. This is where the EA program is initiated in the organization and the overall EA policy is developed based on the organizations architectural principles. The EA policy (at the least) addresses issues like: purpose and value of the EA, relationship between EA and organizations strategic goals, transformation of business strategies into EA goals, and objectives and establishment of the EA program office and core team with roles and responsibilities. The EA core team is responsible for all activities involving development, implementation, deployment, and maintenance of the EA. The requirements phase in GERA maps to define an architecture process and approach activity. In this phase, the organization elaborates the scope and intended use of the architecture. Besides, the overall intent of early GERA phases is also reflected in the way reference models are sequenced in the FEAF, where upstream activities like performance and business reference models influence and drive the development of the remaining reference models downstream. To summarize, this phase sets the tone for the rest of the EA development process. GERA splits the actual EA design into two phases that are preliminary design and detailed design. These two phases directly map to the FEAF develop baseline architecture and develop target architecture stages. In building the EA, the first logical step is to understand the as-is

state. This is crucial as it enables future progress to be measured against a reference or baseline. As baseline architectures focus on capturing the current state, organizations usually decide on the level of details and complexity desired. This phase of developing the baseline architecture takes and provides critical input to the requirements phase. Once the organization documents the current architecture and requirements for the future to-be architecture, it is ready to undertake the development of the target architecture, which primarily is the process of addressing gaps between the as-is and to-be states. The next phase in GERA is implementation of the EA and this maps to develop the sequencing plan in the FEAF. This process focuses in developing a transition/migration plan for the organization to move from the as-is state to the to-be state. In this, phase organizations usually take inputs from industry specific standards that may be available. The primary goal of this stage is that the organization starts operating with the new EA in place. The next GERA phase of operation maps directly to use the enterprise architecture process in the FEAF. The focus here is to ensure the target EA is implemented and good EA management practices enforced leading to continuous governance. Decommissioning the EA at the end of its useful life is the last phase in GERA; the FEAF specifies maintain the enterprise architecture as its last process step. The objective of this phase is to establish a process to ensure that the baseline architecture accurately reflects the current state and the target architecture correctly represents the future business vision.

Concluding Remarks on Life Cycle Phases

The common underlying premise that evolution of enterprises, represented as enterprise life cycle consisting of progressive stages like conception, design, deployment, operation and maintenance, and retirement, is an iterative process that incor-

A Synergistic Assessment of the Federal Enterprise Architecture Framework

porates new business processes, new technology, and new capabilities is evident in both GERA and the FEAF. While the EA process specified by the CIO Council is not specific to the FEAF, its application in the FEAF context is well accepted.

TEMPORALITY AND SUCCESSION

The development and maintenance of architecture is a continuous process that includes assessment of current business conditions and exploration for target solutions. In addition to the logical groupings of activities and tasks represented earlier as life cycle phases in the EA process, the development of EA also progresses in time and detail. Hence, timeline related aspects form a crucial portion of the GERAM requirements. A separate and explicit temporal aspect allows organizations to evolve and adapt to changing business environment during the progress of the enterprise architecture development. This is made possible by the fact that an organization may necessarily not delve into details at the initiation stage of EA development, but has the flexibility to add increasing details over time.

Temporality and Succession in the FEAF

The FEAF explicitly specifies timeline- and succession-based approaches to architecture development. Temporality and succession in the FEAF is realized through successive levels of decomposition and drill-down on each core component. The decomposition process is a basis for a four-level framework, with each level providing a frame of reference for the next. The four levels represent a continuum that captures progression, evolution, and adaptation in time. The first three levels represent the progression of eight increasingly detailed components leading to a logical structure for classifying and organizing the organization specific descriptive representa-

tions of the Federal EA at Level IV. The temporal aspect is tightly integrated to the FEAF EA process, providing time-based anchors during the architecture life cycle to represent various forms that the EA takes. Level I is the highest level of the FEAF that introduces the eight core components and interplay between them in developing and maintaining the architecture. Level II depicts the business and design elements and the relationships between them. At this level, the business of the enterprise along with the architectural design needed to support the business is represented. The relationship is push-pull, where the business pushes the design and the design pulls the business to higher levels of capability and service delivery. Level II further elaborates on the migration processes that facilitates the movement of the enterprise from the baseline to the target architecture adhering to the architecture standards. A critical activity in Level II is the development of the business architecture. Level III expands on the design elements that are needed to support the business architecture. This includes development of the data, technology, and applications architecture. Application of design standards like data standards, security standards, applications standards, and technology standards is a critical activity at this level. Level IV identifies the specific kinds of models that specify the business architecture along with the design architectures (data, technology, and applications). At this level, the mechanism for design architectures to support the business architecture is made explicit. Additionally EA planning takes place at this level. The models to specify the business and design architectures and the architecture planning that occur at Level IV are based on the Zachman Framework for EA (Zachman, 2000) and Spewaks EA Planning Methodology (Spewak, 1993). In its current form, the FEAF Level IV incorporates only three of the six columns from the Zachman Framework (i.e., what, how, and where). The who, when, and

A Synergistic Assessment of the Federal Enterprise Architecture Framework

why columns will be considered for incorporation in future.

1. 2. 3.

The life cycle dimension, The life history dimension, and The perspective dimension.

Concluding Remarks on Temporality and Succession

Time-based progression and succession in levels of details is critical in GERAM, and the FEAF explicitly addresses this with a four-level architecture framework. As an organization progresses through the architecture development process, the level of details specified increases leading to a generic-to-specific continuum that ensures bidirectional traceability between enterprise entities. The architecture reference models elaborated subsequently form the initial basis and a starting point for successive architecture specifications in increasing levels of details.

MODELING FRAMEWORK
The GERA modeling framework is included as a core component in the GERA reference architecture. In specifying the scope and type of enterprise models that need to be developed and maintained as part of the architecture development process, the modeling framework plays a crucial role. The analysis of the FEAF against GERAM modeling requirements incorporates two critical issues, which are: (1) the richness of guidance provided in the FEAF with regard to the scope and types of models to be created and maintained; and (2) the ability of the FEAF to accommodate the complete scope of modeling framework as in the GERA specifications.

The FEAF Modeling Framework

The FEA framework at Level IV is based on the Zachman Framework and so is its modeling framework. The FEAF modeling framework is anchored around three dimensions:

The coverage and mapping of the first two dimensions by the FEAF has already been discussed. With regard to the perspective dimension, the FEAF explicitly mentions the existence of multiple perspectives and their mapping to the various architectures that are developed to build the overall EA. Each row (perspective) represents a holistic view of the architecture from a particular perspective. Each row represents a unique perspective; however, the model for each perspective provide necessary details to specify the solution at the level of the perspective and translates to the next lower row explicitly. The FEAF recommends five perspectives/views. The planners view specifies the overall scope of the architecture, while the owners, designers, builders, and the subcontractors views specify the enterprise, information systems, technology, and detailed specification models, respectively. Each column represents a specific area of focus and this drives the way the overall architecture is partitioned. In summary, each column poses a fundamental question (i.e., what, how, and where), while the way these fundamental questions are answered depend on the viewpoints of the stakeholders in architecture development. The intersections of the rows and columns specify the models that need to be developed. The FEAF specification provides fairly detailed descriptions of the models that are to be developed and further enriched with illustrations. With the same intention of reducing complexity and providing a structuring mechanism, GERA also supports multiple views that accommodate viewpoints of different stakeholders. While GERA is not normative about the actual views, it explicitly identifies two areas for conformance by candidate architectures, which are: (1) the overall intent of the four GERA views must be covered; and (2) the views should be subdivisions of an integrated

A Synergistic Assessment of the Federal Enterprise Architecture Framework

metamodel such that the combined scope of the modeling framework is complete. The mapping between GERA and the FEAF views is a little convoluted. GERA model content views with focus on user-oriented process representation of the enterprise entity descriptions maps to the FEAF planners and owners view but largely along the activities column. GERA purpose views with focus on mission of the enterprise entity and products and services required to support the enterprise objectives roughly map to the FEAF planners and owners view mostly along the entities column. GERA implementation views focusing on tasks that are/are not to be automated roughly maps to the FEAF designers view. Lastly, GERA physical manifestation views with focus on software and hardware required to realize the architecture maps to both the FEAF builders and subcontractors view.

(TRM), business reference model (BRM), performance reference model (PRM), service component reference model (SRM), and the data reference model (DRM). Additionally, it is believed that as and when the FEAF specifications include the remaining three columns (i.e., who, when, and why) addressing three more fundamental questions, the mapping with GERA would become tighter.

MODELING LANGUAGES
Enterprise architecture involves creation of several models governed by a modeling framework and influenced by a modeling methodology. GERAM recognizes that any enterprise architecture initiative is a large and complex undertaking and thus, would require potentially multiple modeling languages (IFIP-IFAC Task Force, 1999). GERAM specified requirements for modeling languages include: 1. The (set of) modeling language(s) must be able to represent every modeling view/ viewpoint for every enterprise architecture artifact in the development methodology and extent of specificity. Models developed for one view must be linkable with models in other views as such linkages are a logical requirement for a coherent enterprise architecture view. Modeling languages must be based on reliable ontologies (metamodels with semantic rules).

Concluding Remarks on Modeling Framework

In mapping the FEAF against GERA modeling views, it is to be noted that even within the same column, each intersecting cell in the FEAF covers GERA views to a different extent, depending on the perspective (row) containing them. A modeling framework is a structure specifying the artifacts (deliverables) required to accomplish the architecture development. From the modeling framework point of view, in line with GERA requirements, the FEAF has a direct mapping vis--vis GERA life cycle and temporality dimensions. On the view dimension, while there are areas where the mapping is not direct, the point to be noted is that the FEAF taxonomy of recommended views largely covers the entire intent of GERA view concepts. This is made possible as the FEAF Level IV is based on Zachman framework, which has been analyzed against GERAM (Noran, 2003). The FEAF specifications do not limit the modeling framework to just models, but also include other construct types like the technical reference model

2.

3.

Modeling Language(s) for the FEAF

The FEAF, while explicitly specifying the models and architecture products required to be developed and when and how they are to be developed, does not define any dedicated architecture development language. However, as guide to organizations implementing the FEAF, it does recommend third-party modeling languages that might be

A Synergistic Assessment of the Federal Enterprise Architecture Framework

appropriate in developing critical EA products (CIO Council, 2001). Enterprise architects selecting the FEAF must utilize several proprietary and third-party modeling languages in order to accomplish all architectural activities and products. Lack of the single/unified set of modeling language(s) for EA, based on a single underlying metamodel, creates the risk of low consistency and interoperability between various models and products, and it is upon the architect to impose discipline in this regard. The EA tool selected by the organization further influences the selection of modeling language(s) depending on the languages supported. In summary, the FEAF is open and non-prescriptive about any specific modeling language, as long as the architects goal is accomplished.

Unified modeling language (UML) for application architecture, Entity-relationship (ER) data model using IDEF 1x for information architecture, Object-role modeling (ORM) and object constraint language (OCL) for specifying business rules, Event driven process chain (EPC) and business process modeling notation (BPMN) for specifying business process view, among others.

Table 1 provides an indicative list of notations and languages that could be used in the different stages of the EA development.

METHODOLOGIES Concluding Remarks on Modeling Languages

The FEAF does not recommend/specify any language. Currently, there is no single modeling language capable of modeling all aspects of an enterprise. Hence, meaningful and complete enterprise model development needs several languages (Bernus et al., 2003; Vernadat, 1998). Several general-purpose languages currently available are candidates. Using several languages not belonging to the same family (and not having the same underlying metamodel) creates challenges in maintaining consistency and interoperability. One potential solution currently under development is the proposed unified enterprise modeling language (UEML), which would be based on a common integrated set of metamodels, semantic rules, and language constructs (Vernadat, 1998). This initiative is still in its infancy and the hope to find a language that is able to accomplish all of EA modeling objectives is still farfetched. The architect must therefore choose language(s) appropriate to project requirements. Several general-purpose languages currently available are candidates and they include: A formal methodology seeking to fulfill GERA requirements must: 1. 2. 3. 4. 5. 6. Identify and elaborate the phases involved in the architectural development life cycle, Specify the scope and intent of each phase, Describe the required inputs and expected outputs of each phase, Include activity and task level elaborations of each phase, Provide guidance to progress through the phases, and Furnish any supporting materials that may be useful in the EA pursuit.

In addition, GERA has several requirements for modeling methodologies, which include: 1. The criticality of human involvement in architecture development for overall program success. The need to differentiate between useroriented and technology-oriented design,

2.

A Synergistic Assessment of the Federal Enterprise Architecture Framework

3.

4.

impacting the extent of automation required by the enterprise. The need to utilize and imbibe accepted project management techniques and practices leading to increase in the extent of management and control. The need to provide due consideration to economic and performance factors to facilitate justification of the initiative and alignment with business objectives.

The FEAF Methodology

The FEAF EA process is a detailed architecture development methodology that fulfills all requirements of a comprehensive and guided step-bystep approach as mandated by GERAM. While

the FEA framework provides valuable inputs on the content of enterprise architectures, a federal level guidance specifically addressing issues like conceptualizing, realizing, implementing, operating, and maintaining an EA is also available to interested organizations (CIO Council, 2001). This treats an EA program as a project with specific activities and deliverables in each phase, allowing enterprises to follow a disciplined and structured approach to architecture development. The EA process is not a framework specific EA methodology. The decision to choose the specific framework for implementation is left to the organization. Besides the methodology, the FEAF also recognizes and recommends the establishment of EA governance structure for overall success. The recommended governance

Table 1. Partial list of candidate modeling languages for FEAF documentation

Architectural Phases Key Phase Artifacts Request for architecture work. Initial statement of architecture work. Architecture principles. Architecture vision. Baseline architectures. Proposed Modeling Languages

Architecture visioning

Rich pictures / English.

Business architecture

Statement of architecture work. Business principles. Target business architecture. Business architecture views. Gap analysis report.

Rich pictures / English. UML. System dynamics. BPMN/BPML. OCL. Structured English. IDEF 0 & IDEF 3. ORM. EPC. IDEF 1. UML. ERM. ORM. UML. Structured English.

Information architecture

Target information architecture. Information architecture views. Gap analysis report. Impact analysis report. Target application architecture. Application architecture views. Gap analysis report. Impact analysis report. Technology baseline description. Technology principles. Target technology architecture. Gap analysis report. Impact analysis report. Technology architecture views.

Application architecture

Technology architecture

FEAF format. Rich pictures / English.

A Synergistic Assessment of the Federal Enterprise Architecture Framework

structure is in the form of: (1) setting an executive steering committee, providing management oversight and sponsorship to the EA initiative and (2) forming an EA program management office to manage, monitor, and control development and maintenance of the EA. Investment management is closely associated with the EA processes. Within the context of FEA, organizations are required to configure investments that make the organizations move toward the target architecture and these investment decisions should comply with the sequencing plan. The CIO Council recommends the use of General accounting offices information technology investment management framework in this regard (United States General Accounting Office, 2004). At Level IV, the FEAF is based on the Zachman framework. Various tool vendors have developed proprietary methodologies for the Zachman framework.

Concluding Remarks on Methodologies

The FEAF, while providing guidance to EA development, still maintains its generosity, allowing enterprises to choose appropriate methodologies. Integration with investment management framework further facilitates monitoring and control of EA initiatives financial goals and objectives. Mandating a strong management structure and control enables organizations to make informed and reasoned decisions and enforces discipline. Agencies can further monitor the efficacy of their methodologies by assessing the EA program using the five-level enterprise architecture management maturity model (EAMMF) on completion, use, and results dimensions, thus improving overall architectural practices (United States General Accounting Office, 2003).

The NASCIO EA Toolkit REFERENCE MODELS

To facilitate EA adoption, the National Association of State Chief Information Officers (NASCIO) provides an enterprise architecture development toolkit (NASCIO, 2004). The toolkit organizes the complete EA into four sub-architecture sections, namely: business architecture, information architecture, technology architecture, and solution architecture. In addition, it also has a section on architecture governance and management. Each section consists of a glossary of relevant terms, the detailed development process represented as workflow activities, including roles expected to perform specific activities, input and outputs items produced, templates and facilitation guides to derive the blueprint items, complete with examples and illustrations. Used in conjunction with the FEAF methodology, the toolkit is a rich source of guidance for all adopting agencies and meets GERA requirements and expectations. Well-developed enterprise architectures have the capability to capture, classify, and encapsulate enterprise knowledge. Complete or partial reuse is the only reason to justify management of enterprise knowledge. In the case of enterprise architectures, reference models (also called partial enterprise models) facilitate such reuse. Applicability of reference models becomes narrow and focused as their specificity increases. Hence, the extent of reuse depends on the depth of reuse and the breadth of reuse. Reference models are used to increase overall modeling efficiencies, requiring enterprise specific adaptation. Partial enterprise models in the GERA sense may capture some common part of a class of enterprises; represent prototypes or abstract models that require specialization and adaptation before being realized as enterprise specific models. GERA categorizes partial models into four groups, which are:

0

A Synergistic Assessment of the Federal Enterprise Architecture Framework

1. 2. 3.

4.

Partial human role models focusing on organization and responsibilities, Partial process models with focus on business processes and services, Partial technology models providing industry specific common description of resources and their aggregations, and Partial models of IT systems describing the components needed communications and information processing to enable enterprise integration.

The FEAF Reference Models

The FEAF explicitly defines the notion of reference models by specifying several reference models to facilitate cross organization analysis and improvement (CIO Council, 1999). From a business perspective, the FEAF specifies two reference models. The performance reference model (PRM) provides a common set of generic performance measures for organizations to achieve business goals and objectives (FEAPMO CRM, 2006). The PRM is designed for three main purposes: 1. Facilitate enhanced IT performance information to improve strategic and operational decision making. Improve business-IT alignment, thereby creating a clear line-of-sight to desired results. Identify performance improvement opportunities spanning organizational structures and boundaries.

2.

3.

The business reference model (BRM) on the other hand describes the business operations and services of the enterprise (in this case the federal government) independent of the specific organizations that perform them, including services performed by state and local government (FEAPMO CRM, 2006). The BRM, which forms a critical component in specifying the overall services blueprint of the enterprise, is organized

into four business areas, 39 lines of business, and 153 sub-functions. Together the PRM and the BRM owned by line of business owners, map to GERAM partial process and partial human model requirements. While the mapping to partial process model requirements against BRM is direct, the intent of the partial human model requirements is covered by the PRM through identification of organizational inputs, outputs, and outcomes along with key performance indicators. These can be mapped to organization and responsibilities as required by GERAM. From a technology perspective, the FEAF specifies three reference models. The service component reference model (SRM) identifies and classifies application components that support the organizations and facilitate reuse of these components (FEAPMO CRM, 2006). The SRM is categorized into seven service domains differentiated by business-oriented capability they represent. The data reference model (DRM) describes at an aggregate level, the type of data and information along with their relationships required for supporting program and business line operations (FEAPMO DRM, 2006). The technical reference model (TRM) describes the use of technology in delivering business services and relevant standards for implementing the technology (FEAPMO CRM, 2006). The TRM is comprised of four core service areas that include: service access and delivery, service platform and infrastructure, component framework, and service interface and integration. The TRM can be mapped to GERAM partial technology model requirements as the TRM focuses on the technology infrastructure required for delivery of business services identified in the BRM. The SRM and DRM together cover the requirements of GERAM partial models of IT systems. A study of the FEAF reference models reveals that the intent of GERAM partial enterprise models is covered in totality, though as expected the approaches taken to categorize the models and their intent differ.



A Synergistic Assessment of the Federal Enterprise Architecture Framework

Concluding Remarks on Reference Models

An architecture framework like FEAF must provide constructs, frameworks, and guidelines to develop these models to be GERAM compliant. By providing templates, reference models play a significant role in reducing this complexity and accelerating the architecture initiative. Reference models are created either by specializing generic models or generalizing specific models, thus requiring a strong validation process. The FEAF largely meets the GERA partial enterprise model requirements, though mechanism to create executable partial models would greatly enhance ease of implementation (Noran, 2003).

Tools for the FEAF

In the current state of affairs, there is no single toolset that meets all requirements of an EA project in general and an EA project using the FEAF in specific. The situation is further exacerbated by: (1) existence of several competing architecture frameworks that are available for organization to adopt and (2) non-availability of a comprehensive EA language based on a common underlying metamodel. These factors encourage EA tool vendors to support multiple architecture frameworks and myriads of languages, lest they reduce tool marketability and acceptance. The FEAF is not prescriptive about any specific toolset, but explicitly includes tool selection as a mandatory activity in the architecture development life cycle. It further provides criteria that can be used to make such a selection. Table 2 provides a summary of tools and their generic enterprise architecture capabilities (Arbab et al., 2002). Note that ++ depicts primary functionality and + depicts secondary functionality.

TOOLS FOR ARCHITECTING ENTERPRISES

There can potentially be a large number of requirements for EA tools; GERAM identifies a few vital high-level requirements in this respect and expects organizations to select appropriate tools based on their requirements. GERAM is not normative in recommending tool selection criteria. The core requirements specified by GERAM are: 1. Support for analysis and evaluation of enterprise models allowing model enactment through simulation. Comprehensive user guidance and embedded architecture development process. Support for collaborative as well as individual design and engineering activities. Provision of shared repository of all reference models, informal design descriptions and patterns, document, etc. Ability to incorporate engineering of both products and enterprises. Forward and reverse engineering capabilities.

Concluding Remarks on Enterprise Architecture Tools

In the absence of a single EA modeling language and existence of several architecture frameworks, it is challenging to find a tool that is sufficient to complete all aspects of architecture development. Organizations thus need to use multiple languages and tools to accomplish the stated objectives of an EA initiative. Use of multiple languages and tools creates challenges in model interoperability and integration.

2. 3. 4.

5. 6.

ADDITIONAL ASPECTS OF ANALYSIS

This section aims to cover the remaining GERAM components and also identify areas where the



A Synergistic Assessment of the Federal Enterprise Architecture Framework

Table 2. Partial list of enterprise architecture tools and their capabilities

Management ++ ++ Process & organization modeling Information management modeling Software & system modeling Repository ++ + ++ ++ + + ++ ++ ++ + ++ + ++ ++ ++ + + + + + +

Aris Toolset Asg-rochade Enterprise Architect Front Arena Enterprise Troux Microsoft Visio Ms Visual Studio .net Ptech Framework IBM Rational Rose Select Enterprise System Architect Tivoli Enterprise

++

FEAF goes beyond GERAM specifications. Aspects analyzed in this section include: ntity types and their recursivity: The E GERAM explicitly states that the life cycle of more than one entity may be related to each other. GERA incorporates the concept of entity types and identifies five recursive entity types, which are: (1) strategic enterprise management entity, (2) enterprise engineering entity, (3) enterprise entity, (4) product entity, and (5) methodology entity. nterprise modules: Similar to component E based software engineering, GERAM also recommends the use of pre-built components/modules and incorporate an assembly based approach to enterprise architecture. reas for improvement in GERAM: This A chapter assesses the FEAF against GERAM requirements. However, the assessment also

reveals at least three critical areas where GERAM is found to be weak and these have been discussed briefly.

RECURSIVITY OF ENTITY TYPES IN THE FEAF

The FEAF does not explicitly mention the concept of entity types, though the four levels of succession in the FEAF recognize the notion of entity types, as each level could ideally be performed by a different entity and involves activities in increasing details and granularity. However, the framework is compatible with GERAM requirements on recursion. This is evident in the way the FEA reference models are sequenced (CIO Council, 1999). This allows organizations to progress through the architecture development in a continuum through time, where different groups (entities) perform different activities, but



A Synergistic Assessment of the Federal Enterprise Architecture Framework

maintaining bidirectional traceability along the reference model continuum.

Architecture Governance and Management

This involves specifying the decision rights and the accountability framework required to encourage the desirable use of the EA. From a practical perspective, this entails establishing a control mechanism over the development, implementation, and continued evolution of all EA elements and components. A key requirement for any EA program (and also in the FEAF) is compliance to the EA (CIO Council, 2001). Practice has revealed that if individual IT initiatives within the enterprise are not required to comply with the EA, then the EA program itself faces the danger of irrelevancy. To address such issues, the FEAF strongly recommends the establishment of a central EA office within the organization. From this point of view, GERAM is found to be weak. Key governance mechanisms recommended within the FEAF include: 1. 2. Conducting architecture readiness assessment at the start of the EA program. Setting up the architecture program management office and other roles like the architecture review board. Establishing architecture principles. Defining architecture compliance review process. Defining architecture life cycle processes.

ENTERPRISE MODULES IN THE FEAF

In the FEAF, a component is defined as: A self contained business process or service with predetermined functionality that may be exposed through a business or technology interface (FEAPMO CRM, 2006). Components as architecture building blocks are clearly evident and explicit in the FEAF. The FEAF specifies components at increasing levels of granularity that include: federated component, business component system, business component, and distributed component. The SRM, which is the base reference model recommending a component-based approach, is organized into three levels with service domains followed by service types and components. There are seven service domains that categorize service capabilities from a business perspective. The 29 service types elaborate and categorize service capabilities within a specific service domain. Lastly, the 168 components are the building blocks with their interface specifications of a business or application service component (FEAPMO CRM, 2006). Thus, the concept of enterprise modules as architecture building blocks is directly compatible with the FEA components.

3. 4. 5.

Architecture Effectiveness Assessment

EA, when treated as a program as suggested by the FEAF (CIO Council, 2001), is a long-term and an ongoing effort. The challenge thus is to create and sustain senior management and stakeholder interest. In this regard, one of the key components of the EA program is to establish a set of metrics early in the program life cycle that can be used: (1) as a way to manage stakeholder expectations from the EA program, and (2) as a mechanism

AREAS FOR IMPROVEMENT IN GERAM

Interestingly, the assessment presented in this chapter revealed three areas where there is scope for improvement in the GERAM. From the authors experience, these have been found to be critical to the overall success of the EA program.



A Synergistic Assessment of the Federal Enterprise Architecture Framework

to evaluate and communicate the success and effectiveness of the EA program. GERAM makes no mention of such metrics, while this is a key component within the FEAF driven initiatives (NASCIO, 2004). The FEAF recommends that agencies identify EA effectiveness metrics to support their architecture goals and objectives. Typical architecture objectives include, but are not limited to: 1. 2. 3. 4. 5. 6. Cost reduction, Higher business value of IT, Flexible IT, Cheaper and faster solutions/acquisitions, Reduction in project failures, Integration and interoperability of information services,

Adoption of service-oriented architecture (SOA), 8. Service quality guarantee, 9. Compliance, 10. Efficient portfolio management, and 11. Risk reduction.

7.

Touch-Points with Organizations Other Activities

EA provides several benefits to the agencies, especially on issues concerning procurement and decommissioning of IT solutions. Hence, it is critical for the agencies to understand and acknowledge the fact that EA has very logical touch-points with

Table 3. Linkages of agency EA program to other activities

Activity Nature of linkage from the EA program IT governance is the process of specifying the decision rights and the accountability framework to encourage desirable behavior in the use of IT. The linkage between EA and IT governance is most extensive in architecture governance as this is derived from IT governance. Agencies can benefit from key IT governance mechanisms (like IT leadership committee, IT investment evaluation board, architecture committee, chargeback agreements, etc.) in utilizing them as architecture governance mechanisms. Another area where the linkage is strong is IT policies. When defining architecture principles, agencies must strive to derive them from the agencys IT policies. Typically, an EA blueprint results in identifying IT projects and initiatives that help an organization transition toward the target architecture. The identified IT projects and initiatives lend themselves very well to populating the organizations IT portfolio. In other words, the IT projects in the EA programs feeds into the IT portfolio, which can then be categorized and administered as a portfolio asset mix to balance risks and returns (Saha, 2004b). EA is a more upstream activity, while IT project management represents downstream activity. The linkage between EA and project management happens through the fact that IT project management facilitates the agencys transition to the target architecture using a series of IT projects and initiatives. Individual projects should utilize the EA blueprint as the main source of their business requirements, business case development, and for understanding the interdependencies between the various projects. The EA blueprint provides the big-picture view. From a governance perspective as each executed project takes the agency toward the target architecture, it must also demonstrate compliance to the agency blueprint at all times. This is accomplished through conducting regular architecture compliance reviews. An agencys strategic IT plan represents its long term IT plan and projects usually in-line with its strategic business plan. EA provides a very disciplined approach to identifying and prioritizing IT projects and initiatives, which can then become part of the strategic IT plan for a specific period of time (usually 3 or 5 years). The linkage in this case is in the area of EA effectiveness metrics. Organizations usually derive their IT scorecard from their balanced scorecard (BSC). IT scorecard metrics can be categorized into four perspectives, namely, corporate contribution, customer orientation, operational excellence, and future readiness. The EA program plays a critical role in positively impacting IT scorecard metrics across all perspectives. While there is no direct impact of the EA into the strategic planning exercise, it has been noticed that successful EA programs usually elevate the role of the IT department within the organization. As a result organizations with mature EA programs tend to include IT as a key resource and asset in executing business strategies through a series of strategic programs and initiatives.

IT governance

IT portfolio management

IT project anagement

Strategic IT planning

IT performance management

Strategic planning



A Synergistic Assessment of the Federal Enterprise Architecture Framework

other key organizational activities. GERAM does not make any explicit mention about the type and intensity of impact the EA program can have on some of the organizations other activities. The FEAF on the other hand recognizes these. Table 3 lists the organizational activities that the EA programs has linkages to and also briefly describes the nature of such linkages.

not in concepts. In this regard, two points to be noted are: The FEAF is still evolving and it is highly likely that eventually it would map to GERAM even further, as a common set of requirements also has the potential to assist in the evolution of enterprise architecture practice. The discipline and practice of enterprise architecture is also evolving, hence every architecture framework hopes to set trends rather than follow it, in order to maintain its comparative advantage.

FINAL CONCLUSION
Reducing complexities, enhancing standardization, and disseminating best practices are some of the crucial recurring themes in EA practice. Standardization helps an organization to ultimately reap the benefits of economies of scale and scope. This is one of the critical goals of the FEAF. However, the advancement of practice in EA by the FEAF is limited due to the absence of a single unified architecture development language based on a common underlying metamodel. Using GERAM as a meta-framework, the assessment revealed that FEAF largely fulfills all the key GERAM concepts. By providing a generalized set of requirements, GERAM / ISO15704:2000 is an excellent baseline to map and assess candidate architecture frameworks like the FEAF. GERAM is not to be viewed as a competitor to the FEAF or any other framework. Rather, it represents a minimum set of requirements that constitute enterprise architecture practice. Such a baseline allows enterprises and architects to assess various candidate reference architectures and choose the most appropriate one based on their specific business needs. This makes the rationale for choosing a specific framework correct and reasoned and not impulsive and swayed by hype. It is clearly evident from the analysis in this chapter that the FEAF largely meets GERAM requirements and also exceeds them in a few areas. The few areas where the FEAF is found to be deficient are limited to guidance and specifications only and

GERAM at this instance is found weak in areas of (1) architecture governance and management, (2) architecture effectiveness metrics, and (3) linkages that a typical EA program might have on the organizations other related activities. From a practical perspective, these are critical to sustain the EA practice within an organization. Similarly, it is near impossible to get key stakeholder buyin in the absence of metrics that can be used by organizations to demonstrate and communicate the effectiveness of the EA program. Nonetheless, an assessment of this nature is beneficial to ensure the continued relevancy of GERAM as a meta-framework for EA.

REFERENCES
Arbab, F., Bonsangue, M., Scholten, J. G., Iacob, M. E., Jonkers, H., Lankhorst, M., Proper, E., & Stam, A. (2002). State of the art in architecture framework and tools. Telematica Institut Version 1.2. Bernus, P. (2001). Some thoughts on enterprise modeling. International Journal of Production Planning and Control, 12(2), 110-118.



A Synergistic Assessment of the Federal Enterprise Architecture Framework

Bernus, P., Nemes, L., & Schmidt, G. (2003). Handbook on enterprise architecture. BerlinHeidelberg: Springer-Verlag. Bernus, P., Nemes, L., & Williams, T. J. (1996). Architectures for enterprise integration. London: Chapman & Hall. Chen, D., & Doumeingts, G. (1996). The GRAIGIM reference model, architecture, and methodology. In P. Bernus, L. Nemes, & T. J. Williams (Eds.), Architectures for enterprise integration. London: Chapman & Hall. Chen, D., Vallespir, B., & Doumeingts, G. (1997). GRAI integrated methodology and its mapping onto generic enterprise reference architecture and methodology. Computers in Industry, 33(3), 387-394. CIO Council. (1999). Federal enterprise architecture framework, Version 1.1. Retrieved from http://www.whitehouse.gov/omb/egov/a-1-fea. html CIO Council. (2001). A practical guide to federal enterprise architecture, Version 1.1. Retrieved from http://www.gao.gov/bestpractices/bpeaguide.pdf FEAPMO DRM. (2005). The data reference model, Version 2.0. Retrieved from http://www. whitehouse.gov/omb/egov/a-1-fea.html FEAPMO CRM. (2006). FEA consolidated reference model, Version 2.0. Retrieved from http:// www.whitehouse.gov/omb/egov/a-1-fea.html IFIP-IFAC Task Force. (1999). GERAM: Generalized enterprise reference architecture and methodology. IFIP-IFAC Task Force on Architectures for Enterprise Integration, Version 1.6.3, (March). Morabito, J., Sack, I., & Bhate, A. (1999). Organization modeling: innovative architectures for the 21st century. Upper Saddle River, NJ: Prentice Hall PTR.

NASCIO. (2004). Enterprise architecture development toolkit Version 3.0. Retrieved from http://www.nascio.org Noran, O. (2003). An analysis of the Zachman framework for enterprise architecture from the GERAM perspective. Annual Reviews in Control, 27, 163-183. Noran, O. (2005). A systematic evaluation of the C4ISR AF Using ISO 15704 Annex A (GERAM). Computers in Industry, 56(2005), 407-427. Saha, P. (2004a). Analyzing the open group architecture framework (TOGAF) from the GERAM perspective. The open group architecture forum, TOGAF White Papers, (October). Retrieved from http://www.opengroup.org/architecture/wp/ Saha, P. (2004b). A real options perspective to enterprise architecture as an investment activity. The Open Group Architecture Forum, TOGAF White Papers, (November). Retrieved from http:// www.opengroup.org/architecture/wp/ Spewak, S. H. (2002). Enterprise architecture planning (2nd ed.). NY: John Wiley & Sons. United States General Accounting Office. (2003). A framework for assessing & improving enterprise architecture management, Version 1.1. Retrieved from http://www.gao.gov/new.items/d03584g. pdf United States General Accounting Office. (2004). Information technology investment management: A framework for assessing process maturity, Version 1.1. Retrieved from http://www.gao.gov/new. items/d04394g.pdf Vernadat, F. B. (1998). The CIMOSA languages. In P. Bernus, K. Mertins, & G. Schmidt (Eds.), Handbook of information systems (pp. 243-263). Berli-Heidelberg: Springer-Verlag. Zachman, J. A. (2000). Enterprise architecture: A framework. Retrieved from http://www.zifa. com



18

A Minimalist Framework for Modern Times

Phil Robinson Lonsdale Systems, Australia Floris Gout Independent Consultant, Australia

Extreme Architecture Framework:

Chapter II

ABSTRACT
As consultant-educators, the authors created the extreme architecture framework (XAF) in order to quickly grasp an understanding of an organisations architecture from different perspectives. The framework is presented as a matrix of system types and architectural perspectives that is described by a single uncluttered diagram. Elements within the framework are defined along with the content that can include architectural representations, planning, and governance information. A discussion follows to show the relationship of the framework to planning, development, and governance activities. The minimalist framework presents a consolidated view of both human activity and software systems and can also help to foster a shared understanding between IT groups and business areas. It has been designed to answer a managers questions: Which elements of the enterprise do I need to be aware of and understand; and Which elements am I responsible for and need to manage?

INTRODUCTION
The enterprise architecture framework described here evolved slowly over a period of time. It has been heavily influenced by the assignments un-

dertaken by the authors who consult to a variety of clients across a range of industry sectors. In presenting yet another framework, it is not the authors intention to reinvent the wheel but rather to synthesise some of the best ideas in

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

Extreme Architecture Framework

the field of enterprise architecture and inject a healthy dose of experience in order to create an enterprise architecture framework that has strong conceptual foundations but can also be applied to practical situations. Early in the evolution of the framework, both authors were introduced to the ideas advocated by the extreme programming (XP) community (Beck, 2000). XP is a lightweight but highly rigorous approach to software development that the authors originally sought to emulate in their architecture framework. The extreme in XP refers to the way in which well-established best practices have been taken to the extreme. In the area of enterprise architecture, there is less consensus on what represents best practice. This also means that there is less opportunity to develop extreme practices. In fact, as the extreme architecture framework (XAF) evolved, it became obvious that the extreme in XAF was in fact a pun. The XAF is best described as a lightweight pragmatic approach to enterprise architecture that avoids the extremes of perfection and chaos. In contrast to other architecture frameworks the XAF: Is easy to describe. Encourages an agile approach to architectural work products. Unifies a number of disparate disciplines. Offers a simple, consistent view to the various parties involved in the management of enterprise resources.

The remainder of this chapter describes how the XAF attempts to present a unified view of human activity and software systems from the three perspectives of business processes, information systems, and technology infrastructure. The unified view attempts to strike a balance between architectural perfection and the inevitable chaos when there is an absence of architecture. The XAF embodies three guiding principles: 1. 2. The contribution of frameworks themselves. The need for interoperability between systems whether they be human or software systems. The various different architectural perspectives that are required to be managed (IEEE Computer Society, 2000).

3.

The chapter concludes with a description of how elements of the enterprise can be organised into groupings that reflect the disciplines responsible for building and managing the enterprise. The XAF is a perfect mechanism for highlighting these grouping and revealing the nature of the relationship between them.

BUILDINGS, URBAN DISTRICTS, SOFTWARE, AND ARCHITECTURE

A clear and simple definition of what constitutes architecture can be difficult to achieve. The authors like this definition of building architecture that was provided by Ean MacDonald, a retired architect (e-mail communication October 5, 2003). Architectural design is the simultaneous resolution and solution of the various architectural problems including location, aspect, and prospect, sun, wind, and weather, materials and method, finance, function, and form, to which may be added a dash of flair that can make a structure work of art.

Above all, the XAF can be used to answer the two questions most often asked by the authors clients (frequently IT managers and chief information officers): Which elements of the enterprise do I need to be aware of and understand; and Which elements am I responsible for and need to manage?

19

Extreme Architecture Framework

Surprisingly, the view that architecture can be both a science and an art is shared by some software architects. Roger Pressman describes architecture as representations of a software system that allow software engineers, to (1) analyse the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce risks associated with the construction of the software. (Pressman, 2005, p. 288) At the same time, he unashamedly notes that architecture is an art (Pressman, 2005, p. 287). Based on the opinions of these two architects working in different fields, it seems that architecture is intended to provide both functional design and aesthetic appeal. Before presenting the XAF in detail, it is useful to further explore a metaphor that equates buildings with software systems and the urban landscape with enterprises. In his well-known essay on software architecture, Brooks (1995, p. 42) cites the building of the cathedral at Reims as a triumph of architectural vision. According to Brooks, eight generations of highly skilled builders sacrificed their own

ideas in order to maintain the design integrity of the cathedral. In describing the cathedral, Brooks states: the joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. Brooks offers the triumph of Reims as a sort of Holy Grail for software developers. In stark contrast, the authors of the Big Ball of Mud Pattern describe what they claim is the most frequently adopted software systems architecture. They use the metaphor of a shantytown structure to describe the software architecture and point out that the buildings are: built from common, inexpensive materials and simple toolsusing relatively unskilled labor. (Foote & Yoder, 1999, p. 7)

Figure 2. The shantytown

Figure 1. The cathedral

20

Extreme Architecture Framework

Foote et al. argue that there are a number of reasons why the big ball of mud is common: Pressure on project schedules and costs. Inexperience, lack of skills and high staff turnover. The complexity and rate of change of the software requirements.

Care must be taken not to mix metaphors. The Reims metaphor is based on the architecture of a single building while the shantytown metaphor is simultaneously based on the architecture of

buildings and a chronic lack of urban planning. Urban planning involves laying out the streets and amenities for a suburb and planning the provision of services such as water, electricity, and telephone. Individual residents of the suburb are free to build whatever style of house they desire providing it conforms to the building standards and guidelines laid down for the suburb. An example of urban planning that equates to the construction of Reims is the planning of Canberra, Australias national capital, by Walter Burley-Griffin. It is true that modern-day Canberra does not have the casino, trams, or sole

Figure 3. The 1912 plan of Canberra

21

Extreme Architecture Framework

residential centre envisaged by Griffin. However, the overall layout of Canberra and its capital is instantly recognisable in the original 1912 plan. In contrast to Canberra, a shantytown represents an extreme lack of urban design resulting in opportunistic utilisation of space that has adverse affects on land use and the shantytowns residents. These metaphors provided the starting point for the XAF. Reims and Canberra reflect the extremes of architecture as art. Reims was built as a symbol of glorification and Canberra as a symbol of national pride. At the opposite extreme, a shantytown suffers from a complete absence of urban planning and is built from whatever comes to hand. The result is misery for the towns inhabitants and degradation of the environment. Confronted by these two extremes, the authors found themselves drawn to what the Buddhist faith calls the middle path.

avoiding the extremes gives vision and knowledge and leads to calm, realization, enlightenment. (Thera, 1958) It is a fact that most architects and urban planners spend the majority of their time following the middle path. Few are involved in the planning of entire cities or the design of cathedrals. Instead, the majority of architects and planners spend their time designing suburban houses and planning the layout of residential suburbs. This simple reality offers the perfect metaphor of a suburban house in a residential suburb sitting between the two extremes of perfection (Reims, Canberra) and chaos (shantytown). The precise choice of architectural elements used to describe an enterprise provides the structure of an enterprise architecture. The selected elements must interact with each other in a con-

Figure 4. The suburban house

Figure 5. The middle path

22

Extreme Architecture Framework

sistent manner in order to provide a holistic view of the enterprise. An enterprise architecture framework provides support by serving as a checklist to identify the actual enterprise elements1 that describe an enterprise. The structural integrity of an enterprise architecture is maintained by carefully defining the relationships between architectural elements and ensuring that framework will highlight the impact of change.

THE NEED FOR FRAMEWORKS

The use of frameworks to provide structure and support is a common practice in many disciplines. The role of frameworks can be illustrated by returning once more to the building metaphor. There is a style of building that involves first constructing a steel or wooden frame and then cladding it with a suitable material. The frame defines the structure of the building and provides

support while the cladding provides shelter and aesthetic appeal. Maintaining the exterior of such a building is a simple matter of replacing worn or damaged sections of the external cladding. When required, the appearance of a building can be completely renovated by simply replacing the cladding. Maintaining or renovating the exterior of a building with a frame has no impact on the structural integrity of the building. To summarise, the role of a buildings frame is to provide structure and support while maintaining structural integrity in the face of change. Enterprise architecture frameworks provide structure, support, and integrity in much the same manner as the frame of a building: There are a plethora of enterprise architecture frameworks. For those interested, Shekkerman (2004) offers a useful inventory of the more important frameworks. The three frameworks that have had the greatest influence on the XAF are listed next:

Figure 6. A building framework

23

Extreme Architecture Framework

The Zachman framework (Zachman, 1987) is perhaps the best-known enterprise architecture framework. The presentation of the XAF as a matrix reflects the influence of this framework. The NIST framework (Fong & Goldfine 1989) is one of the earliest enterprise architecture frameworks and has had a strong influenced on many subsequent frameworks. The architectural views adopted by the XAF as matrix columns, reflect the influence of this framework. The TOGAF framework (The Open Group, 2003) is a comprehensive enterprise architecture methodology that places great emphasis on interoperability between systems. The influence of this framework on the XAF is reflected in the choice of systems as matrix rows.

factors that are far more abstract and often quite difficult to measure. Figure 7 shows the classification of human activity and software systems on which the XAF is based. There are three categories of human activity system: 1. An industry sector is a system of interacting enterprises that are all engaged in a similar type of activity. Travel, banking, and education are all examples of industry sectors. An enterprise is a collection of individuals performing systematic and purposeful activities in support of a well-defined mission. Travel agents, airlines, banks, and educational institutions are all examples of enterprises. A business process has been defined as a sequence of activities that produce outputs of value to the customers of the process (Hammer & Champy, 2003). Hotel or airline reservations, funds transfer, and student enrolments are all examples of business processes.

2.

3.

SYSTEMS AND INTEROPERABILITY

Although useful at a superficial level, the building and urban planning metaphors for enterprise architecture have quite important limitations. Buildings are static structures that interact minimally with their environment. Services such as water, gas, electricity, and access roads are well defined and change infrequently. Fundamental to the XAF is the concept that an enterprise can be regarded as a collection of human activity and software systems exhibiting purposeful design (Checkland & Scholes, 1990, p. 21-22). In contrast to the static nature of buildings, human activity, and software systems are highly dynamic and interactive. While the design integrity of a building is determined by factors such as geometric proportion, structural strength, and the materials used for construction, the design integrity of human activity and software systems is determined by

There are two categories of software system: 1. A software application is a mechanism for packaging and physically deploying a collection of software functions that are designed to support one or more business processes.

Figure 7. Hierarchy of enterprise systems

Industry Sector Enterprise Business Process Application Component Human Activity Systems

Software Systems

24

Extreme Architecture Framework

2.

A software component is a piece of software that can be easily replaced by another piece of software and can potentially be reused in a number of different applications. A reservations Web service provided by an airline, a calendar visual component, a banking database, and a reusable computerbased training module are all examples of components.

another enterprise or that a software application may only support a single business process. While the hierarchical and nested representations of enterprise systems may have been convenient in the past, there are a number of factors in the modern business environment that now make this perspective somewhat less valid: It is common for business processes to be outsourced. This means that more than one enterprise can have responsibility for a business process and invalidates the notion of a business process being nested inside a single containing system. It is now normal practice for people outside an enterprise, such as customers, agents, and suppliers, to interact directly with the enterprises software applications. This invalidates the notion that software applications are nested inside business processes that are in turn nested inside an enterprise. Modern software development techniques emphasise the creation of reusable software components. This invalidates the notion that a software component is nested inside a

The enterprise systems shown in Figure 7 are organised into a hierarchy. This is a common representation of enterprise systems that emphasises their composition. The hierarchy of systems suggests that industry sectors are composed from a number of enterprises, enterprises are composed from a number of business processes, and software applications are composed from a number of software components. Another common representation of enterprise systems is to show them nested one inside the other. This perspective suggests that an individual system can only interact with the system that contains it or the other systems sharing the same container. This implies that a business processes may not interact with the business processes of

Figure 8. Independent and overlapping nature of enterprise systems

Industry Sector Enterprise Business Process Application Component Component Component Application Industry Sector Enterprise Business Process Application

25

Extreme Architecture Framework

single software application since the goal is to reuse a component many times in order to construct a variety of software applications. In addition, the recent trend toward internet Web services means that an entire industry sector can use the services provided by a single software component thus invalidating the entire hierarchy of systems. For these reasons, the authors believe that it is more realistic to view the human activity and software systems of an enterprise as a number of independent and overlapping systems. This representation is shown in Figure 8. Independent, overlapping systems are able to interact with each other in an unrestricted manner. For example: A single software applications may support a number of disparate business processes. A single business processes may extend across a number of different enterprises. A single software application may support the business process of a number of different, unrelated enterprises.

A software component may be designed to provide a suite of generic services that are used by one or more industry sectors.

Regarding human activity and software systems as independent and overlapping leads to an overriding requirement for interoperability between the individual systems. Interoperability can be defined as the ability of a system to successfully interact with other specified systems.

ARCHITECTURAL VIEWS
High levels of interoperability are unlikely to be found in enterprises that resemble a shantytown. Interoperability requires a high level of structural integrity in the interfaces between enterprise systems. As the builders of Reims and Canberra knew only too well, it is necessary to develop a detailed architectural plan and stick to it in order to achieve a high level of structural integrity. Describing a large building, town, or city is a complex task and for this reason architects and urban planners present their plans using a number of complimentary views. An urban planner might create one view to show the proposed subdivision of land. Another view might show the routing of services such as electricity, gas, water, and sewage. Additional views might include transportation, public amenities, or environmental concerns. For similar reasons, enterprise architectures are also normally presented as a number of complimentary views. Perhaps the best-known set of architectural views are those described in the Zachman framework (Zachman, 1987). The Zachman framework describes an enterprise using two orthogonal dimensions based on five enterprise roles (planner, owner, designer, builder, sub-contractor) and six English language imperatives (what, how, where, who, when, why). A different set of architectural views are described in the National Institute for Standards

Figure 9. The OMB architecture framework

Enterprise Architecture

Technical Reference Model Standards Profile

26

Technology

Information

Software

Activity

Data

Extreme Architecture Framework

and Technology (NIST) architecture framework (Fong et al., 1989). Following the enactment of the Clinger-Cohen Act in the United States, the NIST architectural views were endorsed by the Office of Management and Budget (OMB), which issued a directive requiring government agencies to develop enterprise architectures. The directive included an architecture framework based on the NIST framework. Since the enactment of the Clinger-Cohen Act, the U.S. government has unveiled a number of electronic government initiatives. To support these initiatives, the OMB has developed and published its federal enterprise architecture (FEA). In contrast to the original OMB reference architecture, FEA is more complex and closely aligned with the specific needs of the U.S. government. One of the attractions of the original OMB reference architecture is its simplicity. It has just three major components: 1. 2. 3. Enterprise architecture. Technical reference model. Standards profile.

technical environment in which software executes. The technical reference model is a comprehensive list of the generic services provided by the enterprises technology infrastructure. The list includes items such as: Data interchange services Data management services Graphics services Directory management services Network services Operating system services

The enterprise architecture consists of five architectural views that together describe the enterprise: 1. Activity architecture 2: Describes an enterprises high-level business activities and workflows. Information architecture3: Describes the information required to support the business activities described in the activity architecture. Software architecture4: Describes the software that is required to support the Activity and Information Architectures. Data architecture5: Describes the logical and physical structure of the enterprises software-maintained data stores. Technology architecture6: Describes the

2.

3.

4.

5.

The technical reference model groups the services into logical classifications rather than identifying specific products or solutions The TOGAF framework (The Open Group, 2003) includes a detailed example of a technical reference model. The standards profile is a collection of standards that fully specify the generic services identified in the technical reference model. Standards are fundamental to the achievement of interoperability between systems. Internally developed guidelines, de facto standards, and formal international standards may all be included in the standards profile. It should be briefly noted that the reference architecture described in the OMB directive does not exhaustively define an enterprise. A full understanding of an enterprise must include elements such as business strategy, culture, and values. These elements will influence the architecture in much the same way that financial, political, and social factors influence urban planning. The architectural views from the OMB enterprise architecture have been chosen as the basis for architectural views in the XAF because of their ease of understanding when compared to the architectural views presented in the Zachman framework. In the authors experience, most people readily understand the Zachman framework

27

Extreme Architecture Framework

views that are based on the six English language imperatives. However, many people struggle with the Zachman framework views that are based on the five enterprise roles.

THE EXTREME ARCHITECTURE FRAMEWORK

It is now time to introduce the complete XAF. The framework is presented as a matrix, which maps the orthogonal enterprise architecture dimensions of systems and architectural views. A

matrix format was chosen because the Zachman framework has demonstrated the power of mapping orthogonal dimensions coupled with the simplicity and universal appeal of presenting an architecture framework as a matrix. The rows of the XAF matrix are labelled with the five independent, overlapping systems previously described. The columns of the matrix are labelled with the five architectural views from the OMB reference architecture. The individual cells of the matrix are used to organise architectural content. The labels of the

Figure 10. The extreme architecture framework presented as a matrix

Activity Sector Enterprise Process Application Component Information Software Data Technology

Figure 4. The extreme architecture framework

Activity Sector
Activities Subject Areas Information Requirements Functional Areas Business Objects

Information

Software

Data

Technology

Enterprise
Workflow

Process
Networks Interface Requirements Functional Requirements Non-Functional Requirements Storage Requirements Platforms

Application

Use Cases

Architecture

Component

User Interface Code

Schemas

28

Extreme Architecture Framework

intersecting row and column classify the content of each cell. For example: The cell at the intersection of the sector row and the activity column contains content that describes the activities performed within an industry sector. The cell at the intersection of the process row and data column contains content that describes the data associated with a business process. The cell at the intersection of the application row and software column contains content that describes the requirements for an individual software application.

ARCHITECTURAL ELEMENTS
Each cell in the matrix contains a number of architectural elements that further refine the coarse classification scheme provided by the rows and columns of the matrix. Figure 4 shows the complete XAF with the 18 architectural elements added to the framework. Notice how some of the cells have been grouped together when they share similar content across a number of rows of columns. The most obvious examples are the grouping of sector, enterprise, and process into a single row representing human activity systems and the grouping of the entire technology column into a single cell. A necessarily brief description of the 18 architectural elements is given next. The descriptions are deliberately presented at a fairly high level of detail in order to facilitate the mapping of the XAF to other standards such as the unified modelling language (UML) or the integrated definition methods (IDEF) series of standards. Activities: Describe the business activities performed within a sector, enterprise, or business process.

Workflows: Describe the flow of physical objects and information between business activities. Subject areas: Classify and group information requirements having a common theme, subject areas can also be used to group businesses objects and storage requirements. A database7 is a special case of subject area that is actually implemented and physically deployed. Information requirements: Identify and describe the information required in order to successfully perform an activity as well as any information that is produced as an outcome of the activity. Functional areas: Used to classify and group functional requirements that have a common purpose. Functional areas can also used to group non-functional requirements, interface requirements, and use cases. Business objects8: Represent the concepts of interest within the sector, enterprise, or process. A useful scheme for classifying concepts of interest can be found in Peter Coads work which identifies the following categories (Coad et al., 1999, pp. 3-6): Business-related events and time periods. The roles of people, organisations, places, and things. The actual people, organisations, places, and things. Classifications of any of the above. Use cases: Describe the usage of a software application by identifying interactions between an actor (user) and the software (Jacobson, 1992). Each step in the interaction either provides some direct value to the actor or indirect value to the applications stakeholders. Use case steps provide value by: Enforcing business rules. Controlling a hardware device. Storing data. Presenting information to the actor.

29

Extreme Architecture Framework

Interface requirements: Provides a detailed description of either a user or software interface. Interface requirements may include detailed definitions for each of the data elements included in the interface. Functional requirements: Describe the mandatory capabilities, actions, and behaviour of a proposed software application. Non-functional requirements: Describes the requirements of a proposed software application that are not related to its capabilities, actions, or behaviour. Non-functional requirements include: Quality attributes of an application such as performance, usability, security, reliability, recovery, audit, and archiving. Application constraints relating to the software platform, the stakeholders, the external environment, the applications life cycle, and its design. Storage requirements: Describe data that will be permanently stored (persistent data). Storage requirements may include detailed definitions for each of the data elements included in the requirements. User interfaces: The physical screens reports and Web pages that a user interacts with. Architecture: Various high-level views of a software application. A useful scheme for classifying architectural views can be found in Hofmeister et al. (1999), which identifies the following views: Underlying conceptual organization of the software. The individual modules from which the software constructed. The organisation of the source code. The run-time deployment of the software. Code: The human readable source code that defines the software and the binary code that is executed.

Schemas: Defines an electronic data store in terms of the records (or tables) and the relationships between the records. Networks: The mechanisms that are used to interconnect hardware and software platforms to permit the transfer of data and invocation of remote of services. Platforms: The hardware, firmware, system software, and middleware required to deploy and execute a software application. Frameworks: Standard component models and/or reference software architectures such as J2EE or .Net.

ENTERPRISE ELEMENTS
The XAF architectural elements offer a checklist that can be used to identify the elements that actually describe a specific enterprise. The XAF uses the term enterprise elements to differentiate these elements from the architectural elements previously described. The following enterprise elements might be used to describe part of an enterprise architecture for a hotel: Activities: Accept reservations Check in guest Provide room service Provide laundry Check out guest Information Requirements: Guest details Room types Room availability Room maintenance schedule Room utilisation rate Functional Requirements: The system shall allow reservations to be created from guest history. The system shall allow reservations to be created for individuals or groups.

30

Extreme Architecture Framework

The system shall allow reservations for more than one room to be created. The system shall record the guests arrival date, time, and flight number.

ARCHITECTURE CONTENT
The XAF architectural elements also provide a classification scheme for architecture content. Each cell (or group of cells) in the framework matrix can contain different types of content. The content can be further classified into content that describes architectural elements or enterprise elements.

of the architecture itself can also be defined. For example, the principles of minimising data redundancy and duplication or the principle of performing data entry at the first point of data capture. Again this principle would apply equally to all information and storage requirements. A strategy or course of action to achieve a desirable, future state of an architectural element: For example, a strategy to facilitate transfer of data between business activities by integrating software applications using a hub and spoke architecture.

ARCHITECTURAL ELEMENT CONTENT

Content for architectural elements define the vision, principles, and strategies that guide the current functioning and future evolution of an enterprise. Typical content for this category of elements include: A vision of some desirable, future state of an architectural element and its associated enterprise elements: The vision should describe how the future state will contribute to business strategies and goals. For example, a vision that data will be seamlessly transferred between different business activities. This vision would apply equally to all business activities. An underlying principle associated with an architectural element: A principle is a short statement that guides or constrains some aspect of the architectural element. Principles tend to define fundamental aspects of an architecture that are infrequently changed or amended. Principles that actually guide the development and implementation

Content for architectural elements is normally associated with planning. It would also be possible to extend this area of the framework to incorporate balanced scorecard techniques (Kaplan & Norton 1990, 2004) as well as the planning models described by the Business Rules Group (Hall, Healy, & Ross, 2005, p. 1-2). The authors have experimented with synthesising the ideas from these thinkers into the framework.

ENTERPRISE ELEMENT CONTENT

Content for enterprise elements describes the detail of the enterprise. Typical content for this category of elements include: A model, list, or definition describing enterprise elements: For example, a list of the core business activities performed by a hotel, a glossary defining the key business objects that are relevant to the hospitality sector, or a UML model describing a hotel management application. An assessment or SWOT analysis of the current state of an enterprise element: For example, an assessment of data quality associated with hotel reservation data, or a SWOT analysis of the user interface of an existing hotel management application. As-

31

Extreme Architecture Framework

sessments might also refer to potential risks and rewards associated with the current state of the enterprise element. A potential risk associated with an enterprise element: For example, low customer satisfaction associated with the check in process at a hotel. A potential reward associated with an enterprise element: For example, a reduction in staff costs associated with an internet-based guest reservation system.

GROUPING FRAMEWORK CELLS

Although this chapter does not deal with the governance or development tasks associated with an enterprise architecture, the authors have found that the framework reflects aspects of both tasks. In addition to what can be regarded as the standard grouping of cells shown in the framework diagram above, cells of the matrix can be grouped in a number of other ways. Grouping cells is the main technique used to highlight focus areas of the framework.

context for the individual software applications of the enterprise. The requirements definition row defines the requirements for a single software application. The row includes the applications use cases, interface requirements, functional and non-functional requirements, data storage requirements, and an elaboration of technology requirements documents. It should be obvious that the content of this row also reflects the typical content of a requirement definition document. The software construction row describes the physical artefacts that together implement a single software application. Here are found the artefacts of software development such as user interfaces, software architecture, program code, and database schemas. Notice how a part of the technology column is included in all three of the rows. This would appear to reflect that the appropriate use of technology needs to be considered at all three levels.

COLUMNS
Partitioning the framework into columns also provides a major insight into the framework. The logical choice of names for the columns tends to reflect the management disciplines frequently tasked with the governance of the enterprise architecture. The process improvement column includes the elements that are the focus of business process reengineering projects or continuous improvement initiatives. Activities define the scope of the improvement while workflows define the improved processes. Use cases and user interfaces describe how a software application will support the improved process. The information management column includes the elements that need to be properly managed in order for an organisation to make effective use of information. It includes the grouping of information requirements into subject

ROWS
Partitioning the cells of the framework into rows and attempting to name them offers a major insight into the framework. The most obvious choice of names for the rows tends to reflect the major disciplines associated with the systems development life cycle. The business modeling row describes what the enterprise does and how its activities are supported by its software systems. The row includes the activities performed, workflows between activities, information requirements, business objects, a high-level grouping of software functions into a number of functional areas, and the technology platforms and networks used to support business activity. This row provides the

32

Extreme Architecture Framework

Figure 11. Partitioning into life cycle disciplines

Business Modelling
Activity Sector
Activites
Activities

Information

Software

Data

Technology

Subject Areas
Subject Areas

Functional Areas Functional Areas

Business Objects Business Objects

Enterprise Process

Workflow

Workflow

Information Information Requirements Requirements

Requirements Definition
Application
Use Cases
Use Cases

Interface Interface Requirements Requirements

Functional Functional Requirements

Requirements Non-Functional Functional Requirements

Networks Networks

Non-

Storage Storage Requirements Requirements

Platforms Platforms

Frameworks

Frameworks

Requirements

Architecture Architecture

Component

User Interface User Interface

Code Code

Schemas Schemas

Software Construction

Figure 12. Partitioning into management disciplines

Process Improvement Software Portfolio Management Infrastructure Management

Activity Sector
Activities

Information

Software

Data

Technology

Subject Areas Information Requirements Functional Areas Business Objects

Enterprise
Workflow

Process
Networks Functional Requirements Non-Functional Requirements Platforms Storage Requirements Frameworks

Application

Use Cases

Interface Requirements

Architecture

Component

User Interface Code

Schemas

Information Management

Data Administration

areas that are independent of business processes and the management of all electronic and paperbased records. The software portfolio management column includes the elements that define an organisations software portfolio. The portfolio is likely to a mixture of bought-in packaged software and custom in-house developed software. A major concern of those who focus on this column is the integration of disparate software.

The data administration column includes the elements that define an organisations electronic databases. While data administration is often regarded as an on-going function, it should not be forgotten that this is also the discipline that drives data quality improvement and data integration projects. The infrastructure management column is often viewed as the operations domain. The elements in this column represent the organisations

33

Extreme Architecture Framework

hardware and software platforms together with the networks that interconnect them. The operations group also manages the technical frameworks underlying the technology. While the discipline is mainly concerned with guaranteeing the smooth running of technology, infrastructure projects such as the technology conversion, standard operating environments, or rationalisation of networks and technology also fall into this domain.

BUSINESS AND IT RESPONSIBILITIES

Considering the columns of the XAF offers one further insight into the governance of enterprise architecture. Frequently tension develops between business and IT groups. The reason for the tension becomes clearer when the responsibility for different columns is highlighted on the XAFbusiness groups are usually responsible for the elements in the activity and information columns while IT groups are usually responsible for the data and technology columns. Many would include the software column as an IT responsibility. It is true that IT areas actually Figure 13. The axis of joy or sorrow business and IT ownership

construct the software portfolio by identifying the functional requirements, designing databases, and writing program code. However, it can be argued that business groups must be actively involved in the management of the software portfolio if it is to meet their needs and be properly aligned to the goals of the enterprise. The authors conclusion is that both groups must share responsibility for the software portfolio. This column represents the boundary between the two groups; it is where most benefit will be gained from collaboration and joint responsibility. For many enterprises, this column will come to represent what the authors call an axis of joy or an axis of sorrow.

WHERE ROWS MEET COLUMNS

The individual cells of the XAF are where the life cycle and management disciplines intersect. They also highlight areas where cooperation is required and conflict is common. For example, the intersection between the component row and the data column could involve interaction between the software developers and the data administrator. Many readers will be familiar with situations in which software developers design a data structure that does not conform to enterprise standards. Often the developers have compelling reasons to do this but it will inevitably bring them into conflict with the data administrator. The XAF offers a way out by providing a platform for both parties to present their arguments while at the same time offering an opportunity to acknowledge the importance of the opposing point of view.

Axis of joy or sorrow

Activity Sector
Activities Subject Areas Information Requirements Functional Areas Business Objects

Information

Software

Data

Technology

Enterprise
Workflow

Process

Networks Interface Requirements Functional Requirements Non-Functional Requirements Storage Requirements Platforms

Application

Use Cases

ARBITRARY AREAS
Schemas

Architecture

Component

User Interface Code

Business ownership

IT ownership

As well as the rows and columns previously described, the cells of the XAF can be grouped into any number of arbitrary areas. This approach

34

Extreme Architecture Framework

Figure 14. Where disciplines intersect Data Administration

Activity Sector
Activities Subject Areas Information Requirements Functional Areas Business Objects

To summarise the various groupings of the XAF previously discussed: The horizontal rows describe the disciplines associated with projects and are applied to various phases of the system development life cycle. The vertical columns represent the management disciplines that are required for proper governance of the enterprise architecture. Groupings of vertical columns represent the responsibilities of business and IT groups with the software column representing an area of joint responsibility. Individual cells represent areas of potential conflict (or cooperation) between the needs of projects and good governance. Arbitrary areas represent the scope of unique types of work; typically project assignments.

Information

Software

Data

Technology

Enterprise
Workflow

Process
Networks Interface Requirements Functional Requirements Non-Functional Requirements Storage Requirements Platforms

Use Cases

Application

Architecture

Component

User Interface Code

Schemas

Software Construction

can be very useful for scoping areas of special interest. As an example, the authors will briefly discuss how they have used the framework to scope consultancy projects. In one project, the framework was used to plan the development of a requirements traceability matrix. The client wanted to be certain that the software application they had acquired satisfied their documented requirements and would successfully integrate with other applications. The basic question they wanted to answer was, Have we covered everything? To determine the scope of the assignment, the authors presented the framework using a colourful laminated card. As well as helping to explain the nature of the XAF, the reference card served as a focal point for negotiating the scope of the assignment. A number of possible boundaries for the assignment were physically sketched on the reference card. Presentation of the XAF in this manner assisted the client to articulate what they wanted at the authors to cover. The final sketch became the scope of the assignment and the basis of the project charter.

WHO OWNS THE FRAMEWORK?

Using groupings of framework cells to highlight the responsibilities of business and IT groups raises the question Who is responsible for the framework itself? The authors initial reaction to this question is that the framework is simple enough not to require an owner! However, it is a fact that the successful development of an enterprise architecture will require firm leadership and the allocation of appropriate resources. With this in mind, the authors envisage that an enterprise architect role will be required and that this role will serve as the custodian (rather than owner) of the framework. The responsibilities of the enterprise architect role would include: Facilitating the population of the framework with a variety of content.

35

Extreme Architecture Framework

Figure 9. Defining the scope of a consultancy project

Consultancy scope
Activity Sector
Activities Subject Areas Information Requirements Functional Areas Business Objects

Information

Software

Data

Technology

Enterprise
Workflow

Process
Networks Functional Requirements Non-Functional Requirements Platforms Storage Requirements Frameworks

Application

Use Cases

Interface Requirements

Architecture

Component

User Interface Code

Schemas

Coordinating activities performed by the life cycle disciplines and management disciplines. Arbitrating in conflicts between the life cycle and management disciplines.

greater relevance to the modern enterprise than the abundance, privilege, and order of Reims cathedral or the disenfranchisement, poverty, and chaos found in a shantytown. Secondly, the XAF is extreme because it exaggerates the best aspects of other architecture frameworks. Like the Zachman framework, the XAF is easy to describe: It is based on a simple five by five matrix. The body of the matrix is populated with just 18 architectural elements. The authors present the framework using a single, colourful reference card that everyone seems to want. The use of a matrix provides a simple structuring mechanism for the architecture. The relationship and interaction between elements in adjacent cells is easy to understand and the impact of change is easy to see. The complete matrix offers a holistic view of the enterprise as a whole. In contrast, many architecture frameworks are complex and difficult to describe. The documentation for TOGAF Version 8 runs to 313 pages and includes many complex diagrams.

WHY EXTREME?
How can an architecture framework that evolved out of a search for the middle path be called extreme? Firstly, enterprise architecture is beset by extremes. At one extreme, the would-be builders of corporate cathedrals will settle for nothing less than perfection. At the other extreme, the builders of chaotic shantytowns grab the first solution that comes to hand. As we have seen earlier, when the image of a modest suburban house is placed between the images of a cathedral and a shantytown it becomes obvious that the middle path is in fact an attractive alternative to the two extremes. However, it is important to emphasise that following the middle path is not the same as sitting on the fence. The suburban house as a metaphor for self-reliance, affordability, and pragmatism has a much

36

Extreme Architecture Framework

The XAF encourages an agile approach to architecture work products: The 18 architectural elements serve as a comprehensive but manageable checklist for many different types of architectural content. This versatility supports the development of many different styles of enterprise content. In contrast, many architecture frameworks advocate the creation of a large number of elaborate and detailed models. For example, the Zachman framework identifies no less that 36 primitive models. The XAF unifies a number of disparate disciplines: We know of architecture groups that work in splendid isolation. Their elaborate models never make one iota of difference to the business managers, business analysts, software developers, or IT infrastructure groups. In our framework, the 19 architectural elements can be grouped into four different areas. Each area is focused on a particular group but retains the context of its relationship to the other elements. The XAF offers a simple, consistent view to the various parties involved in the management of enterprise resources: This encourages shared understanding between disparate groups by presenting an area of common ground that can be understood by everyone. This leads to increased participation and ownership by all parties. In contrast, some frameworks organise models according to various roles and disciplines. This tends to encourage redundant descriptions of architectural elements at different levels of detail. For example, the Zachman framework answers the questions what, why, when, how, where, and who from the perspective of five different roles. The framework can provide a means to explicitly acknowledge the responsibility that some groups have for certain architectural elements: From the opposite perspective, it also serves as an encourage-

ment for people to acknowledge the responsibility that others have for architectural elements. Above all, the XAF is a middle of the road vehicle for those businesses and IT groups who cannot afford the comprehensive nature of some published frameworks and who wish to avoid the chaos of not having one at all.

REFERENCES
Beck, K. (2000). Extreme programming explained: Embrace change. Upper Saddle River, NJ: Addison Wesley. Brooks, F. P., Jr. (1995). The mythical man-month: essays on software engineering. Reading, MA: Addison-Wesley. Checkland, P., & Scholes, J. (1990). Soft systems methodology in action. Chichester, UK: John Wiley. Coad, P., et al. (1999). Java modelling in color with UML: Enterprise components and processes. Upper Saddle River, NJ: Prentice Hall. Fong, E. N., & Goldfine, A. H. (1989). Information management directions: The integration challenge. National Institute for Standards and Technology (NIST). Foote, B., & Yoder, J. (1999). Big ball of mud: Pattern languages of program design 4. Addison-Wesley. Hall, J., Healy, K., & Ross, R. G. (2005). The business motivation modelBusiness governance in a volatile world. Business Rules Group. Hammer, M., & Champy, J. (2003). Reengineering the corporation: A manifesto for business change. HarperCollins. Hofmeister, C., et al. (1999). Applied software architecture. Addison Wesley.

37

Extreme Architecture Framework

IEEE Computer Society. (2000). Recommended practice for architectural description of softwareintensive systems, Std 1471-2000 IEEE. Pressman, R. (2005). Software engineering: A practitioners approach (6th ed.). New York: McGraw-Hill. The Open Group. (2003). The Open Group architecture framework (TOGAF), Version 8, Enterprise Edition, San Francisco, California: The Open Group. Retrieved July 18, 2003, from http://www.opengroup.org/architecture/togaf8doc/arch/ Thera, V. P. (1958). The Buddha: His life and teachings. Kandy, Sri Lanka: Buddhist Publication Society. Retrieved January 2006 http://www.buddhanet.net/e-learning/buddhism/bud_lt11.htm Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems J., 26(3).
6 4

ENdNotES
1

Enterprise elements can be regarded as instances of architectural elements. For example, a framework might include business objects as one of its architectural elements. The corresponding enterprise elements would include the actual business objects such customer, supplier, product, and purchase that are relevant to a specific enterprise. In the OMB memorandum, this architecture is called the business process architecture. We have changed the name because we have already used the phrase business process to describe a type of system. It is common practice to either combine the information architecture with the activity architecture and call it a business architecture or to include information requirements in the data architecture. We do not like the first approach, as the phrase business architecture sounds rather vague and nebulous. As far as the second approach is concerned, we feel it

does not highlight the fact that information is related to business activity while data is more closely related to information technology. In addition, there are issues associated with an information architecture such as the management of non-electronic records that are not accommodated well in the data architecture. In the OBM memorandum, this architecture is called an applications architecture. We have changed the name because we have already used the word application to describe a type of system. The change of name also allows for a more service-oriented view of software. The software architecture and data architecture together could be viewed as the definition of an information systems architecture. In fact, this composite architecture would appear to be a much better candidate to be named applications architecture. The technology architecture includes components such as hardware platforms, operating systems, database management systems, networking software, and the communications infrastructure. Terms used in the database world can be mapped to those used in the framework. A logical data model is equivalent to the business objects. A physical data model (or database design) is equivalent to storage requirements. Data manipulation language (DML) is code. Data definition language (DDL) defines a database schema. A DBMS such as Oracle is technology. Strictly speaking, the objects of object-orientation have relevance in three places in the framework; The persistent business objects described here belong in the data column; business objects that have behaviour (as well as state) belong in the activity column (we actually dont recommend that activities are modelled in this way but some users of the framework may prefer this approach); and software classes and components belong in the component row.

38

39

Discovering and Modelling Enterprise Engineering Project Processes

Ovidiu Noran Griffith University, Australia

Chapter III

AbstrAct
Often, in an enterprise engineering (EE) project, it is quite difficult to figure out what exactly needs to be done due to the rather generic (and often proprietary) character of the EE methods available. In addition, selecting appropriate elements from the multitude of available and emerging architecture frameworks (AFs) in order to model and manage the given EE undertaking is a non-trivial task. This chapter proposes a way to assist the inference of processes and to facilitate the selection and use of AF elements needed to accomplish EE projects. This is accomplished by assessing and organising AF elements into a structured repository (SR) using a generalised architecture framework (ISO15704:2000 Annex A) and by providing a method to create methods (a meta-methodology) for specific EE tasks that also guides the selection of AF elements from the SR. A brief introduction outlining the previously mentioned EE problems is followed by the description of the meta-methodology principle and of the assessment reference used. Next, a case study presents a sample application of the meta-methodology for a real EE project. The chapter closes with conclusions on the presented approach and a description of further work to refine and enrich the meta-methodology.

IntroductIon
Typically, the scope of enterprise engineering (EE) projects requires significant resources and involves large turn-around periods. Therefore,

such projects should be approached using suitable and mature methods, modelling constructs, and tools. EE practice in the virtual enterprise (VE) domain (Globemen, 2000-2002) has shown that often, the initial problem in an EE project is the

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

Discovering and Modelling Enterprise Engineering Project Processes

lack of a clear image of the activities that need to be performed to manage and execute that project. The currently available public and proprietary EE methods are quite generic, resembling reference models that need to be customised for specific projects; this typically requires knowledge of those methods (Noran, 2003a). EE artefacts typically required by EE projects, such as modelling frameworks (MFs), reference models (RMs), modelling constructs (languages), and tools, etc., can be provided in an integrated manner by architecture frameworks (AFs). Note that the term architecture framework is understood in this chapter as an artefact defining the types of elements needed to support the creation of an object from the identification of the need to create that object through to its decommissioning. However, often the artefacts composing a single AF do not provide sufficient coverage for a specific EE project and thus, a combination of elements from several AFs is necessary. The complexity involved in most EE tasks makes the selection of AF elements a non-trivial task, usually requiring knowledge of the elements outcomes, prerequisites, and dependencies on other AF elements. This chapter proposes a basic method to guide the creation of a set of activity type descriptions expressing what needs to be done in a particular EE project, based on domain knowledge (i.e., based on project stakeholder/champion knowledge about the participating entities and their relations). The proposed method also assists in the selection of suitable AF elements for the specific needs of the particular EE project, based on their capabilities assessed in relation to a reference AF. Note that the method and the reference AF used in this example do not prescribe the use of any specific AF or AF elements; they provide a way to assess AF element capabilities, to present a set of steps that specify types of activities needed to accomplish specific EE tasks and to

recommend sets of AF elements suitable for those tasks; it is then up to the user to select specific AF elements out of ranked lists, or override the recommendations. Therefore, this approach could be reused by EA practitioners to evaluate and select their preferred AF elements and to assess other methods for applicability to their specific EE project(s).

bAckground: Issues In enterprIse engIneerIng prActIce

The critical review of several mainstream AFs described in (Noran, 2003a, 2004a) has identified some of the problems associated with the use of AF elements in EE practice. The reviewed AFs were Purdue enterprise reference architecture (PERA) (Williams, 1994), GRAI (graphs with results and activities inter-related) (Doumeingts, 1984), computer integrated manufacturing open system architecture (CIMOSA) (CIMOSA Association, 1996), the Zachman framework (Zachman, 1987), command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) (C4ISR architectures working group, 1997), and architecture for information systems (ARIS) (Scheer, 1992). Note that subsequently, several other AFs such as TOGAF (the Open Group architecture framework) (The Open Group, 2006), FEAF (Federal enterprise architecture framework) (U.S. Federal CIO Council), Department of Defence architecture framework (DODAF) (Department of Defence Architecture Framework Working Group, 2003), and TEAF (Treasury Enterprise architecture framework) (Department of the Treasury CIO Council, 2000) have also been examined and found to be related to, and/or display similar main problems to the first six AFs. These problems are summarized next.

40

Discovering and Modelling Enterprise Engineering Project Processes

Methods: generality
Several methodologies associated with, or relating to AFs have been reviewed in Noran (2003a), such as the Purdue methodology, (published as a Handbook for Master Planning (Williams, Rathwell, & Li, 2001)), the structured approach of the GRAI integrated methodology (Doumeingts, Vallespir, Zanettin, & Chen, 1992), the CIMOSA methodology (Zelm, Vernadat, & Kosanke, 1995), Zachman foresight (Zachman, 2000), and Popkin process (Popkin Software, 2001), the six-step C4ISR process (C4ISR Architectures Working Group, 1997), and ARIS house/house of business engineering (Scheer, 1998a, 1998b). The review has found that all methods display various degrees of generality, reflecting the parent AFs aim to have broad applicability. However, for this reason the available methods are rather reference models of methods that need to be customised for each particular EE project. It has also been found that knowledge of these methods is required in order to decide on their selection and to subsequently customise them for the specific EE task.

tency by integrating the views contained in their MFs (e.g., C4ISRs core architecture data model, Zachmans metamodel (Sowa & Zachman, 1992), and ARIS high-level metamodel (Scheer, 1999).

Languages: Integration, complexity, control

Some reviewed AFs such as PERA and Zachman aim not to prescribe a complete set of languages, instead arguing that the given engineering domain already has adequate means to describe any deliverable, and the architecture is only there to create a checklist of deliverables and to make their relationships explicit. Such AFs only give examples of typical modelling languages. However, the choice of modelling languages is paramount for the user/ stakeholder support and thus ultimately, for the success of an EE task. Thus, modelling languages can provide a degree of inter-model consistency by being part of a set/family (e.g., IDEF (Menzel & Mayer, 1998) or UML (Rumbaugh, Jacobson, & Booch, 1999)), ideally integrated through a set of metamodels (e.g., UML, but not IDEF (Noran, 2003b)). Layering and complexity hiding abilities of a language allow parts of the same model to be developed and used simultaneously by several user groups while maintaining overall model consistency. It also allows presenting the model to various audiences, from technical personnel to upper management/CEO.

Models: consistency
A given EE task typically requires several enterprise models focusing on specific aspects. This creates the issue of consistency between the models created. For example, if the functionality of the enterprise is expressed in an activity/process model, the inputs/outputs, resources, and controls of the activities represented in that model could also be described in information, resources, and organisational models. In that case, it is imperative that the various descriptions of the same artefact are kept in agreement. Typically, this is no easy task and can be enforced by the users via policies (weak), triggers, and procedures (medium), or through more formal means such as meta-models underlying modelling constructs (strong). Some of the reviewed AFs aim to ensure such consis-

reference Models: generality vs. specialisation

The review undertaken has found that RMs provided by some AFs, such as the Purdue CIM reference model (Williams, 1988), the GRAI Grid reference model (Doumeingts, Vallespir, & Chen, 1998), the CIMOSA integration infrastructure services, the C4ISR universal reference resources, and the ARIS Y-CIM model (Scheer, 1994) come in various degrees of specialisation. A specialised RM has a narrow area of application, while a

41

Discovering and Modelling Enterprise Engineering Project Processes

more generic RM needs to be customised before being used for a specific EE task. Knowledge of the RM is needed, either to be able to use a specialised RM, or to customise a generic one. RMs also vary greatly in their ability and efficiency to cover various life cycle phases.

step, taking into account the applicable aspects and life cycle phases.

evALuAtIon And seLectIon of ArchItecture frAMework eLeMents the Architecture framework Assessment reference
The ISO15704:2000 standard, Requirements for enterprise reference architectures and methodologies, has been developed to supply a generic set of criteria to test the ability of existing AFs to provide relevant assistance for EA tasks. Annex A of the standard, the generalised enterprise reference architecture and methodology (GERAM, see Figure 1) is a generic AF compliant with ISO15704, obtained by generalising concepts present in several mainstream AFs and in EA best-practice. Note that GERAM only specifies requirements for tools, methods, and models; it does not enforce any particular choices to satisfy these requirements.

tools: Awareness, Integration

Effective enterprise modelling tools have to be aware of the languages they support (i.e., support their syntax at a minimum). Noran (2004a) has reviewed several tools, including FirstStep (Levi & Klapsis, 1999), IMAGIM (GRAISoft, 2002), and system architect (Popkin Software, 2001). It has been found that tools belonging to a suite and/or based on a shared repository and supporting languages belonging to a set can provide a degree of integration of the models produced. Existing/legacy modelling tools and staff skills may constitute deciding factors in modelling tools selection for an EE task.

proposed solution
The previously described issues can be addressed in two main steps. First, evaluate and organise AF elements in respect to a generalised reference AF. Second, develop a method guiding the discovery of the processes involved in accomplishing EE tasks and supporting the user in selecting suitable AF elements for those tasks. These two steps have been addressed in the meta-methodology (method to create methods) research described by Noran (2004a). Thus, one of the main meta-methodology components is a structured repository containing elements of several AFs assessed in respect to ISO15704:2000 Annex A (ISO/TC184, 2000) as a common reference. The other major component is a set of steps assisting the inference of activity types that need to be undertaken for specific EE tasks. The meta-methodology steps use the repository content to build ranked lists of AF elements recommended to the user for each

GERAM Components
A main component of GERAM is its reference architecture (GERA), whose MF features a threedimensional structure containing several views that may be used to structure the knowledge in various interrelated models (refer Figure 2). GERA does not enforce the presence of all views; also, other view types can be added if necessary. The condition however is that the views that are present must together cover the necessary aspects of the specific EE task. Thus, the user is presented with a list of possible views and must make informed decisions as to which views are indeed necessary for the task at hand. GERA is further described in the next section. ISO15704:2000 specifies a requirement for compliant AFs to have associated methods (ex-

42

Discovering and Modelling Enterprise Engineering Project Processes

Figure 1. A GERAM metamodel

GERA
Generalised Enterprise Reference Architecture
Identifies concepts of Enterprise Integration

EEM
1..* 1..* Enterprise Engineering 0..* 1..*
Methodology
Describes process of enterprise engineering

EML
Enterprise Modelling Language
Provides modelling constructs for processes, technologies and human role

employs

utilises

0*

implemented in implemented in 0..* 0..*

1..* 0..*

GEMC
Generic Enterprise Modelling Concept
Defines the meaning of enterprise modelling constructs

EET
Enterprise Engineering Tool
Supports Enterprise Engineering

0..* supports

used to build

PEM
Partial Enterprise Model
Provides reusable reference models and designs of processes, technologies and human roles

0..*

supports

0..* 1..*

EM
Enterprise Model
Supports Enterprise Engineering

is a kind of

1..* used to implement 1..*

EMO
Enterprise Module
Provides implementable modules of operational processes, technologies and human professions

EOS
0..* used to implement 1..*
Enterprise Operational System
Supports the operation of the particular Enterprise

emplified in GERAM by enterprise engineering methodologies (EEMs)) guiding the user in utilising their elements. The level of specialisation of such methods can be assessed by using GERAs MF Instantiation dimension (see next section). Enterprise modelling languages (EMLs) provide the necessary constructs to describe the various artefacts present within GERAM. For example, EEMs represent the models of engineering processes by means of EMLs. Typically, a combination of EMLs has to be used to describe all necessary modelling aspects (information, function, organisation, behaviour, etc.) of an EE project. GERAM calls RMs partial enterprise models (PEMs)reusable templates for human roles (organisational), processes (common functionality), or technology (e.g., IT resources). Enterprise models (EMs) are the main vehicle for structuring the knowledge existent in the enterprise (e.g., by modelling the AS-IS state) but are

also essential enablers of the change processes that may have prompted their creation (by modelling TO-BE states). A typical set of EMs as required by ISO15704:2000 and described by GERAM should include enterprise operations, organisation, IS and resources, and clearly show the human role within the control and production systems. Further detail, such as hardware/software may also be required depending on models intended use (see the GERA views in Figure 2). Enterprise modules (EMOs) are implemented RMs, usable as trusted plug-and-play components. For example, if a design has used certain RMs, the EMOs corresponding to those RMs can be directly used in the implementation of that design.

gerA structure
GERA is a life cycle reference architecture (i.e., an architecture that can specify types of activi-

43

Discovering and Modelling Enterprise Engineering Project Processes

ties involved in the implementation of a project spanning over part, or the entire life of an entity; in contrast, a system architecture only models the structure of an entity (system) at a certain point in time). GERA contains an MF (represented in Figure 2) and other concepts such as life history, entity recursiveness, and so forth. Generally, an MF is a structure containing placeholders for artefacts needed in the modelling process. Depending on the structure of the framework, the type of these artefacts may be limited to models, or may extend to other construct types such as RMs, metamodels, glossaries, etc. For example, the GERA MF contains placeholders for artefacts of the types shown in the GERAM metamodel (see Figure 1). The GERA MF allows the practitioner to focus on certain aspects of complex EMs by using views defined by several criteria, as further described. The model content criterion provides four views describing the functional, information, resource, and organisation aspects of an enterprise. It is to be noted that the organisation view may

Figure 2. The modelling framework of GERA (ISO/TC184, 2000)

Views
Generic Partial Particular

Instantiation
Identification Concept Requirements Prelim. design Design Detailed design Implementation Operation Decommission Machine Human Resource Organisation Information Function Management and Control Product or Service Software Hardware

Life Cycle Phases

be obtained by mapping part of the resource view (human side) onto a subset of the functional view (the human-implemented functions). The purpose criterion divides the EE artefacts into production (or customer service) and control (or management). Typically (although not mandatory), this division is present when representing the relation between the life cycle phases of various enterprise entities in the business models used in meta-methodology application. The implementation criterion provides a way to distinguish between the production/service and the management/control aspect of an enterprise, while at the same time allowing to represent the extent of the human-accomplished tasks (humanisability) in both aspects. The human role is an essential success factor in EA, although it is often either overlooked or has only limited coverage in the AFs and RMs currently available. Finally, the physical manifestation criterion provides a finer subdivision, setting apart hardware and software aspects of EA artefacts. It is mostly used to scope views derived from other criteria. The second dimension of the GERA MF contains the concept of specialisation, which allows it to represent all of the previous aspects at the generic, partial, and particular levels (see Figure 2). For example, the partial level of GERA can be used to assess the coverage and degree of specialisation of RMs (PEMs) or methods (EEMs). Life cycle represents the third dimension of the GERA MF, allowing it to represent (and assess) the applicability of AF elements to various life cycle phases of the modelled entity. For example, this dimension enables the creation of business models in the context of the life cycles of the participating entities, which is an essential meta-methodology requirement. Several other GERA artefacts reside outside its MF. For example, the concept of life history can be used to model process concurrency. In GERA, life history implies a time dimension and represents the collection of life cycle phases

44

Discovering and Modelling Enterprise Engineering Project Processes

that the entity has gone (or will go) through during its life. In contrast, life cycle abstracts from time and is a collection of life cycle phases that the entity could go through during its life. In conclusion, GERAM provides a suitable reference for assessing the pool of AF elements needed to construct a repository and support the meta-methodology application.

Architecture framework element Assessment and organisation into a knowledge base

In addition to identifying problems in EE practice, the critical literature review described in (Noran, 2003a) has also mapped the reviewed AFs against GERAM, attempting to identify relevant components such as MFs, RMs, generic modelling concepts (such as metamodels, ontologies, etc), modelling methods, languages, tools, etc. The MF of GERA has then been used to scope the identified AF elements in order to check their intended coverage and determine

Figure 3. Knowledge base showing AF elements and selection/ordering rules

AF Element
type family integration tool support Prerequisites (, ..., ) Outcomes (, , )

Knowledge Base
AF Elements

Rule
Find AF Elements w. Outcomes matching Prerequisites

Rules Rule
Order AF Elements: - least prerequisites - multiple use - specialisation - part of family - integrated family

their potential applicability domain(s) in terms of views, life cycle, and specialisation. The assessed and mapped AF elements have then been stored in a knowledge base (KB) organising AF elements by name, type, family, integration, tools, and importantly, associating prerequisites and outcomes to each AF element. The KB has then been added rules for the selection of the AF elements and their ordering in ranked lists, resulting in the rule-based KB shown in Figure 3. The subsequent addition of an inference engine to the KB has resulted in the structured repository (SR) currently used by the meta-methodology concept (see Figure 5, left). For example, the representation of a GRAI Grid decisional RM (explained elsewhere in this chapter) includes its name (=GRAI Grid), type (=Reference Model), whether it belongs to a set of reference models (YES, =GRAI), if the set is integrated (NO not formally), and whether the RM is supported by any available tools (YES, =IMAGIM). The main outcome of the GRAI Grid RM representation in the KB would be decisional modelling. However, GRAI Grid RMs can be also used for organisational modelling if the human resources have been previously mapped. Therefore, this GRAI Grid RM could also have an organisational modelling outcome, however associated with a resource modelling prerequisite. The mapping of the AF elements on GERAM and GERA has revealed that typically, elements of several AFs can cover a particular area of an EE project. However, their efficiency in modelling the area in question may vary greatly in respect to various aspects and life cycle phases. For example, GRAI Grid would be quite efficient in modelling the decisional/organisational structure for the concept, requirements, and architectural design of an entity, but less efficient for the detailed design, implementation, or operation of that entity. Therefore, the inference engine would create ranked lists of matching AF elements for the specific task; the user can then accept or override recommended choices and thus test various scenarios.
45

Discovering and Modelling Enterprise Engineering Project Processes

guIdAnce for process dIscovery

In response to the methodological problem identified in the Background section, a basic procedure (meta-methodology) has been developed to guide the development of methods (sets of activity/process types) for specific EE tasks. This method is based on the concept of reading the life cycle phases of the target entity (here, one or more enterprises) in the context of its relations with other entities, using a life cycle-based business model, and, based on domain knowledge, inferring the necessary activities for each life cycle phase. The meta-methodology contains the following main steps (see Figure 4): 1. Identify a list of entities relevant to the EE project. If one or more projects are set up to build the target entity (entities), consider including them as target entities as well. Create a business model showing the relations between the life cycles of the identified

3.

entities, while re-assessing the need for the presence of each entity in the diagram, and the extent of life cycle set to be represented for each entity (e.g., full set, single phase, etc). Reading the life cycle diagram of the target entity, phase by phase, infer a set of activities describing the creation of the entity and the roles played by other entities. For several target entities, determine the order in which they are influenced (from the relations in the diagram) and create the activity model in that order. Detail the activities to the necessary level using the aspects adopted and, if applicable, the views of a suitable MF.

The sub-steps relating to all the main steps are as follows: a. Identify a suitable MF if applicable. Choose the aspects to model, depending on the meta-methodology step. Resolve any aspect dependencies.

2.

Figure 4. The meta-methodology concept (Noran, 2004a)

How to ?

Domain Knowledge

Structured Repository

1 2 3 4 5 6 7 8 7

1 2 3 4 5 6 8

1 2 3 4 5 6 7 8

Entity E1: the large Farmer / association Entity E2: the small / medium Carrier Entity E3: the large Wholesaler Entity E4: the small / medium Retailer Entity E5: the Food Plant / Processor Entity E5: the Commodity Handler

2 3 4 5 6 7 8

E1

E2

E3

E4

Entity List

Business Model

Activity model

Meta-methodology
Specific method

46

Discovering and Modelling Enterprise Engineering Project Processes

b.

c.

Choose whether to represent only the present (AS-IS), future (TO-BE), or both states. If both, choose whether to represent them separately or combined. Choose modelling formalism(s) depending on the aspect(s) selected and on modelling best-practice criteria, such as: previously used in the modelling, specialisation in those aspects, potential multiple use, part of a family, family integration. Choose modelling tool depending on formalism and other factors (such as belonging to a suite, availability, etc).

user to select appropriate aspects and modelling formalisms in order to enforce a degree of coherence to the activity inference process. However, specific conclusions and insights gained by the user in steps 1 and 2 should also be used to select and (if warranted) even override step 3 recommendations. In conclusion, the meta-methodology concept implies constructive assistance, rather than blindly following a set of fixed steps that automatically lead to a unique, best solution.

The application of these steps is illustrated in a case study presented further in this Chapter. In building the activity model (step 3), a sufficient level of detail is reached when the processes can be directly executed by the envisaged resources. Note that the main aim of this chapter is to incite reader interest in the potential meta-methodology reuse and application to other EE tasks, rather than to provide a full description of the meta-methodology development and use. The interested reader is invited to get further metamethodology details from (Noran, 2004a).

IntegrAtIon of the MetAMethodoLogy steps And the structured reposItory

As can be seen in Figure 4, there is a close relationship between the SR and the meta-methodology steps. This connection is further detailed in Figure 5. The SR (containing the KB) is integrated with the meta-methodology steps in a meta-methodology environment. Thus, the search/inference engine (or an artefact with similar functionality, depending on the implementation) within the SR selects AF elements at the request of the metamethodology steps and sub-steps and arranges them in ranked lists using the KB matching and ordering rules. The engine also attempts to resolve dependencies and prerequisites (i.e., if the chosen AF elements require other elements in the KB, they are also added as ranked lists to the proposed solution). The user is notified of any unsatisfied prerequisites. Another aspect of the previously mentioned integration is the implementation of meta-methodology step logic in the KB rules. For example, the main aspect recommended for modelling in sub-step a can be supplied by a rule in the KB of the SR (e.g., on the basis of the step number); subsequently, the engine would also resolve any aspect dependencies by recommending additional aspects if applicable.

note on the Meta-Methodology capabilities

The meta-methodology provides guidance and assistance, but it does not infer the activities for the user. This is because as shown in Figure 4, the domain knowledge required to deduce such activities is quite specific and owned by the specific projects stakeholders. The meta-methodology user (typically the enterprise architect) has to elicit this knowledge from the stakeholders or otherwise acquire it by immersing in the participating organisation(s). For example, step 3 tells the user how to elicit the activities from the business model. The sub-steps applied to step 3 assist and prompt the

47

Discovering and Modelling Enterprise Engineering Project Processes

Figure 5. Meta-methodology steps interaction with the structured repository

AF Element
type family integration tools Prerequisites (, ..., ) Outcomes (, , )

Knowledge Base
AF Elements

Inference Engine
ion s nt An Ste sw ers p Select AF Elements lar Particu Metaing Sett

&

Cu

Qu es t

rre

Rule
Find AF Elements w. Outcomes matching Prerequisites

Rules

Rule
Order AF Elements: - least prereqs - part of family - integrated family

methodology Steps and Sub-steps

Steps & s Substep

Structured Repository Meta-methodology environment

Dynamic facts (specific to the particular setting) that cannot be stored in the KB, such as staff proficiency in particular modelling languages and modelling tools, available/legacy systems, and other relevant constraints within the participating organisations are gathered from the user at runtime and are used in ranking the AF element lists.

collaborative networks and virtual organisations in the Industry

In the current global market, enterprises worldwide must often come together for the purpose of tendering, executing, and servicing large-scale projects requiring competencies and resources beyond their individual capabilities. The resulting organisations, although composed of various participants, appear as an indivisible entity to the outside environment (service providers, clients, etc.)hence their name of virtual organisations (VOs). VOs exist as separate entities for legal and commercial purposes although in fact, most of their resources belong to the participant organisations. Usually, the formation of VOs takes time, due to potentially lengthy processes such as trust building, obtaining commitment from management, agreement on a stable common ICT infrastructure, establishment of commonly understood RMs, etc. Typically, however, the time available to react to a business opportunity (such as a large project) is limited. Therefore, enterprises aiming to suc-

cAse study: the forMAtIon of A vIrtuAL orgAnIsAtIon

This section provides an example of using the previously described meta-methodology environment to infer the types of activities needed to accomplish a concrete EE task, namely the creation of a virtual organisation in the higher education sector. AF elements needed to model and manage the virtual organisation creation process are also suggested. Note that the presented example is also applicable to the creation of other VO types in other areas.

48

Discovering and Modelling Enterprise Engineering Project Processes

cessfully tender for such projects often become collaborative networked organisations (CNO) forming a collaborative network (Camarinha-Matos, 2004) or a company network (CN) (Globemen, 2000-2002) (see Figure 6). Such a CN provides a breeding environment where the participants

can accomplish the previously described processes in advance and thus improve their preparedness to quickly form VOs as required.

A virtual organisation for the tertiary education sector

Faculty FAC within University U contains several schools (A to D), with schools A and B having the same profile. School A is based in two campuses, situated at locations L1 and L2, while school B is based on single campus, situated at location L3 (AS-IS state in Figure 7). Although of the same profile, and belonging to the same FAC and U, Schools A and B are confronted with a lack of consistency in their products and resources, such as the programs and courses offered, allocated budget, academic profile, and availability of teaching staff, etc. This situation causes negative effects such as additional costs in student administration and in course/program design/maintenance and staff perceptions of unequal academic and professional standing between campuses, all of which are detrimental to the entire faculty.

Figure 6. Company network and virtual organisation concepts (Globemen, 2000-2002; Tlle & Vesterager, 2002)
Company Network Competencies Virtual Organisation

Virtual Organisation

Suppliers Suppliers Customer Customer

Figure 7. AS-IS and possible TO-BE state (organisational scenarios also shown)
AS-IS Legend:
FAC: Faculty (BE?) ======================= AD: schools within FAC L1.. L3: physical locations ======================= ITM: Schools merger project ======================= MS: Merged School (VO) ======================= HOS: Head of School DHOS: Deputy HOS PA: Personal Assistant SAO: School Admin Officer =======================

L1

L2

C (L1)

B (L3)

D (L3)

FAC
ITM

TO-BE 1

L1

L2 MS
PA

L3

C (L1) D (L3)

FAC

a) Dean FAC PA c) DHOS L1 PA SAO c) DHOS L2 PA SAO% a) HOS MS c) DHOS L3 PA SAO HOS C HOS D b)

Organisation:
One FAC Dean, one HOS of MS and a DHOS on each MS campus a) Dean FAC and HOS MS are distinct b) Dean FAC is also HOS MS c) HOS MS is one of the DHOS, nominated by rotation or ProVice Chancellor

Preferred Model

49

Discovering and Modelling Enterprise Engineering Project Processes

The problems previously described could be resolved by Schools A and B forming a VO (called merged school (MS) in the TO-BE state in Figure 7) with cross-campus management and policies ensuring inherent consistency in the strategy regarding the products delivered and the resources allocated to future VO campuses at L1, L2, and L3. The individual campuses are set to retain most of their internal decisional and organisational structure except for the highest layer, which will be replaced by the VO governance structure. In view of the CN/VO model previously explained, in this case study the CN function is performed by FAC, which contains several schools forming VOs as necessary. The partners (i.e., schools) A and B within the CN come together at the initiative of U to form an on-going VO project. Importantly, the partners cease to operate independently during the life of MS.

Sub-step c: Choose text representation as modelling formalism. Choose a plain text editor or whiteboard as tool. Motivation: Formalism and tool must preserve simplicity (see a above).

The list of entities constructed in this step is shown in the legend of Figure 10.

Step 2: A Business Model Expressing Entity Roles in a Life Cycle Context

Sub-step a: Adopt GERA as an MF. Using GERA as a checklist, it has been established that management vs. product/service aspects and also decisional and organisational models of the entities participating in the VO formation may be necessary. These representations must be shown in the context of life cycle. Motivation: The scope of this EE project includes management, product/service, decisional structure, and organisation. Life cycle representation is necessary for the second and third main meta-methodology steps. Sub-step b: Represent both AS-IS and TO-BE states. For management/service and life cycle, represent AS-IS and TO-BE in a combined view. Represent decisional and organisational views in separate models. Motivation: Since the present situation was not fully understood by the stakeholders, AS-IS needed to be modelled. Both separate and combined AS-IS / TO-BE representations have been considered. There was no tangible advantage in showing separate AS-IS / TO-BE states in the business model showing management / service in the context of life cycle. However the interest shown by the stakeholders in the decisional structure and the fact that the organisational structure was the only representation able to discern between several TO-BE states have deter-

Meta-Methodology Application Step 1: Identification of the Entities Relevant to the EE Project

The list of entities has been built according to the domain knowledge elicited from, and checked with the stakeholders and the project champions (Pro-Vice-Chancellor (PVC), Dean). Sub-step a: Choose life cycle representation, however no details: only stating to be full set of phases vs. one phase only. Others not necessary. Motivation: The representation must be kept simple. In this early stage, details are not relevant and can be detrimental to creative output. Sub-step b: Choose to represent both AS-IS and TO-BE states in a unified representation. Motivation: There is no obvious gain in having two lists with most list members identical.

50

Discovering and Modelling Enterprise Engineering Project Processes

mined the choice of separate AS-IS and TO-BE representations. Sub-step c: Choose modelling formalisms ranking highest in efficiency for the aspects selected in sub-step a. For life cycle and management/service, choose a chocolate bar formalism derived from GERA as shown in Figure 8.

Choose the GRAI Grid formalism (Figure 9) for decisional and organisational aspects. GRAI Grid ranks high in respect to other candidate languages due to its specialisation for the decisional aspect, potential multiple use (e.g., for organisational aspect), and no prerequisites. Next, construct the business model (Figure 10) illustrating entity roles in accomplishing the

Figure 8. Modelling formalism used for the life cycle and management vs. service/product views of the business model
Views

GERA MF

Generic Partial Particular

Formalism used
P M Id C R PD

Instantiation
Identification Concept Requirements Prelim. design Design Detailed design Implementation Operation Decommission Machine Human Resource Organisation Information Function DD I Op D Management and Control Product or Service Software Hardware

LC phases

Entity

Figure 9. GRAI Grid modelling formalism for decisional aspects (mapped organisational roles show possible use for organisational modelling)
Ext. Info Strategic
Horizon Period

Products

Plan

Resources
Decision Centre (DC)

Int. Info

Role 3

Tactical
Horizon Period Role 4 Role 1

Operational
Horizon Period

Role 2 Information Aggregation Information Link (IL) Decision Framework (DF) = information flow (IF)

Control
Horizon Period Legend:

= decisional centre (DC);

= decisional framework (DF);

51

Discovering and Modelling Enterprise Engineering Project Processes

EE project in the context of their life cycles and management vs. production/service aspects. The only candidate specialised tool for decisional/organisational models is IMAGIM. Due to costs and availability, a simple graphical editor has been used, thus, the consistency of entities showing in both decisional and organisational models had to be ensured by the user. The business model in Figure 10 allows a birds eye view on the entities involved in the target entities life cycle phases and has been constructed using the domain knowledge of the stakeholders as elicited by the user. Several entities influence various life cycle phases of MS directly, or through other entities. The main influence is exercised by ITM, which is in fact a project set up to build the VO and ceases to exist after MS starts operating. Note that this is a common occurrence in EE projects, reflected in the body of step 1 of the meta-methodology. The AS-IS decisional model (Figure 11) has shown in more detail some problems that have triggered the EE project, such as a high degree of turbulence and a lack of clear and effective

strategy within the organisation. Thus, the Head of School (HOS) in the role of planner had to put out fires (product/resource discrepancies requiring immediate reconciliation) on a short-term basis, rather than having strategies in place to avoid the cause of such problems. This can be seen in Figure 11 in the form of decisional frameworks (DFs) flowing from planning toward products and resources at all horizons. The AS-IS decisional model has also shown a lack of sufficient financial and decisional independence of the schools A and B and a shortage of information crucial to long-term strategy making (shown in Figure 11 by several DFs coming from outside the School and by limited external information flow). The TO-BE decisional model (see Figure 12) has attempted to address these problems by confining the authoritarian role of the HOS to the strategic level, by increasing the financial and decisional independence of the target VO (MS), and by providing the necessary external information to MS for the purpose of strategy making and self-governance. This is reflected in a lesser number of horizontal DFs originating from

Figure 10. Business model expressing entity roles in accomplishing the EE project
P Id C R PD DD I Op D AP M UA

UP

FAC

I1

I2

Legend:
ACC: Across Campus Consistency Project; ACCR: Reviews of the ACC A, B: Schools forming CNO (MS) MS: Merged School; I1, I2: Spin-off organisations (virtual or not); GA: University Act U: University; UP: University Project; AP: Academic Plan; FAC: Faculty within the U; ITM: Schools Merger Project

ACCR

ACC

MS

ITM

52

PVC, Academic Committee GU Act, Council, Acad. Committee Uni / PVC Policies HRM Uni Policies Uni./ Faculty / PVC INS Univ. Room Booking Faculty / PVC Commercialisation Office

Products Work for Outside Bodies Plan

Salary Non-salary Academic General Sessional HW, Venues SW / transp.

Resources Budget Staff InfraStruct

External Information Teaching / Learning

Institute Group / Indiv

Research

Internal Information

Strategic H=3y P=1y

N/A (Weak, unstable) N/A (Weak, unstable)

GU Act, Strategies on Project, Acad accreditation, new / Plan, enrolmnet discontinued programs / forecasts, courses, InternationaGovt policies, lisation, fees, prev studies credit, OP, marketing CRC / industry market trends approach, proc. improvement Strategy on GU Institutes, grants WOB strategy applications, (institutes, groups, CRC participat., individuals) research profile HR staffing strategy (academic profile, ratio to general / sessional, joint appointments, HR management, etc) Negotiate yearly budget Hire, supervise manage consult RHD sships. conf. travel, sessional staff General and Sessional Staff supervision /

Infrastructure Strategy, eg common labs, other school venues, transport

Cumulative expenditure / staffing, etc reports, long term trends

Tactical H=1y P=6m

Decide WOB for indiv / institutes

Academic Plan, Marketing approach and OP Research plans market analysis, adjustments, propose / revise SQI, IIIS, CRC participation, stud. enrolment programs / Majors, fees, comb degree / grants, journal figures, service teaching, student conference community, publications demographics services, prev studies credit Allocate teaching / research / WOB, non-salary budget within campus

Performance Upgrade Venue / evals / product com labs transport reports, schoolspecific stud. / staff upgrade enrol., retention management (recruit, train, etc) comp alloctn expenditure, staffing

Discovering and Modelling Enterprise Engineering Project Processes

Figure 11. AS-IS decisional/organisational situation (GRAI Grid model)

Tactical H=6m P=3m

Local / Prof. Semestrial corrections on Seminar planning. Community & service / combined degree Plan adjustments WOB WOB depending on adjust. for adjust. MP,Council, etc and summer teaching, web content mgmt, submission Institutes for indiv feedback, grants majors, acceptances, (SQI) / groups awarded, papers student services grants awarded accepted, Workload / nonsalary budget allocation adjustments (campus)

Sessional, conf. travel Manage, adjustments, supervise, misc expenses consult (resrch lunch)

Hire / lay-off as needed

Teaching evaluations, Manage Adjust replace- venue / student results, ments, transport progress upgrades alloctn. indicators

Operational H=1m P=1w

Decide on short term WOB (teaching, consultancies) Monitor processes

Relevant feedback, events / news

Manage short-tem / unexpected knowledge Manage teaching material / dissemination assessment items events (seminars, presentations, etc)

Manage unexpected savings / expenses

Manage unexpected staff issues Venue / transport Student / staff (e.g. unavailability, surge in / computing feedback, demand) maintenance events

Control H=1d P=real time

Control Teaching / Assessing Control research activity

Significant external events

Control WOB

N/A

Control budget

N/A

Control infrastructure

Significant internal events

= School (CIT/LG/INT) decisional centre (DC); Committee; = CIT/LG School Committee;

= decisional framework (DF); = info. link (IL); = Staff Committee; = Travel Committee;

= HOS ; = INT School = Equipment Committee

53

54
GU Act, Council, Acad. Committee Faculty / PVC Commercialisation Office Negotiated Rules of P/R allocation HRM Uni Policies INS Univ. Room Booking Faculty / PVC

PVC, Academic Committee

Products Work for Outside Bodies Plan

Salary Non-salary Academic General Sessional HW, Venues SW / transp.

Resources Budget Staff InfraStruct

External Information Teaching / Learning Research

Institute Group / Indiv

Internal Information

Strategic H=3y P=1y

Plan Workload allocation Long-term budget forecasts and negotiation

GU Act, Strategies on Project, Acad accreditation, new / Plan, enrolmnet discontinued programs / forecasts, courses, InternationaGovt policies, lisation, fees, prev studies CRC / industry credit, OP, marketing market trends approach, proc. improvement Strategy on GU WOB strategy Institutes, grants (institutes, groups, applications, individuals) CRC participat., research profile Allocate workload, non-salary budget across campuses Negotiate yearly budget Hire, supervise manage consult` RHD sships. conf. travel, sessional staff General and Sessional Staff supervision / Allocate teaching / research / WOB, non-salary budget within campus

Infrastructure HR staffing strategy (academic Strategy, eg profile, ratio to general / GRID, common sessional, joint appointments, labs, other school HR management, etc) venues, transport

Cumulative expenditure / staffing, etc reports, long term trends

Tactical H=1y P=6m

Academic Plan, market analysis, stud. enrolment figures, income generated, community, demographics Marketing approach and OP Research plans adjustments (coordinated), SQI, IIIS, CRC propose / revise programs / participation, Majors, fees, comb degree / grants, journal service teaching, prev studies conference credit, student services, publications Decide WOB for institutes Decide WOB for indiv / groups

Performance Upgrade Venue / evals / product com labs transport reports, schoolspecific stud. / staff upgrade enrol., retention management (recruit, train, etc) comp alloctn expenditure, staffing

Tactical H=6m P=3m

Local / Prof. Community & Seminar planning. Semestrial corrections on MP,Council, etc Plan adjustments service / combined degree feedback, grants WOB adjust. for depending on and summer teaching, web indiv / groups awarded, papers submission content mgmt, majors, accepted, acceptances, student services income grants awarded generated Workload / nonsalary budget allocation adjustments (campus) Sessional, conf. travel adjustments, misc expenses (resrch lunch)

Manage, meet / consult

Teaching Hire / lay- Hire / Manage Adjust evaluations, off as lay-off replace- venue / student results, as ments, transport needed needed upgrades alloctn. progress indicators

Operational H=1m P=1w

Decide on short term WOB (teaching, consultancies) Monitor processes

Relevant feedback, events / news

Manage short-tem / unexpected Manage teaching material / knowledge assessment items dissemination events (seminars, presentations, etc)

Manage unexpected savings / expenses

Manage unexpected staff issues Venue / transport Student / staff (e.g. unavailability, surge in / computing feedback, demand) maintenance events

Figure 12. Preferred TO-BE decisional and organisational situation (GRAI Grid model)

Control H=1d P=real time

Control Teaching / Assessing Control WOB Control research activity

Significant external events

N/A

Control budget

N/A

Control Infrastructure

Significant internal events

Discovering and Modelling Enterprise Engineering Project Processes

= NAT&LG / GC decisional centre (DC); = CINT DC; = DHOS / Campus Commitee; = Staff Commitee;

= decisional framework (DF); = info. link (IL); = Travel Commitee; =Equipment Committee;

= Executive Committee;

Discovering and Modelling Enterprise Engineering Project Processes

planning, less DFs coming from U and increased number of information flows in Figure 12. Also, some existing external DFs have been relocated so as to minimise the negative impact on MS. Figure 11 and Figure 12 show the AS-IS and TO-BE decisional and organisational models. Interestingly, the TO-BE decisional model has been found to match all potential scenarios, with differences only obvious in the organisational structure derived from the decisional model (i.e., the allocation of the various human resource groups to the decision centres [e.g., see areas defined as committees in Figure 12]). Therefore, modelling the organisational structure was instrumental in distinguishing between the available TO-BE options.

Step 3: The Set of Activities describing the EE Project Accomplishment

This step represents the main purpose of the meta-methodology, resulting in a set of activities describing how to accomplish the EE project (here, the VO creation and partly operation). The step is accomplished by reading the life cycle diagram of the entity to be designed (MS) and its relations with the other entities shown in Figure 10. The set of activities obtained is then refined and decomposed into sub-activities, using views of the selected MF (GERA).

Figure 13. IDEF0 modelling formalism (1st, or context level shown)

Controls Inputs
(transformed in the activity) I1 I2 C1 C2 (used in activity, but does not get transformed)

Sub-step a: Aspects: functional and life cycle, but use other categories to detail activities. Motivation: The main deliverable is an activity model, hence functional. However, the activities must be detailed using aspect from the SR and views from the selected AF, in this case management/service with human vs. machine and software vs. hardware aspects. Sub-step b: Choose to represent both AS-IS and TO-BE states in a unified representation. Motivation: The activity model is expressing the transition from AS-IS to TO-BE, thus both states should be represented; here, separate views did not justify the consistency overhead. Sub-step c: Choose IDEF0 (NIST, 1993) functional modelling formalism (see Figure 13 for a basic explanation of its elements). Select AI0Win tool by Knowledge-Based Systems, Inc. Motivations: UML and IDEF0 are both suitable; UML ranks higher than IDEF0, due to integrated metamodel present and wider tool support. However, the available (AI0Win) modelling tool and necessary skills were an overriding factor. AI0Win is also semi-integrated with information/resources modelling (SmartER) and behaviour modelling (ProSIM) tools, similar to a suite, thus ensuring some degree of model consistency. Therefore, overall IDEF0 and AI0Win were considered a suitable choice in this particular case.

Creating the Activity Types in Step 3

A set of activities must be inferred for each life cycle phase represented in the business model. Thus, the functional model can be initiated by creating one main activity for each life cycle phase identified in the business model (such as shown in Figure 14). The modelling formalism chosen to represent the model will assist in developing the model. For example, IDEF0 requires that inputs,

Outputs
(results of activity)

Activity

O1 O2

Mechanisms
M1 M2 (who / what makes it happen)

55

Discovering and Modelling Enterprise Engineering Project Processes

Figure 14. IDEF0 Activity model for the VO creation and operation (2nd level shown)

56

Discovering and Modelling Enterprise Engineering Project Processes

controls, outputs, and mechanisms (ICOMs) are defined for these activities (see Figure 13, where inputs can be omitted if justified). Therefore, the user has to give consideration to what (if anything) is used in the activity, what controls it, what is produced by the activity and who/what executes it. This information can be construed from the roles shown in the business model and further domain knowledge. Each activity must be recursively decomposed down to a level where it can be directly executed; this can be assisted by a checklist of views used in previous steps and/or the chosen MF (if any) and/or available in the MFs contained in the SR. For example, if GERAs MF is chosen, the checklist contains function, information, resources, organisation, management vs. production/service, human roles, and hardware/software. For example, in Figure 16, management vs. production/service and human role views have been used to decompose the detailed design activity.

Note that not all aspects are relevant to all life cycle phases. For example, early life cycles (e.g., identification, concept) require few or no aspects, and the human aspect may only be visible/relevant in the preliminary/detailed design phases, such as illustrated in Figure 2.

example: creating the second Level of the functional Model

Figure 10 shows that the MS entity is influenced by the University U, across campus consistency (ACC), project and by the project that builds it, namely ITM. The first phase in the life cycle of MS is the identification of the need for this artefact. However, in this case, domain knowledge obtained from stakeholders has established that this phase has already been accomplished by U (i.e., the PVC has determined the need for an MS and mandated its creation) thus, identification does

Figure 15. Decomposition of the requirements activity (3rd level IDEF0 model)

57

Discovering and Modelling Enterprise Engineering Project Processes

Figure 16. Decomposition of the detailed design activity (3rd level IDEF0 model)

not need to be represented in the activity model in this case. The concept phase is accomplished under the control of the mandate from PVC, ACC reviews that show what needs to be addressed and Us policies. The work to define the concept of MS is carried out by a working party composed of U staff, the majority of which are in fact also staffing the ITM project. No inputs are present. The outputs reflect the creation and refinement of the MS concept, such as goals, objectives, and responsibilities of the MS. The main changes brought by this EE project are in the management area. Thus, the requirements definition process needs to investigate suitable management structures and in addition, make needed corrections to the MS concept. For this purpose this activity needed to contain the

creation and use of decisional / organisational frameworks (such as shown in Figure 11 and Figure 12). These sub-activities are shown in Figure 15. In this case study, only organisational models were able to discern between various TO-BE states. Therefore, the preliminary design phase must develop organisational structures reflecting various scenarios and recommend/seek stakeholders approval for the optimal one. The detailed design activity was further decomposed according to the GERA implementation criterion, thus showing management vs. production/service and human roles, as shown in Figure 16. Further decompositions then discerned between hardware and software-oriented activities. (Noran, 2004a) contains the relevant diagrams.

58

Discovering and Modelling Enterprise Engineering Project Processes

The VO implementation process must set up the transition process and then implement the detailed specifications produced by the detailed design sub-activities (thus some of its decomposition was similar to detailed design activity). In this case, the operation process of the School can be decomposed in operation and monitoring (producing internal information for the management and requests for change that cannot be handled at operational level). The EE project did not include a detailed operation of the VO, thus no decompositions below level three have been produced for this activity. A full description of the activity model creation and structure (which is beyond the purpose of this chapter) is contained in Noran (2004b). Note that the activity model created represents only one of the many possible suitable solutions to this EE problem.

concLusIon And further work

A practical problem in EE projects is not knowing what exactly needs to be done since potentially usable methods, reference models, modelling frameworks, etc., are rather general in nature. Furthermore, several such AF elements are often suitable for any given area of the project in question, although their modelling efficiency varies greatly depending on aspect, life cycle phase, and specialisation required. Selecting and customising suitable AF elements requires knowledge of such artefacts, which is not normally available. However, domain knowledge describing the problems that triggered the project, specific features, and relations between project participants, etc., is typically available within stakeholders and/or project champion(s), even if often in a tacit form needing to be elicited. In conclusion, help is needed to discover and model what needs to be done for a specific EE project and to select AF elements that suit the

particular project but also the host organisations specific proficiencies, legacies, and culture. This chapter has described a method aiming to assist the discovery of activity types involved in accomplishing specific EE tasks and to provide guidance for the selection of AF elements needed to model and manage those tasks. The proposed meta-methodology achieves these goals through a meta-methodology environment comprising a set of steps and an SR containing AF elements assessed and organised in respect to a suitable reference (GERAM). Research currently in progress aims to implement the KB and SR in a Web-based, open source expert system for possible use as a decision support system for upper/middle management. Future research efforts in this area will be focused toward formalising the meta-methodology environment and enriching the content of the KB by mapping additional AF elements against the chosen reference. Further field-testing and refinement of the KB rules and meta-methodology steps is also needed in order to improve its accuracy and usefulness.

references
C4ISR Architectures Working Group. (1997). Command, control, communications, computers, intelligence, surveillance, and reconnaissance C4ISR. Retrieved 2004, from http://www.cisa. osd.mil Camarinha-Matos, L.M. (2004). Virtualenterprises and collaborative networks. Proceedings of IFIP 18th World CongressTC5/WG5.5 (PROVE 04): 5th IFIP Working Conference on Virtual Enterprises). Toulouse / France: Kluwer Academic Publishers. CIMOSA Association. (1996). CIMOSAOpen system architecture for CIM. Technical Baseline, ver 3.2. Private Publication.

59

Discovering and Modelling Enterprise Engineering Project Processes

Department of Defence Architecture Framework Working Group. (2003). DoD architecture framework. Retrieved 2004, from http://aitc. aitcnet.org/dodfw/ Department of the Treasury CIO Council. (2000). Treasury enterprise architecture framework (v.1). Washington, DC: Department of Treasury. Doumeingts, G. (1984). La Methode GRAI. Unpublished Doctoral Thesis, University of Bordeaux I, Bordeaux, France. Doumeingts, G., Vallespir, B., & Chen, D. (1998). GRAI Grid decisional modelling. In P. Bernus, K. Mertins, & G. Schmidt (Eds.), Handbook on architectures of information systems (pp. 313-339). Heidelberg: Springer Verlag. Doumeingts, G., Vallespir, B., Zanettin, M., & Chen, D. (1992). GIM-GRAI integrated methodologyA methodology for designing CIM systems. Bordeaux: Version 1.0, Unnumbered Report, LAP/GRAI, University Bordeaux 1. Globemen. (2000-2002). Global engineering and manufacturing in enterprise networks (IMS project no. 99004 / IST-1999-60002). Retrieved from http://globemen.vtt.fi/ GRAISoft. (2002). IMAGIM software product. Retrieved August 2002, from http://www.graisoft. com ISO/TC184. (2000). Annex A: GERAM. In ISO/IS 15704: Industrial automation systems - Requirements for enterprise-reference architectures and methodologies. Levi, M. H., & Klapsis, M. P. (1999). FirstSTEP process modelerA CIMOSA-compliant modeling tool. Computers in Industry, 40, 267277. Menzel, C., & Mayer, R. J. (1998). The IDEF family of languages. In P. Bernus, K. Mertins, & G. Schmidt (Eds.), Handbook on architectures of

information systems (pp. 209-241). Heidelberg: Springer Verlag Berlin. NIST. (1993). Integration definition for function modelling (IDEF0) (No. 183: Federal Information Processing Standards Publication): Computer Systems Laboratory, National Institute of Standards and Technology. Noran, O. (2003a). A mapping of individual architecture frameworks (GRAI, PERA, C4ISR, CIMOSA, Zachman, ARIS) onto GERAM. In P. Bernus, L. Nemes, & G. Schmidt (Eds.), Handbook of enterprise architecture (pp. 65-210). Heidelberg: Springer Verlag. Noran, O. (2003b). UML vs. IDEF: An ontologyoriented comparative study in view of business modelling. In I. Seruca, J. Filipe, S. Hammoudi, & J. Cordeiro (Eds.), 6th International Conference on Enterprise Information Systems (ICEIS 2004) (Vol. 3, pp. 674-682). Porto / Portugal: ICEIS. Noran, O. (2004a). A meta-methodology for collaborative networked organisations. Unpublished Doctoral Thesis, School of CIT, Griffith University. Noran, O. (2004b). A meta-methodology for collaborative networked organisations: A case study and reflections. In P. Bernus, M. Fox, & J. B. M. Goossenaerts (Eds.), Knowledge sharing in the integrated enterprise: Interoperability strategies for the enterprise architect (Proceedings of International Conference on Enterprise Integration Modelling and Technology ICEIMT04). Toronto, Canada: Kluwer Academic Publishers. Popkin Software. (2001). Building an enterprise architecture: The Popkin process. Retrieved October 2002, from www.popkin.com Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The unified modelling language reference manual. Reading, MA: Addison-Wesley.

60

Discovering and Modelling Enterprise Engineering Project Processes

Scheer, A. W. (1992). Architecture for integrated information systems. Berlin: Springer-Verlag. Scheer, A. W. (1994). Business process engineeringReference models for industrial enterprises. Berlin: Springer-Verlag. Scheer, A. W. (1998a). ARISHouse of business engineering. In A. Molina, A. Kusiak, & J. Sanchez (Eds.), Handbook of life cycle engineering Concepts, models, and technologies. Dordrecht: Kluwer Academic Publishers. Scheer, A. W. (1998b). ARISBusiness process modeling (2nd ed.). Berlin: Springer-Verlag. Scheer, A. W. (1999). ARISBusiness process frameworks (3rd ed.). Berlin: Springer-Verlag. Sowa, J. F., & Zachman, J. A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 590-616. The Open Group. (2006). The open group architecture framework (TOGAF). Retrieved Mar 2006, from http://www.opengroup.org/togaf/ Tlle, M., & Vesterager, J. (2002). VEM: Virtual enterprise methodology. In I. Karvoinen, R. van den Berg, P. Bernus, Y. Fukuda, M. Hannus, I. Hartel, & J. Vesterager (Eds.), Global engineering and manufacturing in enterprise networks (Globemen). VTT Symposium 224. Helsinki, Finland.

U.S. Federal CIO Council. (2006). Federal enterprise architecture framework (FEAF). Retrieved March 2006, from http://www.itpolicy. gsa.gov/mke/archplus/fedarch1.pdf Williams, T. J. (1994). The Purdue enterprise reference architecture. Computers in Industry, 24(2-3), 141-158. Williams, T. J. (1988). CIM reference model committee: A reference model for computer integrated manufacturing (CIM)A description from the viewpoint of industrial automation (2nd ed.). Research Triangle Park, NC: Instrument Society of America. Williams, T. J., Rathwell, G. A., & Li, H. (2001). A handbook on master planning and implementation (No. Report 160). West Lafayette, IN: Purdue Laboratory for Applied Industrial Control. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276-292. Zachman, J. A. (2000). Zachman framework definition and enterprise architecture quick start. Retrieved June 2002, from www.zifa.com Zelm, M., Vernadat, F., & Kosanke, K. (1995). The CIMOSA modelling process. Computers in Industry, 27(2), 123-142.

61

62

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Tae-Young Kim Pohang University of Science and Technology, South Korea Sunjae Lee Pohang University of Science and Technology, South Korea Jeong-Soo Lee Pohang University of Science and Technology, South Korea Kwangsoo Kim Pohang University of Science and Technology, South Korea Cheol-Han Kim Daejeon University, South Korea

Chapter IV

AbstrAct
Virtual enterprise (VE) has become a prime candidate to survive under the increasingly turbulent and competitive business environment. In order to quickly respond to the rapidly changing business environment, the agility and interoperability are regarded as the core requirements for the VEs. Unfortunately, there is no previous approach to fully support configurations of the agile and interoperable VE. The systematic modeling framework based on the meta-model driven approach could be used for business domain experts and developers to construct VE models quickly and systematically with insights. It should be noted that this chapter aims to present a systematic modeling framework itself, not to generate only instances of VE models. Based on the proposed framework, business domain experts and developers would configure all of VE models such as VE architectures, modeling languages, model transformations, and deployment models, as well as instances of VE models.

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

INtrODUctION
Today, enterprises are facing a rapidly changing business environment and can no longer make predictable long-term provisions. Moreover, business competition is no longer enterprise to enterprise, but value chain to value chain (Cadence Design Systems, 2003). In order to respond to these business environments, most competitive enterprises seek to enhance competitive performance by closely integrating internal operations and effectively linking them with the external operations of suppliers, customers, and other business partners. As each enterprise operates as a node in the network composed of suppliers, customers, engineers, and other specialized service providers, collaborations among multiple business partners are becoming important (Barnett, Presley, & Liles, 1994; Camarinha-Matos & Afsarmanesh, 2003; Jagdev & Thoben, 2001). The virtual enterprise (VE), which is a collaborative network across the value chains, has become a key factor to survive under the competitive business environment. For efficient collaborations among the business partners of the VE, the agility and interoperability among heterogeneous enterprise models in different business domains of interests is required. The agility is the capability to flexibly adapt enterprise models of VE in order to cope with unanticipated business environments. The interoperability means seamless communications among enterprise models, which can be shared and exchanged. To guarantee the agility and the interoperability, participants of the VE must understand each other through EA of participant enterprise. The EA mean business components and their relationships that are required for business activities. Business components are things such as application, data, technology, and business architecture that require enterprise business. Hence, EA of VE describes business components and their relationship that are required by business partners.

In order to establish and manage an agile and interoperable VE, it is keenly necessary to develop a systematic methodology for configuration of a VE based on the collaborative business processes. It should be noted that the configuration of a VE in this chapter means not only the designing instances of VE models, but also the designing VE architecture, modeling languages, and deployed models. The goal of this chapter is to introduce a new systematic modeling framework that can be used for designing and managing the agile and interoperable VEs. The systematic modeling framework has a hybrid approach that harmonizes the up-to-date technologies such as enterprise architecture (EA), model driven architecture (MDA), meta-modeling approach, domain specific methodology (DSM), model transformation, framework-based development, and so on. It combines the advantages of the heterogeneous technologies so that it can produce integrated synergy effects, as well as it can take individual advantages of each technology. This proposed modeling framework provides modeling concepts that underpin the representation of all of the VE from different viewpoints, at different levels of granularity, generality, and abstraction during different life cycle of a VE. It would be used systematically by business domain experts and developers who want to design and manage a VE quickly and effectively. The rest of this chapter is organized as follows. Requirements of VE to Support the Agility and Interoperability Section, describes the requirements of the VE to support the agility and interoperability. Literature Review Section, reviews the related researches. In Systematic Modeling Framework for the Agile and Interoperable VE Section, we introduce our systematic modeling framework for the agile and interoperable VEs. Finally, Discussion and Conclusion Section, provides some conclusions and gives some suggestions for future work.

63

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

rEQUIrEMENts OF VE tO sUPPOrt tHE AGILItY AND INtErOPErAbILItY Definition of VE

Since the advent of the concept of the VE in the 1990s, many studies have progressed. The interest of a researcher is generally given to the development of models, protocols, infrastructures, and mechanisms for VE interoperation (Camarinha-Matos et al., 2003; Gou, Huang, Liu, & Li, 2003; NIIP). Nevertheless, the definition and features of the VE have not even been prescribed completely yet. A variety of terms and definitions have been used in various ways by scholars with different viewpoints. Carmrinha-Matos et al. summarize the common keywords from several definitions of the VE as follows: Cooperation and complementarities. Networked or distributed organization. Temporary organization. Infrastructure supporting interoperation.

From the several previous definitions and keywords, the VE is considered as a temporary organization in which various distributed business partners form a cooperative network on the value chain. Therefore, it is important to establish a value chain systematically and quickly with core competitive functionalities that are the business processes in the form of the set of the service components of the business partners. Consequently, we re-define the following terminologies, the VE and the value chain, as follows: Virtual enterprise (VE): In order to realize the common business goal which is to secure business opportunity, the VE is an active collaborative organization structure which is temporarily made up of value chains. Value chain: A value chain is a comprehensive collection of all of the loosely-coupled business processes of distributed business partners who offer the core complementary functionality and resources.

Figure 1. Concept of VE
Higher-Level Virtual Enterprise
Business Development Chain Product Design Chain Supply Chain Sales & Marketing Chain

Higher-Level Value Chain

Component Manufacturing #1 Supplying #2 Retailing #1 Product Manufacturing #1

Wholesaling #1

Retailing #2

Customer

Lower-Level Virtual Enterprise

Lower-Level Virtual Enterprise

Receive Manufacturing Ship

Lower-Level Virtual Enterprise

retailer #1

Product Manufacturer #1

retailer #2

Lower-Level Value Chain

64

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

According to these definitions, it is possible to understand the concept of the VE as Figure 1. The VE is made up of the hierarchical value chains and each value chain is recursively made up of the collaborative business processes, the lowerlevel VE, and the lower-level value chains. This composition manner among the VEs, the value chains, and the collaborative business processes is repeated recursively until these cannot be divided any more.

Requirements for VE
It has not been easy to develop and realize the VE due to several obstacles. Firstly, real business processes of VE are diverse and complex. Because their business processes are very contextdependent and resource-dependent, it is not suitable to apply a specific traditional methodology. The traditional methodology is too generic to be utilized for the specific type of business processes of a specific business domain (Harmon, 2003a). Secondly, VE has multiple stakeholders who are interested in different aspects of the enterprise models. In most cases, a number of the enterprise

models are distinguished separately, such as different perspectives and different views. But there is no comprehensive approach that enables the integrated enterprise modeling. Thirdly, business processes of VE are very distributed and heterogeneous across value chains. The applications in VE should be performed on distributed and heterogeneous platforms with different types of information and different levels of functionality (Zarli & Richaud, 1999). However, there is a lack of standard definitions and effective mechanisms, which are guaranteed the agility and interoperability of VE models. Therefore, it is necessary to develop a common modeling framework to settle the previously mentioned obstacles. It should provide a narrowfocused modeling approach for representing a specific business domain. On the other hand, it should also provide a coherent modeling approach that supports the representation of VE models from different viewpoints, at different perspectives during the life cycle of the VE, and it should provide a standard mechanism that supports the agility and interoperability of VE models on the heterogeneous platforms in the distributed network.

Figure 2. Technology architecture

Virtual Enterprise
Collaborative or Complementary Organizations Networked or Distributed Organizations Optimized Organizations Innovative Organizations

Agility

Interoperability

Systematic Modeling Framework

Enterprise Architecture Framework Framework-based Development Business Process-centric Architecture Meta-Modeling Approach Domain-Specific Methodology Model-Driven Architecture Service-Oriented Architecture Model Transformation Ontology Engineering Enterprise Modeling Language

65

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

LItErAtUrE rEVIEW
There is a research area for the integration of all knowledge that is needed to support the enterprise development, the enterprise management, and the enterprise integration. This research area is called enterprise engineering. Enterprise engineering can be used to support the life cycle of the VE (Vernadat, 1996). Each technology has been dealt in different interests and developed independently to address its own purpose. Even if they have the advantages in their own viewpoints, they have not provided a complete solution to support all aspects of the VE configuration. Therefore, it is keenly to develop a well-established common methodology to completely support the configuration of the agile and interoperable VEs through the VE life cycle. Focusing on the agility and interoperability of VE, we present a technology architecture that includes several technologies of enterprise engineering as illustrated in Figure 2. In this chapter, we consider that these relevant technologies play important roles in developing the systematic modeling framework for the agile and interoperable VEs.

EA Framework
A VE consists of business processes and various business components such as information, systems, organizations, and so on, which can be classified according to diverse levels and points of view. The term enterprise architecture (EA) refers to a comprehensive description of all of the key elements and relationships that make up an enterprise (Harmon, 2003b). In other words, the EA identifies the essential processes performed by the VE, and how the VE performs these processes, and includes methodologies for the rapid reconfiguration of the VE. As one of the earliest systematic frameworks, the Zachman framework (Zachman, 1987; ZIFA) is made up of

a number of other architectures that are focusing on different, specific areas of concern. The most extensive efforts in the development of reference architecture for a single enterprise have been undertaken by the generalised enterprise reference architecture and methodology (GERAM) (IFIP-IFAC Task Force, 1999). The GERAM framework includes harmonization with software engineering, system engineering, and the developments of frameworks such as Perdue enterprise reference architecture (PERA) (Williams, 1993), computer integrated manufacturing open systems architecture (CIMOSA) (Vernadat, 1993), GRAI integrated methodology (GIM), Zachman framework, and so on. Based on GERAM, virtual enterprise reference architecture (VERA) and its methodology is developed to enable rapid formation of customer-focused and customer-tailored VEs by taking advantages of information technology (IT) (Vesterager, Tolle, & Bernus, 2002). Although current EAs provide approaches to generations of EA models and products and to management procedure of EA models, they are missing the big picture. It means that they have no concept to inter-relate the relevant elements and have no integration mechanism for different views and different perspectives. Also, they have no collaboration mechanism for different value chains.

Enterprise Modeling Language

Enterprise engineering applies various enterprise modeling languages to develop and manage the business processes and business components. Although generic purpose modeling languages such as UML (Booch, Rumbaugh, & Jacobson, 1999), IDEF (Ang, Khoo, & Gay, 1999) series, and so on, have been developed as the collection of multiple types of diagrams they have poorly defined relations between them. This may cause either the redundancy or the loss of some subset

66

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

models. Another restriction is that generic purpose modeling languages are too general to correctly design the specific models of a specific business domain. As the business process-centric approach is becoming a major topic for all kinds of businesses, some of the following languages are emerging: the business process definition meta-model (BPDM) (Object Management Group, 2003a), business process modeling notation (BPMN) (Business Process Management Initiative, 2003), business process execution language for Web service (BPEL4WS) (Andrews et al., 2003), Web services description language (WSDL) (W3C, 2001), and business process modeling language (BPML) (Arkin, 2002). BPEL4WS, WSDL, and BPML are XML-based languages for modeling the business processes that are originated from platform specific process language. Recently, UML 2.0 has been developed and addresses many issues to make strides toward becoming the standard notation for depicting architectures (Object Management Group, 2003b, 2003c).

shifting the modeling concept from code levels to design levels. However, while MDA emphasizes presenting the architecture and the guideline for the meta-modeling, DSM emphasizes freely developing an abstract graphic language, which developers can use easily and accurately in the specific business domain. As DSM lacks integration mechanism currently, DSM cant provide really linking mechanism among narrowly domain-focused languages. DSM has a limitation to design, not only domain specific VE models, but also domain integrated VE models in order to support a coherent modeling.

Meta-Modeling Approach
As a meta-model means the rendering of a language definition as an object model, the metamodeling approach is becoming a standard way of defining and managing the meta-models that is used for designing the VE models. Therefore, it can be used for enabling the designed models and the defined meta-models to have the interoperability with each other. Recently, it has been demonstrated that the meta-modeling can be used to define concrete syntax and abstract syntax, as well as semantics. OMG has suggested the concept of UML profiles in the form of the extended UML meta-model to make good use of the particular domains (Object Management Group, 2003b, 2003c, 2004a). It has been discussed how a UML profile can be defined for specific domains that require a specialization of the general UML mete-model in order to focus UML to more precisely describe the domain.

DsM
Since the VE models have the characteristics of complexity and diversity, as well as context-dependency and resource-dependency on the business domains, it is difficult to use the generic purpose modeling languages as it is. The DSM intends to freely develop abstract graphic languages that business domain experts or developers can easily and accurately use in a specific business domain in order to design and manage a model through shifting the modeling concept from code levels to design levels (Frankel, 2004; MetaCase, 2005). Consequently, the DSM lets developers use the knowledge and skills of business domain experts to design VE models easier. DSM is similar to model driven architecture (MDA), as they intend to design and manage a model itself in the business domain through

MDA
As the technology platforms of the VE continue changing quickly and the demands of integrating the heterogeneous legacy systems continue to grow, the MDA has created a buzz of interest by promising to increase the productivity, flexibility,

67

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

and portability of VE models (Object Management Group, 2002a). The MDA defines an approach that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform, and it also defines an approach for software development based on modeling and automated mapping of models to implementations. The MDA makes a distinction among the computation independent model (CIM), the platform independent model (PIM), and the platform specific model (PSM). According to this, it provides an open and technology-neutral approach to the challenge of business and technology change (Miller & Mukerji, 2003). The MDA also defines the 4-layer architecture for structuring the meta-modeling. It would be a sound foundation for this metamodeling approach in this chapter. Therefore, we define a meta-model in the form of UML profile at M2 (meta-model) layer. Although MDA is in the limelight of software engineering, there is no well-established concrete methodology for realizing MDA. To give an example, model transformation between PIM and PSM is indispensable in MDA. However, the mechanism or implementation for the model transformation is not thoroughgoing enough up to now.

their loosely coupled integration. Consequently, the framework-based development allows improving and accelerating the development of enterprise models in VE. The Supply Chain Council (SCC) established the supply chain operations reference model (SCOR) for the supply chain management domain (Supply Chain Council, 2003). In the domain of telecommunication, the next generation operations systems and software (NGOSS) are proposed by telemanagement forum (TeleManagement Forum, 2002). The instrumentation, systems, and automation society (ISA) have tried to standardize the processes in manufacturing execution system (MES) domain (Instrumentation, Systems, and Automation Society, 2004). However, as the current framework-based development does not separate each element of enterprise models such as business process, application, information, etc., they are too mixed-up and complex to assure agility and flexibility of the VE models. Thus, in this chapter, we bring component-based architecture and serviceoriented architecture in the framework-based development in order to manage independently the elements of enterprise models.

Business Process-Centric Architecture

According to Smith and Fingar (2003), the business process management will be the heart of the future business systems and will support the dynamic integration and collaboration of all participants in the value chain. In the context of this chapter, the basis of the collaboration in a VE has evolved from the data-centric enterprise integration into the process-centric enterprise integration (CSC, 2002). In consequence, the VE is more focused on what can be done to achieve the common goal, and it has to be more dynamic and loosely-coupled with the value chains. The value chain of VE is defined as a set of linked business processes that

Framework-Based Development
The framework-based development is usually said to be the second generation business process methodology (Harmon, 2003a). Important efforts are dedicated to exploiting the best practices and the design patterns of the business processes, the business components, and the architectural frameworks for the coherent design and implementation. Since many quality properties such as the maintainability, portability, efficiency, reusability, etc., rely on framework-based development, it is essential to establish agile and interoperable VEs and

68

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

are distributed at business partners. And these business processes should be managed and controlled autonomously and in a distributed manner because each business partners can be in different places and different time zones.

Ontology Engineering
It is even the case that the business functionalities and information of the VE are not properly understood yet. In other words, the VEs usually have some problems related to the interoperability of vocabularies for the enterprise models in different business domains because they are just temporary and distributed organizations across several business boundaries. In order to achieve interoperability regardless of the heterogeneities of business domains, it is needed to define the ontology and semantics with standardized mechanisms. Although the importance of ontology engineering is well understood, it is also known that building a good ontology is a hard task. There are some approaches that present the procedure and the guidelines for ontology development (de Falbo, de Menezes, & da Rocha, 1998). Uschold, King, Moralee, and Zorgios (1997) aim to provide an environment for integrating and capturing key aspects of an enterprise based on ontology. There is another big project for enterprise ontology development: Toronto virtual enterprise (TOVE) project whose goal is to create generic and reusable enterprise ontology (Fox & Gruninger, 1998). The semantic Web movement also discusses the importance of ontology engineering. In order to realize the semantic Web, Berners-Lee defined three distinct levels that incrementally introduce expressive primitives: meta-data layer, schema layer and logical layer (Berners-Lee, 1998). Based on the Berners-Lees levels, Web ontology languages built on uniform resource identifier (URI) and XML (extensible markup language) technology, such as resource description framework (RDF) and RDF schema, are used

for representing information and for the defining semantics of terminology. Recently, Web ontology language (OWL) that is built on top of RDF/RDF schema became a standard recommended by the World Wide Web Consortium (W3C) (W3C, 2004). In this chapter, the ontology engineering is associated with the systematic modeling framework for the agile and interoperable VEs. It offers the basis for the model transformation and the model synchronization in a general open universe of businesses.

Model Transformation
As the model transformation is the process of converting one model to another model, it is of interest for defining synchronization among the models within or across VEs. Therefore, it is undoubtedly considered as a major matter that plays a vital role in our systematic modeling framework for the agile and interoperable VEs. As research area on model transformation is a relatively new area, its taxonomy is defined lately. Some researches have tried to classify and analyze various model transformation techniques in different domains in order to provide an insight into this new area (Czarnecki & Helsen, 2003; Prakash, Srivastava, & Sabharwal, 2006; Sendall & Kozaczynski, 2003). Currently, several researches are performed in the direction of how to express the transformation between models. Gerber, Lawley, Raymond, Steel, and Wood (2002) have indicated that the model transformation is the missing link of MDA. They have tried to express mapping from the enterprise distributed object computing (EDOC) business process model to the breeze workflow model using a number of different model transformation technologies.

SOA and Web Service

Contrary to the conventional tightly coupled object-oriented paradigm, service oriented ar-

69

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

chitecture (SOA) is the new emerging paradigm for building the agile networks of collaborating business applications distributed within and across business boundaries. As the SOA separates the service interface from the service implementation, it enables service components to be fine-grained and isolated. This separation produces an architecture style that promotes the collaborations among the VE models to be extremely loose and easily reconfigured at the enterprise application level. The SOA serves as glue between well integrated IT systems and well-defined business processes. It encourages the definition and the deployment of the business processes. Although Web service is not the only way to accomplish the SOA, it is usually considered as the ideal candidate for collaboration among the models of the virtual enterprises on the open and loosely coupled platform. The SOA and Web service can bridge the gap between diverse applications and address the increasing need for the agility and interoperability of the VE models. However, current SOA focuses on collaborations at the enterprise application level. As this chapter promotes the concept of the SOA to higher types of VE collaboration, it applies the SOA into the designing of VE architecture, modeling languages, and VE models, as well as the deployment of VE models.

chapter proposes a synthesized architecture and a procedural framework. We combine all relevant technologies into the synthesized architecture. Based on this synthesized architecture, we guide business domain experts and developers through the procedural framework to the entire VE modeling.

Synthesized Architecture
Figure 3 represents diagrammatically the synthesized architecture. First of all, the synthesized architecture is based on EA because EA is usually considered as a systematic approach to configuration and analysis of enterprises or enterprise systems. Our synthesized architecture is based on the original Zachman framework. In our framework, we substitute two dimensions with the perspective layers and the modeling domains, respectively. The shown EA in Figure 3 is just only an example for understanding. It can be extended or modified flexibly according to the characteristics of a VE or the interests of business domain experts. Based on the EA, we combine several technologies such as the MDA, the model transformation, the ontology engineering, and the SOA for the perspective layer integration. Applying the MDA, we regard contextual and conceptual layers as CIM of the MDA. In the same way, we regard logical layer and physical layer as PIM and PSM of the MDA, respectively. In the context of this chapter, these presumptions are sufficient to represent all of the who? (perspective) on VE models. In the relationship between logical layer and physical layer, we apply the model transformation and the ontology engineering in order to transform PIM to PSM. The Web services based on the SOA particularly is applied to PSM of the MDA, because it is considered as a suitable technology on the loosely coupled platform. For the modeling domain integration, we combine the business process-centric architecture

sYstEMAtIc MODELING FrAMEWOrK FOr tHE AGILE AND INtErOPErAbLE VE

These mentioned technologies have their own advantages, but they are dealt in separate interests and were developed independently to address their own purpose. Therefore, it is necessary to develop a common modeling framework that integrates these up-to-date technologies in order to configure the agile and interoperable VEs. In order to establish this systematic modeling framework, this

70

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Figure 3. Synthesized architecture

( Meta-Meta Model )

M3 Layer

MOF Meta-Meta-Model

UM
DSL DSL UML Meta-Model DSL DSL

e LM

ta

DSL

( Meta Model )

M2 Layer

DSL

DSL

DIL (UML Profile) for CIM DSL DSL DSL

L DI

L D S CI M r fo

DIL (UML Profile) for PIM

Com putation I ndependent M odel P latform I ndependent M odel P latform Specific M odel

CI PI PS M M

DIL (UML Profile) for CIM PIM

M1 Layer ( Model )

PSM

er ay Contextual eL rs tiv tion ye ec a La Conceptual rsp te gr ve ti Pe In ec Logical rsp Pe Physical

Pr s es oc n y n on tio ati tio l og ca niz ma no pli ga ch for Ap Te Or In

Enterprise Architecture

Modeling Domains Modeling Domain Integration

and the SOA. According to the VE definition, we declare that a VE is made up of value chains with collaborative business processes. In consequence, the process domain is a main interest of the modeling domains and other modeling domains do a role to support the process domain. To realize it, we also apply the SOA, which means the component-based architecture for each modeling domains. In order to support the integration of VE modeling, we combine the meta-modeling approach and the MDAs 4-layer meta-modeling architecture. The componentized CIM, PIM, and PSM at the M1 (model) layer are built in the EA as shown in Figure 3. Above the M1 layer, there is the M2 (meta-model) layer where the modeling languages are defined to describe each model. Above the M2 layer, there is the M3 (meta-metamodel) layer, which is the top layer in the MDA architecture. We introduce the idea of a family of inter-related, but individually specialized,

modeling language which is based on the DSM. In other words, we apply the DSM into the M2 layer in order to freely develop modeling languages, which developers can use easily and accurately in their specific business domains.

Procedural Framework
In order to support the entire VE modeling, our systematic modeling framework is organized as shown in Figure 4. The left side of Figure 4 shows the procedure for the configuration of the VE. It contains four phases focusing on details of the configuration. These phases will be described in detail in the following sections. The right side of Figure 4 briefly shows the facilities supporting each phase. There are several facilities that support each phase. Each modeling facility such as EA designer, DSL/DIL designers, CIM/PIM modelers, and PSM mapper is associated with its relevant reference

Overall Integration

FM MO

Me aet

ta

el od

l de Mo

71

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

repository, ontology repository, and local instance repository. To increase portability, agility, and interoperability of the models, each modeling facility enables to reuse the best practices stored in each reference repository under the concept of the framework-based development. To support

the communication and the comprehension for retrieval and use, each modeling facility is also connected with the ontology repository. The procedure of the entire VE modeling under the systematic modeling framework is described with IDEF0 model as shown in Figure 5.

Figure 4. Procedural framework

Distributed R epository for R eference M odels
EA Repository
Product Zachman FEAF GERAM

EA Design Phase
Local Repository

Model DoDAF Procedure

TOGAF BCF

Defining EA

EA Designer

DSL/DIL Repository DSL/DIL Design Phase

Abstract Syntax Semantic UML2 BPMN EDOC YAWL BPDM SysML IDEF PSL XLANG WfMC

V E Con figuration

Local Repository

Defining Modeling Languages

INTERNET

DSL/DIL Designer

Concrete Syntax

Ontology Repository

CIM/PIM Modeling Phase

Local Repository

Enterprise Model Repository

Business Process Application SCOR NGOSS OAGIS ITS ISA 95

CIM Modeler Designing VE Models

Local Repository

Information Organization Etc.

Deployment Phase

PIM Modeler

Deploying VE Models PSM Mapper

Figure 5. Procedure of entire VE modeling

Busines Goal Business concept Business Partners Design EA A1 Enterprise Architecture Enterprise Architecture

Design DsL/DIL A2

DsL/DIL

DsL/DIL

Model cIM/PIM A3

cIM/PIM

cIM/PIM

PIM

Deploy A5

PsM based on WebServices

repository of EAF reference Model

repository of DsL/DIL reference Model

repository of Enterprise reference Model

Ontology repository

Distributed repository of reference Model EA Designer DsL/DIL Designer cIM/PIM Modeler PsM Mapper

72

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

EA Design Phase
First of all, the standardized collaborative models of the VE are established through the EA. It is for that reason that an EA defines all the business components and business processes of a VE and explains how all the enterprise components work together as a whole. It is important that formal EA specification should ideally capture all the aspects that are unique to the enterprise system and also help in making various architecture decisions. The procedure to establish the EA is described as follow: Determining the organizational structure of the VE: The organizational structure of the VE is determined. Assigning the roles of each major partner: The roles are assigned to the selected major partners Decomposing views and perspectives: Because the VE models can be understood in a broad sense, from a number of different

views at different abstract levels, the process of decomposing and separating concerns of various participants is performed. Establishing EA: Through the process of decomposing and separating concerns of various stakeholders, an EA can be built to support these different views and different abstract levels. Fulfilling EA: Once we have established an EA, we begin to collect everything that fulfills it such as business process models, information models, resource models, etc., from the suitable reference repositories.

For EA of VE, we suggest a meta-model of the EA as illustrated in Figure 6. Basically, the EA has several perspective layers and some views. Each EA cell that is produced by a pair of a perspective and a view provides a container of the cell content lists, the modeling language, and the enterprise models. The perspectives correspond to the MDA models and the views correspond to the modeling domains. In addition, Figure 6 also

Figure 6. Meta-model of EA
En terprise Arch itectu re Fram ew ork
Enterprise Architecture

M odel Driven Arch itectu re

MDA Model

1..*

1..*

S ervice Orien ted Arch itectu re

Modeling Domain
1..* -supportedby

Perspective

View

M odel Tran sform ation On tology En gin eerin g

PsM PIM cIM Enterprise Architecture cell Process
1 -reifiedby -reifiedby 1 0..* 1 0..* 1 0..*

B u sin ess Proce ss-cen tric arch itectu re

Model
-modeledwith

M eta-m odelin g A pproach

Modeling Language

contents

Fram ew ork -based Deve lopm en t

DsL DIL Enterprise Model Enterprise Reference Model

Dom ain Specific M eth odology

73

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

shows how the relevant technologies are reflected in the meta-model of the EA. To define EA for VE, we introduce two assumptions into the EA: One is that each view of the EA corresponds to one modeling domain. The other is that each perspective of the EA refers to the models of MDA such as CIM, PIM, and PSM (Frankel et al., 2003). In the context of this chapter, these assumptions are sufficient to represent all of the who? (perspective) and what? (view) on the VE models.

For example, we can divide the views of the EA into the following 5 modeling domains. 1. 2. Process domain: Focusing on the business processes, which are the core of the EA. Application domain: Focusing on the business applications supporting the business processes. Information domain: Focusing on the business information or system information supporting the business processes and applications respectively. Organization domain: Focusing on the participants responsible for the supporting and execution of the business processes. Technology domain: Focusing on the technology environment and infrastructures supporting the business applications.

3.

Modeling Domains: What?

According to our definition of the VE, EA design is usually based on efforts to divide all work of the VE into value chains, which are repeatedly subdivided into the business processes. Therefore, it is natural that our EA seems to be a processcentric framework.

4.

5.

Figure 7. EA designer

74

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Perspective Layers: Who?

Meanwhile, the rows of the EA are made for the different perspectives. For example, the perspectives can be the contextual layer, conceptual layer, logical layer and physical layer. Contextual layer: Defining the goal, purpose, and visions of the VE, which restrict the business boundaries. Regarded as CIM in the MDA. Conceptual layer: Designing the models of value chains as business scenarios in business terms. Regarded as CIM in the MDA. Logical layer: Designing the models of the business processes and the business components in more rigorous terms than conceptual layer. Regarded as PIM in the MDA. Physical layer: Designing the deployed models related with specific technology. Regarded as PSM in the MDA.

the modeling languages within CIM and PIM of the MDA at the M2 layer. More information about the generation of PSM is described in the deployment phase of Section 4.6. The DSL/DIL design proceeds on a two-step development. The two steps to design DSLs and DILs are briefly summarized as follows: Firstly, DSLs for CIM and DSLs for PIM are designed for each EA cell. Secondly, DSLs for CIM and DSLs for PIM are simply assembled into DIL for CIM and DIL for PIM, respectively. As this DSL/ DIL design phase is based on the meta-modeling approach, each DSL/DIL is developed in the form of UML profile and is composed of abstract syntax, semantics, and concrete syntaxes.

DSL Design
Standing on the basis of the DSM and the metamodeling approach, this session uses the idea of a family of inter-related, but individually specialized, modeling languages, namely DSL. Each narrowly focused DSL can be very effective at describing the VE models in each modeling domain. Therefore, we intend to freely develop the most suitable language and to use it correctly and effectively for the business domain of the VE. As each EA cell has its own DSL, it is natural that DSLs have to be suitable to the contexts of each EA cell and to be inter-related with each other. It has been stated that UML extension mechanism of UML profile is very useful to defining a suite of modeling languages. Thus, DSLs are developed in the form of UML profiles, which is MOF-compliant at M2 layer in Figure 3. To explain the DSL design more easily, the M2 layer of Figure 3 is scaled up in Figure 8, which illustrates some fragments of the example DSL. It shows three EA cells, which are produced by the pairs of logical layer and process domain/information domain/application domain. Based on the characteristics of each EA cell, each DSL is defined with abstract syntax, semantics, and concrete syntaxes.

Figure 7 illustrates the implemented EA designer for this EA design phase. As previously described, EA designer generates 2D-matrix EA in which each EA cell provides a container of the content lists, the DSL/DIL, the reference models and the enterprise models of VE.

DSL/DIL Design Phase

In this phase, the modeling languages are developed to describe the VE models. The modeling languages, which are domain specific language (DSL) or domain integrated language (DIL) in this chapter, are designed based on the synthesized architecture in Figure 3. As this chapter, as well as MDA, assumes that PSM can be generated from PIM through the model transformation, we focus on the VE modeling at the business logic level. Therefore, we concentrate on designing

75

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Figure 8. Fragments of DSL and DIL

Modeling Domains

Enterprise Architecture

Information (Data)
Abstract Syntax Composite Entity Entity Component Abstract Syntax

Process (Function)

Application (Service)
Abstract Syntax Service Collaboration

Business Process Collaboration

Business Process Role Entity Data Entity manipulate Entity Role Composite Task Composite Usage Business Process Component offer use Service Component Service Interface Service Role

Perspective Layers

Junction

Activity Composite Service Simple Service

Service Port

System Logical ( PIM )

Split Concrete Syntax for DSL ? Entity ?

? Composit e Ent it y ?

Join

Concrete Syntax for DSL Com posite Task A N D A N D

Concrete Syntax for DSL Com posite Service

Activity

Sim ple Service

Domain Specific Language (DSL)

Concrete Syntax for DIL

Domain Specific Language (DSL)

Concrete Syntax for DIL Com posite Task A N D O R

Domain Specific Language (DSL)

Concrete Syntax for DIL Sim ple Service Com posite Service

Com posite Entity

Activity X O R

ABC

Entity

Domain Integrated Language (DIL)

DIL Design
DSLs are isolated from each other so that each DSL is expressible enough to design the models of corresponding EA cells. However, there is also a need for a coherent modeling language that provides the ability to design and integrate the inter-related models and their relationships across several EA cells. This coherent modeling language can provide insights and enable communication among different stakeholders. As integrating DSLs, DIL are to bridge the gaps between these modeling domains and to integrate the models of the heterogeneous modeling domains. While DSLs are used to design the models that are restricted within each EA cell, DIL is used to design the integrated models that support multiple EA cells throughout CIM

and PIM modeling. Therefore, DSLs provide the easiest and most correct way to establish specific domain models that correspond to requirements of various stakeholders. In addition, the usage of DILs enables different stakeholders to readily understand the enterprise model as a whole. To support it, like the links expressed as dotted bold lines in Figure 8, the related modeling elements among DSLs of different EA cells can be connected. MOF-compliant UML profile of the MDA provides the base to manage different DSLs in an integrated fashion and to knit these isolated DSLs together. DIL is not completely independent of DSL because DIL is a type of meta-model (UML profile) assembling several DSLs. Therefore, the model based on a DSL and the model based on a DIL can be interchanged with and converted to each other easily.

76

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Figure 9. DSL designer

The facility, which supports the DSL/DIL design phase is implemented in the previously mentioned EA designer. Figure 9 shows DSL designer of the implemented DSL/DIL designers. The designed elements of DSL such as abstract syntax, concrete syntax, and semantics are packed in the EA cell.

CIM/PIM Modeling Phase

The business components including the business processes of the VE are modeled at the M1 layer using the EA and the DSL/DIL for CIM/PIM. The modeling process for the VE proceeds on each perspective of the EA. This process is based on a top-down modeling paradigm in which more concrete models are created from abstract models. Therefore, the business list, the business purpose, the vision, and the boundaries of the VE are described at the contextual layer, and the value chains of the VE are modeled as CIM at the conceptual layer. Then, the detailed business

components composing CIM are modeled as PIM at the Logical layer. As the VE is considered as a set of the value chains made up of collaborative business processes, it is natural that the VE can be modeled with the process-centric approach. A generalized and process-centric representation for business partners was presented and implemented in our previous research (Kim, Son, Kim, Kim, & Baik, 2005; Kim, Kim, Lee, & Kim, 2005). As this CIM/PIM modeling phase is based on the modeling philosophy of our previous research, CIM and PIM for the VE are regarded as the business scenarios and the collaborative business processes, respectively, as illustrated in Figure 10. In CIM modeling for the business scenarios, functional areas and organizations of each business partner are determined using the functionorganization matrix that describes the process stream and organization stream of the VE. With respect to the process stream, the units of enterprise activities are logically and temporally ordered to

77

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Figure 10. Modeling CIM and PIM

Pro cess Stream

Organization Stream

In PIM modeling for the collaborative business processes, we recommend to perform a top-down analysis primarily to show the business processes according to the business scenario. These business processes, as well as other business components and their relationships, are systematically modeled through the DSL and DIL for PIM.

CI M Modeling

Coherent Modeling
Specifically, our systematic modeling framework supports the coherent modeling using DIL in the PIM modeling phase. The usage of DILs enables developers to readily understand the VE models as a whole. DIL is used to integrate the domain models of the specific view into the entire model of the integrated view, so that each stakeholder can verify their own domain model from the entire model through view navigation. The integrated view using DIL is useful when different stakeP IM Modeling

realize products. For the organization stream, the organization, human, and technical resources are systematically and repetitively assigned.

Figure 11. Coherent modeling

I ntegrated View using DI L
Design New Product
Product Spec . Concept Drawing Prepare Product Roadmap
Product Spec. Road Map

Subsystems Layout Drawing Detailed Drawing Design Subsystems

Product Spec. Project Scheduler Senior Manager Project Engineer Concept Drawing Subsystems Layout Drawing Major Component F/A Result Engineering Design Manager System Engineer Manufacturing Engineer CAD System

Design Details
Product Spec. Concept Drawing Major Component Detailed Drawing BOM Sourcing List Cost Engineering Design Manager System Engineer Manufacturing Engineer Financing Engineer

BOM Sourcing List Cost F/A Result

A N D

Available Tech. Road Map PDM System

Investigate Technology
Product Spec. Concept Drawing Available Tech .

Technology Portal

Senior Manager Project Engineer

Header Id 1 Name Usage Description Note alternate A N D A N D 1 0..N 1

CompositeEntity

Prepare Product Roadmap

refer

Item

PDM Service Manager

Design Subsystems

Design Details

PDM Service

Option 0..N

0..N ItemData 1 0..N 0..N

Investigate Technology

Authoring Service

Id Name Description Note 0..N 1

BOM 1 1 0..N OptionClass 1 Id Description Name Note

refer

P rocess View using DSL Application View using DSL

refer

I nformation View using DSL

78

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

holders design an integrated model and evaluate the relationships among the individual domain models and integrated models. An example of the coherent modeling is represented in Figure 11. The facility, which supports the CIM/PIM modeling phase is also implemented in the previously mentioned EA designer. Figure 12 shows the implemented CIM/PIM modelers. The implemented CIM/PIM modelers also provides the coherent modeling functionality in order to design and integrate the inter-related models and their relationships across several EA cells. The designed VE models such as CIM and PIM are packed in the EA cell.

Deployment Phase
In this deployment phase, the designed VE models are deployed into PSM for actual execution so as to be suitable for specific technology platform. In order to deploy the designed VE models into PSMs, the model transformation through Figure 12. CIM/PIM modelers

meta-model mapping can be introduced. It is obvious that business domain experts can not define DSL/DIL, which provides the executable ability in the DSL/DIL design phase. Thus, it is better to transform the VE models to the execution models through the model transformation. As briefly shown in Figure 13, a meta-model of PSM, that is Web service language, is developed as a UML profile. And then, it is mapped from the DSL/DIL. Such meta-model mapping at the M2 layer enables to transform the CIM/PIM into PSM, namely Web service models. In this chapter, Web service is considered to be the best solution for PSM. Web service is a way to implement the SOA, which is intended to enable developers to create the service components that can be assembled and deployed in a distributed environment. Therefore, Web service is a useful candidate for integrating the enterprise application and setting up the open and loosely coupled information platform for the VE.

79

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Figure 13. Model transformation for deployment

l de Mo

aet LM UM

U M L P r ofile for C IM

UML Meta-Model DSL DSL ( Meta-Model )

DIL (UML Profile) for CIM DSL DSL DSL DSL DIL for PIM

U M L P r ofile for P IM

DSL

DSL

DSL

M2 Layer

DSL L DS L DI

DI

L DS CIM or Lf

Meta-Model of PSM (UML Profile for Web Service)

Com putation I ndependent M odel P latform I ndependent M odel

CI PI M

DIL (UML Profile) for CIM PIM

M1 Layer ( Model )

Platform Specific Model (Web Service Model)

PS

eL tiv ec rs p Pe

e rs ay

Contextual

Conceptual

Logical

Physical

n y i on s ion t io at log es at ca oc niz no rm pli Pr ga ch fo Ap Or Te In

Enterprise Architecture
M eta-m odel M apping (M odel Transform atio n)

Modeling Domains

Figure 14. Deployment of VE models

Meta-model of PIM (UML Profile for PIM)
Composite Entity Entity Component Business Process Collaboration Service Collaboration

Meta-model of Web Service (UML Profile for Web Service)

Input Variable Output Variable

Entity Data

Entity

Business Process Role Business Process Component offer use

Service Role

Partner

Process

Variable

M2 Layer (Meta-Model)

manipulate Entity Role

Service Component

Service Interface

M eta-m odel M apping

Partner Link Activity Message

Composite Task

Composite Usage

Service Port Role

Junction

Activity

Operation

Split

Join

Composite Service

Simple Service

Invoke

Receive

Reply

Port Type

PIM : N ew P roduct Design P rocess of R & D Team

Design New Product
Product Spec . Concept Drawing Prepare Product Roadmap
Product Spec. Road Map

PSM (BPEL4WS) : N ew P roduct Design P rocess of R &D Team

Subsystems

<process name="DesignNewProduct_Process" Detailed Drawing targetNamespace="http://ooo.ooo.ooo/dp" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" BOM Design Design xmlns:msg="http://ooo.ooo.ooo/dp/msg" Subsystems Details Sourcing List xmlns:sc="http://ooo.ooo.ooo/dp/sc"> Product Spec. Subsystems Detailed Drawing Product Spec.
Concept Drawing Layout Drawing Concept Drawing BOM

Layout Drawing

Project Scheduler

Senior Manager Project Engineer

Cost

A N D

Available Tech. Road Map PDM System

Investigate Technology
Product Spec. Concept Drawing Available Tech.

<partnerLinks> Major Component Sourcing List Major Component F/A Result F/A name="DesignNewProduct _Service" partnerLinkType="sc:DesignNewProduct_PLT" myRole="DesignNewProduct_Role"> Cost <partnerLink Result <partnerLink name="ProjectScheduler_Service" partnerLinkType="sc:ProjectScheduler_PLT" partnerRole="PrepareProductRoadmap_Role"> Engineering Engineering CAD Design Design <partnerLink name="TechnologyPotal _Service" partnerLinkType="sc:TechnologyPotal_PLT" partnerRole="InvestigateTechnology_Role"> System Manager Manager <partnerLink name="PDM_Service" partnerLinkType="sc:PDM_PLT" partnerRole="DesignSubsystem_Role"> System System Engineer Engineer <partnerLink name="CAD_Service" partnerLinkType="sc:CAD_PLT" partnerRole="DesignDetails_Role"> Manufacturing Manufacturing </partnerLinks> Engineer Engineer
Financing

Technology Portal

Senior Manager Project Engineer

M1 Layer (Model)

Engineer <variables> <variable name="ProductSpec" messageType ="msg:ProductSpec"/> <variable name="ConceptDrawing" messageType="msg:ConceptDrawing"/> <variable name="RoadMap" messageType="msg:RoadMap"/> <variable name="AvailableTech" messageType="msg:AvailableTech"/> <variable name="Subsystems" messageType="msg:Subsystems"/> <variable name="LayoutDrawing" messageType ="msg:LayoutDrawing"/> R&D <variable name="MajorComponent" messageType ="msg:MajorComponent"/> Team <variable name="F/AResult" messageType ="msg:F/AResult"/> <variable name="DetailedDrawing" messageType="msg: DetailedDrawing"/> <variable name="BOM" messageType="msg:BOM"/> <variable name="SourceList" messageType ="msg:SourceList"/> <variable name="Cost" messageType ="msg:Cost"/> <variables>

<sequence> <receive name="DesignNewProduct " partnerlink="DesignNewProduct _Service" portType="DesignNewProduct_PT" operation="Do_DesignNewProduct" variable="ProductSpec" variable="ConceptDrawing"/> <flow> <invoke name="PrepareProductRoadmap" partnerlink="ProjectScheduler_Service" portType="sc:ProjectScheduler_PT" operation="Do_PrepareProductRoadmap" inputVariable="ProductSpec" outputVariable="RoadMap"> <invoke name="InvestigateTechnology" partnerlink="TechnologyPotal_Service" portType="sc:TechnologyPotal_PT" operation="Do_InvestigateTechnology" inputVariable="ProductSpec" inputVariable="ConceptDrawing" outputVariable="AvailableTech"> </flow> <invoke name="DesignSubsystems" partnerlink="PDM_Service" portType="sc:PDM_PT" operation="Do_DesignSubsystems" inputVariable="ProductSpec" inputVariable="ConceptDrawing" inputVariable="AvailableTech" inputVariable="RoadMap" ouputVariable="Subsystems" ouputVariable="LayoutDrawing" ouputVariable="MajorComponent" ouputVariable="F/AResult"> <invoke name="DesignDetails" partnerlink="CAD_Service" portType="sc:CAD_PT" operation="Do_DesignDetails" inputVariable="ProductSpec" inputVariable="ConceptDrawing" inputVariable="MajorComponent" ouputVariable="DetailedDrawing" ouputVariable="BOM" ouputVariable="SourceList" ouputVariable="Cost"> <reply name="DesignNewProduct " partnerlink="DesignNewProduct_Service" portType="DesignNewProduct-PT" operation="Do_DesignNewProduct " variable="Subsystems" variable="LayoutDrawing" variable="DetailedDrawing" variable="BOM" variable="SourcingList" variable="Cost" variable="F/AResult"/> </sequence> </process>

80

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

As represented diagrammatically in Figure 14, PIM, which are modeled in Figure 11, can be transformed into BPEL4WS model via the meta-model mapping between DSL/DIL into the meta-model of BPEL4WS. And the generated BPEL4WS model is expected to be possibly executed through the existing commercial Web server systems, such as WebSphere or WebLogic.

DIscUssION AND cONcLUsION

The VE based on the process-centric loosely coupled integration has become a key for survival in the competitive business environment. In order to establish this VE models quickly and systematically, it is necessary to develop a systematic modeling framework for supporting the entire VE modeling such as VE architectures, the modeling languages, VE models, and deployment. Unfortunately, existing technologies in enterprise engineering doesnt fully support the design and management of the VE. Although they have their own advantages, the review of current technologies reveals that none support all aspects of the VE model because each technology deals with diverse domains in different ways and has been developed independently to address its own purpose. This observation has motivated the development of a systematic modeling framework for the agile and interoperable VE based on a hybrid approach. It harmonizes the up-to-date approaches in order to not only utilize the individual advantages of each approach, but also to produce integrated synergy effects. In this chapter, we aim to suggest a systematic modeling framework itself, not to propose an EA, modeling languages, or VE model instances. Based on our modeling framework, business domain experts and developers of VE can design their own EA, DSLs/DILs, and deployed models, as well as VE models. In order to establish the systematic modeling framework, we propose the

synthesized architecture, which combines all relevant technologies. Based on the synthesized architecture, we also propose the procedural framework, which guides the enterprise configuration to support the entire VE. The proposed systematic modeling framework could be used by business domain experts and developers to build an agile and interoperable VE quickly and systematically by composing business partners and by designing the collaborative business processes and the business components across the value chains of the VE. For communications among the different stakeholders, it also supports the coherent enterprise modeling in which various stakeholders, having their own aspects and methodology, such as an IT manager and a business manager, can communicate effectively. Consequently, this systematic modeling framework could contribute significantly to the configuration of agile and interoperable VEs. Although the modeling framework is developed in this chapter, works are currently underway to enrich it as yet. The in-depth meta-models for specific business domains have not been covered in this chapter because they are too complicated to be described in detail. Through gathering industrial data and cases, the meta-models, which are applicable to real industrial example, should be constructed and proved by experiments. We have implemented a modeling system supporting the proposed modeling framework. Nevertheless, because there is much room for improvement as ever, we are under discussion on better and more robust system implementations.

rEFErENcEs
Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., et al. (2003). Business process execution language for web services version 1.1. Retrieved from http://www-106.ibm.com/ developerworks/Webservices/library/ws-bpel/

81

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Ang, C. L., Khoo, L. P., & Gay, R. K. L. (1999). IDEF*: A comprehensive modeling methodology for development of manufacturing enterprise system. International Journal of Production Research, 37(17), 3839-3858. Arkin, A. (2002). Business process modeling language. Retrieved from http://www.bpmi. org/downloads/BPML1.0.zip Barnett, W., Presley, M. J., & Liles, D. (1994). An architecture for the virtual enterprise. Paper presented at the IEEE International Conference on Systems, Man, and Cybernetics, San Antonio. Berners-Lee, T. (1998). Semantic Web road map. Retrieved from http://w3.org/DisignIssues/Semantic.html Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language user guide. Addison-Wesley. Business Process Management Initiative. (2003). Business process modeling natation working draft 1.0. Retrieved from http://www.bpmi.org/downloads/BPMN-V1.0.pdf Cadence Design Systems. (2003). Design chain optimization: Competing in the disaggregated electronic industry. Cadence Design Systems, Whitepaper. Camarinha-Matos, L. M., & Afsarmanesh, H. (2003). Elements of a base VE infrastructure. Computers in Industry, 51, 139-163 CIO Council. (2001). A practical guide to federal enterprise architecture version 1.0. Retrieved from http://www.cio.gov CSC. (2002). The emergence of business process management version 1.0. A Report by CSCs Research Services Czarnecki, K., & Helsen, S. (2003). Classification of model transformation approaches. Paper presented at the OOPSLA03 Workshop on

Generative Techniques in the Context of ModelDriven Architecture. Retrieved from http://www. softmetaware.com/oopsla2003/mda-workshop. html DoDAF Working Group. (2003). DoD architecture framework version 1.0: Volume I: Definition and guidelines. de Falbo, R. A., de Menezes, C. S., & da Rocha, A. R. C. (1998). A systematic approach for building ontologies. IBERAMIA98, LNAI 1484. Fox, M. S., & Gruninger, M. (1998). Enterprise modeling. AI Magazine, American Association for Artificial Intelligence Press. Frankel, D. S., et al. (2003). The Zachman framework and the OMGs model driven architecture. Business process Trends: Whitepaper. Frankel, D. S. (2004). Domain-specific modeling and model driven architecture. Business Process Trends: MDA Journal. Gerber, A., Lawley, M., Raymond, K., Steel, J., & Wood, A. (2002). Transformation: The missing link of MDA. In Proceedings of International Conference on Graph Transformation (ICGT), Barcelona, Spain. Gou, H., Huang, B., Liu, W., & Li, X. (2003). A framework for virtual enterprise operation management. Computers in Industry, 50, 333-352 Harmon, P. (2003a). Second generation business process methodologies. Business Process Trends: Newsletter, 1(5). Harmon, P. (2003b). Developing an enterprise architecture. Business process Trends: Whitepaper. IFIP-IFAC Task Force. (1999). GERAM: Generalised enterprise reference architecture and methodology version 1.6.3. Retrieved from http:// www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/GERAMv1.6.3.pdf

82

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

The Instrumentation, Systems, and Automation Society. (2004). Enterprise-control system integrationPart 3: Models of manufacturing operations management, ISA Draft 95.00.03. Jagdev, H. S., & Thoben, K. D. (2001). Anatomy of enterprise collaborations. Production Planning & Control, 12(5), 437-451 Kim, C. H., Son, Y. J., Kim, T. Y., Kim, K., & Baik, K. (2005). A modeling approach for designing a value chain of virtual enterprise. International Journal of Advanced Manufacturing Technology. Online first retrieved http://dx.doi.org/10.1007/ s00170-004-2445-4 Kim, T. Y., Kim, C. H., Lee, J. S., & Kim, K. (2005). Enterprise architecture framework based on MDA to support virtual enterprise modeling. In Proceedings of the 9th International IEEE EDOC Workshop on VORTE (Vocabularies, Ontologies, and Rules for The Enterprise), Enschede, Netherlands. MetaCase. (2005). Domain-specific modelling, application development advisor. Retrieved from http://www.appdevadvisor.co.uk/express/vendor/ domain.html Miller, J., & Mukerji, J. (2003). MDA guide version 1.0.1. Retrieved from http://www.omg. org/docs/omg/03-06-01.pdf NIIIP. Retrieved from http://www.niiip.org Object Management Group. (2002). Model driven architecture (MDA). Retrieved from http://www. omg.org/mda/ Object Management Group. (2003a). Request for proposal: business process definition metamodel RFP. Retrieved from http://www.omg.org/docs/ bei/03-01-06.pdf Object Management Group. (2003b). UML 2.0 infrastructure specification: Final adopted specification. Retrieved from http://www.omg. org/docs/ptc/03-09-15.pdf

Object Management Group. (2003c). UML 2.0 superstructure specification: Final adopted specification. Retrieved from http://www.omg. org/docs/ptc/03-08-02.pdf Object Management Group. (2004). UML profile for enterprise collaboration architecture specification version 1.0. Retrieved from http://www. omg.org/docs/formal/04-02-05.pdf Prakash, N., Srivastava, S., & Sabharwal, S. (2006). The classification framework for model transformation. Journal of Computer Science, 2(2), 166-170. Supply Chain Council. (2003). Supply chain operations reference modelSCOR version 6.0. Supply Chain Council, Inc. Sendall, S., & Kozaczynski, W. (2003). Model transformation: The heart and soul of model-driven software development. IEEE Software, Special Issue on Model Driven Software Development, Sep./Oct. Smith, H., & Fingar, P. (2003). Business process management: The third wave. Meghan-Kiffer Press. TeleManagement Forum. (2002). Enhanced telecom operations MapTM (eTOM): The business process framework version 3.0, GB921. Uschold, M., King, M., Moralee, S., & Zorgios, Y. (1997). The enterprise ontology. Knowledge Engineering Review, 13. Vernadat, F. B. (1993). CIMOSA: Enterprise modeling and enterprise integration using a process-based approach. Paper presented at the Workshop on the Design of Information Infrastructure Systems for Manufacturing, The Japan Society for Precision Engineering. Vernadat, F. B. (1996). Enterprise modeling and integration: Principles and applications. Chapman and Hall.

83

Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

Vesterager, J., Tolle, M., & Bernus, P. (2002). VERA: Virtual enterprise reference architecture. Paper presented at the Blobeman Plenary Conference, Helsinki. W3C. (2001). Web services description language (WSDL) 1.1, W3C Notes. Retrieved from http:// www.w3.org/TR/wsdl/ W3C. (2004). OWL Web ontology language guide, W3C Recommendation. Retrieved from http://www.w3.org/TR/owl-guide/ Williams, T. J. (1993). The Perdue enterprise reference architecture. Paper presented at

the Workshop on the Design of Information Infrastructure Systems for Manufacturing, The Japan Society for Precision Engineering. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3). Zarli, A., & Richaud, O. (1999). Requirements and technology integration for IT-based businessoriented frameworks in building and construction. Electronic Journal of Information Technology in Construction, 4. ZIFA. Retrieved from http://www.zifa.com

84

85

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Steven J. Ring The MITRE Corporation, USA Dave Nicholson The MITRE Corporation, USA

Chapter V

AbstrAct
This chapter describes the activity-based methodology (ABM), an efficient and effective approach toward development and analysis of DoD integrated architectures that will enable them to align with and fully support decision-making processes and mission outcomes. ABM consists of a tool-independent disciplined approach to developing fully integrated, unambiguous, and consistent DODAF Operational, System, and Technical views in supporting both as-is architectures (where all current elements are known) and to-be architectures (where not all future elements are known). ABM enables architects to concentrate on the Art and Science of architecturesthat is identifying core architecture elements, their views, how they are related together, and the resulting analysis used for decision-making purposes. ABM delivers significant architecture development productivity and quality gains by generating several DoDAF products and their elements from the core architecture elements. ABM facilitates the transition from integrated static architectures to executable dynamic process models for time-dependent assessments of complex operations and resource usage. Workflow steps for creating integrated architecture are detailed. Numerous architecture analysis strategies are presented that show the value of integrated architectures to decision makers and mission outcomes.

IntroductIon
This document provides guidance in developing fully integrated, unambiguous, and consistent DoD architecture framework (DoDAF) and ar-

chitecture descriptions in supporting both as-is domains (where all current elements are known) and to-be domains (where not all future elements are known). It presents a disciplined approach in identifying core architecture data elements, their

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

views, how they are related together, and how they compare with other architectures developed according to this guidance. The resulting analysis based on common, integrated architecture data can then be used for decision-making purposes. The associations between these core elements form the basis of an integrated architecture data model. Using these core architecture data elements and their associations, significant architecture development productivity and quality gains can be obtained by providing a standard means for comparing and relating architecture descriptions. Workflow steps in creating an integrated architecture are detailed. Architectures are a means to an end and not an end to themselves. They need to be aligned with and support the decision-making process and ultimately mission outcomes and objectives. Figure 1 depicts this process where mission outcomes are determined by mission decisions, chosen from among a set of courses of actions, based on analysis and assessments of architecture

data, coming from both integrated and executable architectures. Having a disciplined process that ensures quality architectures raises the potential for quality and consistency in their descriptions and minimizes discrepancies. Consequently, the analytics will produce quality results, not be prone to misinterpretations, and thus, be of high value to decision makers and mission outcomes.

bAckground
The DoD architecture framework (DoDAF) provides DoD commands, services, and agencies with the rules and guidance for describing architectures for both warfighting operations and business processes (DoDAF, 2003). DoDAFs purpose is to ensure that the architecture descriptions contain related architecture entities and relationships that can be used (1) for understanding, comparing, and integrating families of systems (FOSs) and systems of systems (SoSs) and (2) to enable in-

Figure 1. Role of architectures in the decision-making and mission outcome processes

86

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

teroperating and interacting architectures within and across organizational boundaries, including joint and multi-national. DoDAF is not an architecture by itself. DoDAF is an architecture framework that provides structured guidance and rules for classifying and organizing architectures within an enterprise. It represents approaches, standards, concepts, descriptions, views, visualizations, products, and architecture artifacts in a single framework. An architecture is a representation of a defined domain as of a current or future point in time. The term is generally used both to refer to an architecture description and an architecture implementation. In this document, the term architecture will be used as a shortened reference to architecture description. An architecture description, then, is a representation of a defined domain as of a current or future point in time, in terms of its component parts, what those parts do, how the parts relate to each other, and the rules and constraints under which the parts function. What constitutes domains and components depends on the degree of detail of interest. For example, domains can be at any level, from DoD as a whole down to individual functional areas

Figure 2. Architecture framework hierarchy

or groups of functional areas. Component parts can be anything from U.S. Air Force as a component of DoD, down to a satellite ground station as a component part of a communications network, or a UAV operator as a component part of a reconnaissance system. What those parts do can be as general as their high-level operational concept or as specific as the lowest-level action they perform. How the parts relate to each other can be as general as how organizations fit into a very high-level command structure or as specific as what frequency one unit uses in communicating with another. The rules and constraints under which they work can be as general as high-level doctrine or as specific as the e-mail standard they must use. An architecture description can represent requirements without a specific implementation or it can represent both requirements and their implementation. An architecture description consists of integrated architecture perspectives (or views). Architecture descriptions and views help communicate domain complexity and aid in its understanding. Architecture perspectives are logical perspectives used to separate components into unique viewpoints or frames of reference. Each architecture view, by itself, consists of one or more related real-world models (or products) of processes, resources, rules, and relationships for a specific viewpoint. These products are graphical, textual, or tabular related representations of architecture artifacts (elements). At the lowest level, architecture artifacts are instances of activities, nodes, organizational elements, organizations, systems, networks, interfaces, etc.

dod ArchItecture FrAmework

DoDAF defines four perspectives (i.e., three of the four views are shown in Figure 3) that logically combine to form an architecture description: Operational View (OV), System View (SV), and Technical Standards View (TSV). OV is a de-

87

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

scription of an enterprises operational elements required to accomplish DoD missions. SV is a refinement of the OV that describes system elements, their functions and interfaces, and their exchanges supporting operational missions. TSV is the set of standards to be applied to the elements and their relationships in the OV and SV. A fourth view, All-Views (AV), relates overarching aspects of OV, SV, and TSV. AV products provide information pertinent to the entire architecture but do not represent a distinct view of the architecture. AV products set the scope and context of the architecture to include (i) subject area and timeframe for the architecture, (ii) setting in which the architecture exists, (iii) interrelated conditions such as doctrine, tactics, techniques, and procedures that compose the context for the

architecture, (iv) relevant goals and vision statements, (v) concepts of operations, scenarios, and environmental conditions. Each view is composed of sets of architecture elements that are depicted via a baseline set of 26 graphic, tabular, and textual architecture products. It is important to distinguish between an architecture view and an architecture product. As stated earlier, an architecture view represents a given perspective of an architecture, while an architecture product is a specific representation of a particular aspect of that perspective. At the lowest level, these architecture artifacts are data instances of activities, nodes, organizational elements, organizations, systems, networks, interfaces, etc.

Figure 3. Linkages among OV, SV, and TSV Views

operational view
W W ha In ho t N fo D e Re r qu ma oe eds S ire tio s It to th ys d nE Be In e A tem to x fo c s Do G ch rm tiv th et a ne at itie at ng It io s S Do es n a u Ex nd pp ne or ch t an ge s

Identifies what needs to be Accomplished and who does It

t ts en m m r re ui e eq y y ll R es o og ie o ol na illit h hn y iio b at pa ec llit l ra ap Te bii iica pe d C rta hn O d sic por ch s an Ba upp Te iitie Su ew abil b N p N p Ca

systems view
relates systems and characteristics to operational needs

Specific System Capabilities Required to Satisfy Information Exchanges

technical standards view

Prescribes standards and conventions

Technical Standards Criteria Governing Interoperable Implementation/Procurement of the Selected System Capabilities

Table 1. All views and technical architecture view products

Product AV-1 AV-2 TV-1 TV-2 Product Name Overview and Summary Information Integrated Dictionary Technical Standards Profile Technical Standards Forecast General Description Scope, purpose, intended users, environment depicted, analytical findings Architecture data repository with definitions of all terms used in all products Listing of standards that apply to Systems View elements in a given architecture Description of emerging standards and potential impact on current Systems View elements, within a set of time frames

88

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Table 2. Operational View products

Product OV-1 OV-2 OV-3 OV-4 OV-5 OV-6a OV-6b OV-6c OV-7 Product Name High-Level Operational Concept Graphic Operational Node Connectivity Description Operational Information Exchange Matrix Organizational Relationships Chart Operational Activity Model Operational Rules Model Operational State Transition Description Operational Event-Trace Description Logical Data Model General Description High-level graphical/textual description of operational concept Operational nodes, connectivity, and information exchange need lines between nodes Information exchanged between nodes and the relevant attributes of that exchange Organizational, role, or other relationships among organizations Capabilities, operational activities, relationships among activities, inputs, and outputs; overlays can show cost, performing nodes, or other pertinent information One of three products used to describe operational activityidentifies business rules that constrain operation One of three products used to describe operational activityidentifies business process responses to events One of three products used to describe operational activitytraces actions in a scenario or sequence of events Documentation of the system data requirements and structural business process rules of the operational view

Table 3. System View products

Product SV-1 SV-2 SV-3 SV-4 SV-5 SV-6 SV-7 SV-8 SV-9 SV-10a Product Name Systems Interface Description Systems Communications Description Systems-Systems Matrix Systems Functionality Description Operational Activity to Systems Function Traceability Matrix Systems Data Exchange Matrix Systems Performance Parameters Matrix Systems Evolution Description Systems Technology Forecast Systems Rules Model General Description Identification of systems nodes, systems, and system items and their interconnections, within and between nodes Systems nodes, systems, and system items, and their related communications laydowns Relationships among systems in a given architecture; can be designed to show relationships of interest (e.g., system-type interfaces, planned vs. existing interfaces, etc). Functions performed by systems and the system data flows among system functions Mapping of systems back to capabilities or of system functions back to operational activities Provides details of system data elements being exchanged between systems and the attributes of that exchange Performance characteristics of systems view elements for the appropriate time frame(s) Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture One of three products used to describe system functionalityidentifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation One of three products used to describe system functionalityidentifies responses of a system to events One of three products used to describe system functionalityidentifies systemspecific refinements of critical sequences of events described in the operational view Physical implementation of the logical data model entities (e.g., message formats, file structures, physical schema)

SV-10b SV-10c SV-11

Systems State Transition Description Systems Event-Trace Description Physical Schema

89

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

current stAte oF dod ArchItectIng

As we near the end of the first generation of DoD architecting, differing interpretations and definitions of DoDAF concepts within the architecture community combined with variations in architecture development workflow processes, practices, and results have, in almost all cases, led to architectures that cannot be federated, compared, analyzed, or assessed (Nicholson, Mercer, & Ang, 2005). While there are pockets of good architecture practice, too often applying DoDAF in any consistent and repeatable way is improbable and difficult. Architects are unsure of how to apply DoDAF and wind up practicing check the box architecting just to get to the next program/project development stage. Although DoD architects have produced thousands of architecture descriptions, they generally have not produced actionable decision information in support of core organizational processes, yet, the purpose of DoD architecting has always been to support the development of such actionable information. These core organizational processes include joint capabilities integration and development system (JCIDS, 2005) process, information technology portfolio management (ITPM) (DoDI 8115.bb, 2006) process of managing investments as portfolios, and a capabilities-based planning process that provides useful architecture descriptions expressed as the full range of military Doctrine, Organization, Material, Training, Leadership, Personnel and Facilities (DOTMLPF) alternatives. The ability to develop integrated architectures that produce actionable information to support these core processes results in the need for a conceptual architecture model that meets the following requirements: Provides a data-centric (not product-centric) approach to integrated architecting.

Is unambiguous and semantically rich: eliminate semantic overloading of architecture data elements. Identifies a set of core architecture elements. Ensures DoDAF architectures do not become dis-integrated. Supports executable architecture development and analysis. Enables linking (federating) producing and consuming architectures. Captures sufficient architectural detail for full DOTMLPF analysis (not just material).

Provides a data-centric (not Product-centric) Approach to Integrated Architecting

The current emphasis on discrete DoDAF product development obscures the real purpose in describing architecturesi.e., producing actionable architectures that can be used for decision and mission outcome objectives. The lack of a single holistic model of architecture concepts as the underlying foundation of the 26 DoDAF products characterizes DoDAF as product-centric rather than data-centric. A more appropriate approach begins with the descriptive concepts employed in DoD architecting that leads to a holistic collection of the descriptive concepts, in the form of data types, as the foundation of architecture descriptions. This is the basis of the data-centric ABM approach to architecture development.

Is unambiguous and semantically rich: eliminate semantic overloading of Architecture data elements
Semantic overloading is where one descriptive element conveys more than one semantic concept. This results in definitions of architecture elements

90

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

being subject-to-differing-interpretations by architects and creates ambiguity that may or may not be resolved through examination, on an individual basis, of the context in which the element is used. It is primarily DoDAFs inconsistent expression of semantics that characterizes it as semantically incomplete. Most notably, an Operational Node is defined (and has been since the original 1997 C4ISR Framework (C4ISR AF, 1997, pp. 4-11)) to be an element that represents Organizations, Organization Types, and Occupational Specialties (DoDAF, Vol II, pp. 3-10), while at the same time is defined to be an element that produces, consumes, or processes information (DoDAF, Vol II, pp. 4-7). Operational nodes have also been increasingly interpreted as platforms (ground, air, and sea), facilities, and systems in many OV architectures. Thus, what constitutes an operational node can vary among architectures, including, but not limited to, an operational/human role, an organization, organization type, and so on. Another example is the semantic overloading of the Operational View (OV). Current OV describes both (1) a human performer-only view and (2) an undifferentiated logical view that treats performers as neither human nor machine, but instead as resources composed of both. Again, only by examining the context of each OV can one resolve the intention of the architecture. To eliminate any ambiguity and semantic overloading, an architecture taxonomy, at the highest level, must be based on the six interrogativeswhO, where, whAT, why, wheN, and hOw. This eliminates the case where whO and where are combined into a single element (Operational Node).

set of architecture elements and their respective framework products that are the sources of those elements, integrated architectures may not always be produced. For example, while an OV-3 is part of the integrated product set, some architectures that only consist of an OV-3 are declared to be integrated without one ever producing an OV-2 or OV-5. A set of four core architecture elements from the six interrogativesnodes (where), resources (whO), products (whAT), functions (hOw) serve as the foundation of an integrated architecture.

Ensures DODAF Architectures do not become Dis-Integrated

Because there is no identification of core integrated architecture data elements, there is no consistent workflow process ordering of framework product development. In a recent DoD enterprise architecture survey (Ring & Johnson, 2005), not having a consistent workflow process was highlighted as a major concern. It is precisely because one can start anywhere, that DoDAF architectures can become dis-integrated and inconsistent over time. For example, one could start with an OV-3, jump to the OV-2, and then develop an OV-5. However, because an OV-3 is made up of activities and nodes coming from an OV-2 and OV-5, one could define activities and nodes in an OV-3 that never appear in OV-2 and OV-5. Conversely, one could create activities and nodes on OV-2 and OV-5 that are never entered in an OV-3. This results in an architecture that is dis-integrated, out of sync, and not useful for any purpose. If the OV-2, 3, 5 are independently developed, then one must continuously manually ensure that they are always in sync and consistent to ensure an integrated architecture. A workflow procedure, associated with the capture of four core architecture elements, can be established to provide a consistent, repeatable, ordering of framework product development. A major benefit from defining a set of four core elements and this

Identifies a Set of Core Architecture Elements

While DoDAF defines a set of products that make up an integrated architecture, it doesnt identify any architecture elements within those products as being core building block foundations of integrated architecture. Without defining any specific core

91

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

standard workflow procedure is that two exchange products, OV-3 and SV-6, can automatically be generated from their constituent core elements as defined in their respective framework products (OV-2, OV-5, SV-1, and SV-4). This eliminates any manual synchronization by architects and improves and accelerates the entire development process.

Captures Sufficient Architectural detail for Full dotmLPF Analysis

DoDAF does not capture sufficient architectural detail needed for full DOTMLPF analysis. For example, in the framework products identified as making up an integrated architecture, OV-4 is missing. OV-4 is fundamental to providing architecture detail for organizations and people which are the (O)rganization and (P)ersonnel of DOTMLPF. In addition, there is no current way to define (T)raining and (L)eadership aspects. This can be accomplished by basing an architectural taxonomy on the six interrogatives which, in turn, can then be mapped to full range of DOTMLPF.

supports executable Architecture development and Analysis

A majority of the current 26 DoDAF products capture only static information for their Operational and System views. Several products (OV-6 and SV-10) provide for dynamic views of operations. However, these products do not adequately address how to capture time dependencies and organizational resource (human and system) responsibilities. These dependencies and resource allocations are needed to analyze and assess operational and system dynamic behavior of how organizations and resources interact with each over time as part of DOTMLPF analysis. DoDAF architectures need to be able to capture sufficient details that will enable them to be transitioned and transformed from static to dynamic architectures.

summary of current state

We must evolve and mature DoD architecting to address these issues and to meet new requirements and demands on future integrated architecture usage such as: JCIDS, capabilities-based planning processes with useful integrated architecture descriptions expressed in the full range of DOTMLPF architecture alternatives; systems acquisition and portfolio planning/ investment processes based on integrated architectures with an unambiguous way to compare architecture alternatives; and linking integrated architectures with enterprise systems engineering processes by providing information to support requirements development and analysis. What is needed, then, is a small yet powerful set of DoD architecture description principles and concepts, as provided by ABM, that provides a semantically shared vocabulary for the DoD architecting community. Descriptive concepts can, in turn, serve as a formal foundation for development of the next-generation DoD architecture framework that will support interoperability between DoD architecting practices and also architecture-based analysis in support of DoD core processes.

enables Linking (Federating) Producing and consuming Architectures

DoDAF does not provide for separate producing and consuming architectures to be linked and federated. This can be accomplished by (1) explicitly defining new external core architecture elements (i.e., NODES, FUNCTIONS, RESOURCES) that are outside the scope, external, of one producing architecture but that are inside the scope, internal, of a second consuming architecture and then (2) extending the exchange definitions (OV-3, SV-6) to include these producing and consuming external core elements.

92

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

IntegrAted ArchItectures
Before one can use architecture descriptions for any analysis, decision-making, and mission outcome purposes, one must first start with an architecture that is integrated, unambiguous, and consistent. There are two definitions of an integrated architecture. The first comes from DoDAF and is considered as a top down product perspective. The second is described by ABM here and is considered as a bottom up data perspective. For both definitions, integrated architectures facilitate integration and promote interoperability across family-of-systems and system-of-systems and compatibility among related mission area architectures. From a top down product perspective, DoDAF defines a single architecture description to be an integrated architecture when products and their constituent architecture data elements are developed such that architecture data elements defined in one view are the same (i.e., same names, definitions, and values) as architecture data elements referenced in another view. A subset of DoDAF products make up the foundation of an integrated architecture and consists of AV-1, AV-2, OV-2, OV-3, OV-5, SV-1, and TV-1 at a minimum (DoDAF, Vol I, p. 1-5). From a bottom up data perspective, ABM defines an integrated architecture description to be when architecture data elements are defined based on a methodology-independent, semantically complete model of the concepts used in understanding and describing integrated architectures. Integrated architectures usually have associated with them a time frame, whether by specific years (e.g., 2005-2010) or by designations such as as-is, to-be, transitional, objective, epoch, etc. In all cases, this reduces to either inventories of current capability (as-is) or blueprints of future capability (to-be). Domain experts, program managers, and decision-makers need to be able to analyze these architectures to locate, identify, and resolve definitions, properties, facts,

constraints, inferences, and issues both within and across architectural boundaries that are redundant, conflicting, missing, and/or obsolete. The analysis must also be able to determine the effect and impact of change (what if) when something is redefined, redeployed, deleted, moved, delayed, accelerated, or defunded. In most as-is architectures, details about architecture elements are fully known and architectures analysis can be readily accomplished. The present DoDAF approach to developing to-be integrated architectures and their analysis does not fully enable them to be used for true system engineering purposes to discover future enterprise rules, patterns, practices, relationships, and system and organizational requirements. That is because not all architecture details are known resulting in architecture descriptions that are based on unknowns and abstract elements. However, with ABM and by examining aggregations and clusters of architecture elements and by performing gap analysis and assessments, new system and organizational requirements can be derived. This would support justifications for future funding decisions of new systems, their elements, components, and supporting operational organizations. It is assumed that any architecture project begins with an effort to identify the architectures intended purpose, its scope, and level of detail that follows the six-step process detailed in (DoDAF Vol. I, pp. 5-4).

ActIvIty-bAsed methodoLogy
ABM presents a holistic approach for architecture development (Ring, Nicholson, Thilenius, & Harris, 2005). It establishes a common means to express integrated architecture data consistent with intent of DoDAF, JCIDS, ITPM, and the Clinger-Cohen Act (CCA, 1996). ABM provides a rigorous, disciplined, and structured approach to integrated architecture development and

93

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

analysis that is lacking today. It consists of a tool-independent methodology that enables fully integrated, unambiguous, and consistent DODAF views to be developed in supporting both as-is architectures and their analysis as well as to-be architecture and their analysis to include future gap-analysis. The Zachman framework (Zachman, 1987) describes a structure for defining and capturing architecture descriptions. It is arranged as a matrix where the columns represent six logical interrogative abstractions or aspectswhAT (Product), hOw (Function), whERE (Node), whO (Resourse), whEN (Event), why (Rule)and the rows represent unique viewpoint perspectives

or frames of reference (ORourke, Fishman, & Selkow, 2003). ABM architecture descriptions are based on this Zachman framework matrix with the six columns representing architecture elements and three architecture view row perspectives representing the three DoDAF viewsOV, SV, and TSV. Grouping of architecture elements into the six interrogatives ensures consistency in their meaning and eliminates any possible conflicting and/or misinterpretation of their definitions. Figure 4 illustrates DoDAF with ABM based on this matrix. ABM does not impact the DoDAF All View (AV) or Technical Standards View (TSV). However, the Operational View (OV) and System

Figure 4. DoDAF with ABM

Figure 5. Five pillars of an integrated architecture

94

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

View (SV) are directly impacted. ABM uses a data centric approach that supports cross-product relationships based on an integrated symmetric set of architecture building block elements. These enable several architecture elements and architecture products to be automatically generated. An integrated architecture, based on ABM, is built on a foundation of five pillars (Figure 5): 1. 2. 3. 4. 5. Separation of architecture elements into six interrogative groupings. Symmetric alignment of architecture elements. Four core architecture elements. Data-centric architecture data model. Generation of DoDAF elements and products.

Figure 8 shows how DoDAF associates its constituent architecture elements to each of the six interrogatives within the three DoDAF perspective views (Operational, System, Technical).

Pillar 2: symmetric Alignment of Architecture elements

The development of ABM led to a second observation that there are symmetrically aligned patterns of Operational and System architecture elements within each of the six interrogatives. By symmetric alignment, we mean that Operational and System architecture elements have similar meanings, associations/relationships, properties, and characteristics. For example, in the HOW aspect, activities within the Operational View are aligned with and correspond to system functions within the System View. The recognition of these DoDAF symmetric elements was a guiding principle in the development of ABM. These symmetrically aligned elements are divided into three object classes: entities, relationships, and attributes. In following an E-R-A approach to architecture objects, entity objects are the objects about which architecture data is collected, Relationship objects are the associations between entity objects, and attribute objects identify characteristics of entity and relationship objects. This symmetry and alignment is shown in Figure 9.

Pillar 1: separation of Architecture elements into six Interrogative groupings

The development of ABM began with a fundament architecture principle that architectural elements should be grouped according to the six interrogatives. From this fundamental architecture principle, the three-way association between three of the column interrogatives, hOw at whERE by whO, was observed (Figure 6). In the triple association, one can see in Figure 7 that the intersection of any two is the third.

Figure 6. Three-way associations of the six interrogatives

95

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 7. Intersections of hOw at whERE by whO

Figure 8. Mapping of DoDAF architecture elements to the six interrogatives

On the Operational View side, concept of operations (CONOPS), information, activities, nodes, roles, and processes represent the primary architecture objects. Need lines represent associations between information, activities and node entities with the information exchange providing the attributes of need lines. Roles have relationships with each other (e.g., supervisor, command, and coordinate), which are modeled as organizations and they possess knowledge, skills, and abilities (KSA) attributes. Similar associations and relations exist on the System View side.

Pillar 3: Four core Architecture elements

Four primary objects within each view are considered core (i.e., those building block primitives that make up the foundation of an integrated architecture). The associations between these core primitives form the basis of a data-centric integrated architecture. 1. FuNctioN (how: activity, system function): Actions by which input PRODUCTS are consumed in being transformed to output PRODUCTS. FUNCTIONS are usually decomposed to sub-FUNCTIONS. They carry

96

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 9. Symmetrically aligned architecture objects

2.

3.

dynamic time and costs properties needed in an executable architecture. ReSouRce (who: role, system): Means by which a FUNCTION is performed, processed, or executed. Roles are human resources, characterized by a set of knowledge, skills and abilities (KSA) assigned to humans and are analogous to job titles or job responsibilities. Systems are machine resources and are described in terms of their performance characteristics. Roles and systems can be structurally composed into organizations and networks. They each carry dynamic time and costs properties needed in an executable architecture. PRoDuct (what: information, data): Formalized representations of data subject to a transformation process. They are the inputs and outputs of FUNCTIONS. PRODUCTS can be decomposed into their component items so that, at higher levels of a FUNCTION model, an input/output can be considered as a bundle while at

4.

the lower levels the input/outputs consists of the unbundled component items. For example, weather could be made up of temperature and humidity so that weather is produced/consumed at the higher FUNCTION levels but temperature and humidity are separate inputs and outputs at the lower FUNCTION levels. Bundled information is usually graphically depicted as branchs/joins. PRODUCTS do not have time propertiestheir exchanges do. NoDe (wheRe: operational node, system node): Logical or functional encapsulations (i.e., groupings or collections) of (1) RESOURCES (if known) performing FUNCTIONS and (2) FUNCTIONS alone when RESOURCES are unknown (see Figure 10). NODES are usually where RESOURCES are located in performing FUNCTIONS. NODES can be decomposed to sub-NODES. They carry no dynamic time properties but carry cost properties.

97

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Since NODES are considered as encapsulations or collections, they may be graphically depicted as platforms (ground, air, and sea), organizations, facilities, tactical operational centers (TOC), air and space operations center (ASOC), vans, military units, buildings, and even soldiers. Figure 11 shows these graphical depictions of collections of RESOURCES performing FUNCTIONS (i.e., NODES). For any instance thats considered a NODE (operational, system), the same instance can also be considered a RESOURCE (role, system) at the same time and vice versa. Because of the separation of NODES and RESOURCES in ABM, one can have the same textual representation for bothonce for a NODE (operational, system) and once for a RESOURCE (role, system). Having the same textual representation for both NODE and RESOURCE has no impact because they separately exist. Note that a NODE could also have been considered an organization and an organization also considered as a NODE. Again, with the separation in ABM, one can have the same textual representation for both concepts in the same architecture. This separation eliminates any semantic overloading of the NODE definition.

Figure 11. Graphical examples of nodes

Figure 10. NODES as collections of RESOURCES performing FUNCTIONS

For example, lets say an architect views a military unit organization as a role and creates the 1-8 Armor Battalion role. If in the same architecture, the same military unit organization is considered as a node, then the architect creates the 1-8 Armor Battalion node. Because of the separation of the two node and role definitions in ABM, information exchanges and need lines will be consistent. That is, some activity is performed by the 1-8 Armor Battalion role at the 1-8 Armor Battalion node. In addition, when the OV-2 node diagram is viewed, the architecture will see the 1-8 Armor Battalion as a node item which is entirely consistent with the architects view of the architecture. Similarly, when the OV-4 organization diagram is viewed, the architect will see the 1-8 Armor Battalion as a role itemagain entirely consistent with architects view of the architecture. In all cases, the consistency of the three-way association between NODE, FUNCTION, and RESOURCE is always maintained allowing complete flexibility in creating architectures. The benefit to the architect is that the architecture diagrams and models are consistent with

98

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 12. Three-way associations of core architecture objects

Figure 13. Visualization of three-way associations

the manner in which they are defined, viewed, and intended. The core elements relate to each other such that: Each (activity, system function) that produces and consumes (information, data) is performed at an (operational node, system node) by a (role, system) Each (operational node, system node) contains a (role, system) that performs an (activity, system function) that produces and consumes (information, data) Each (role, system) in an (operational node, system node) performs an (activity, system function) that produces and consumes (information, data) (information, data) is produced from and consumed by an (activity, system function)

performed by (role, system) at a (operational node, system node) This is the foundation for the dual set of three-way relationships as shown in Figure 12. The intersection of the association between an activity and a node is a role and, likewise, the intersection of the association between a system function and a system node is a system. Figure 13 shows how the three-way associations can be visualized by having each FuncTion, nodE, and rEsourcE core element graphic object display its respective associations with the other two core elements.

Pillar 4: Data-Centric Architecture Data Model

Figure 14 shows how the core architecture elements are related and their source dodAF

99

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

products. Because of the symmetrically aligned set of architecture elements shown in Figure 9, ABM addedOV-4 (roles), OV-7 (information), SV-2 (Networks), SV-4 (system Functions), SV-5, and SV-11 (Data)to the original seven DoDAF integrated product set (AV-1, AV-2, etc.). SV-5, in particular, maps activities to system functions enabling integrated Operational and System views within a single architecture. The four core elements come together to form information exchanges and system data exchanges from which need lines and interfaces are extracted. The source DoDAF products for the core elements are summarized in Table 4. Figure 15 depicts the top-level ABM architecture data model. As important as it is to understand the direct relationships that exist between the architecture

data elements, it is equally important to understand the direct relationships that do not exist. For example, systems are not directly related to activities. They are related, indirectly (via SV-5), first to system functions and then from system functions to activities.

Pillar 5: generation of Architecture elements and dodAF Products

ABM introduces generation of several architecture elements (exchanges, need lines, and interfaces) and products (OV-2, OV-3, SV-1, SV-6) into the architecture development process. Generation of these elements and products eliminates user inputs and speeds up the entire development process. This ensures data consistency and quality and results in a deterministic collection of architecture

Figure 14. Core architecture element associations

Table 4. Core architecture element source products

coRe Function Product Node Resource SouRce oV OV-5 activities OV-7 information OV-2 operational node OV-4 role SouRce SV SV-4 system function SV-11 data SV-1 system node SV-1 system

100

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 15. Top level ABM architecture data model

artifacts that can be repeatedly regenerated as the architecture evolves and matures. To enable valid generation of these elements and products, ABM introduces external FUNCTIONS as high level context FUNCTIONS in the FUNCTION model. They are perfomed by external RESOURCES at external NODES in producing and consuming PRODUCTS (information, data) to/from the highest level context FUNCTION. External FUNCTIONS, External RESOURCES, and External NODES are all considered outside the scope of the context FUNCTION model. They provide producing and consuming ending FUNCTIONS when generating operational/ system exchanges between themselves and leaf FUNCTIONS. Figure 16 shows an Operational View example where two external activities are each associated with their own external nodes and external roles in providing the source of an input and the destination of an output into and out of the context activity. Defining external (producing and consuming) elements enables ABM-based integrated architectures to be federated together. This is because the consuming external elements of one architecture are the producing external elements of a second federated architecture. Conversly, the producing external elements of one architectuere are the consuming external elements of a second federated architecture.

Need lines (Operational) and interfaces (System) document the requirement to exchange (1) PRODUCTS between NODES and (2) PRODUCTS between RESOURCES. Exchanges identify who exchanges what products, with whom, why the information is necessary, and how the information exchange must occur. Exchanges and their need lines/interfaces are generated from their four producing and consuming core elementsleaf FUNCTIONS (including external activities), their input and output PRODUCTS (information, data), and their associations to NODES (including external nodes) and to RESOURCES (including external roles and systems). FUNCTION models are decomposed down to the appropriate level for the purposes of the architecture. Leaf FUNCTIONS are at the lowest decomposition level. Usually, this would be to the level where a FUNCTION is capable of being (i) associated with a single NODE and/or (ii) assigned to an individual RESOURCE, and/or (iii) has a single input or single output PRODUCT. Usually leaf FUNCTIONS are some combination of these three and subject to judgment calls by the architect. Figure 17 graphically illustrates how NODE need lines/interfaces (between two NODES) contain collections of RESOURCE need lines/ interfaces (between two RESOURCES within each NODE) which, in turn, contain the entire

101

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 16. Context activity model with two external activities

Figure 17. Need lines/interfaces and exchanges

collection of the individual exchanges (between two functions performed by the two RESOURCES at the two NODES). Need lines/interfaces can be alternatively be visualized (Figure 18) where a single NODE need line/interface pipeline consists of one or more RESOURCE need line/interface pipelines each consisting of one or more exchanges. OV-3 information exchanges and OV-2 need lines are generated from their four producing and consuming core elementsleaf activities, their information inputs and outputs, and their associations to nodes and to roles as shown in Figure 19.

Figure 18. Need line/interface collections

Likewise, the SV-6 system data exchanges and SV-1 interfaces are generated from their four producing and consuming core elementsleaf system functions, their data inputs and outputs, and their associations to system nodes and to systems as show in Figure 20. Information exchanges are always generated between producing and consuming leaf activities and their associated op nodes. However, valid and consistent need lines on OV-2 diagrams are only obtained when information exchanges are formed from leaf activities at different nodes. Likewise, system data exchanges are always generated between producing and consuming leaf system functions and their associated system nodes. However, valid and consistent interfaces on SV1 diagrams are only obtained when system data exchanges are formed from leaf system functions at different system nodes. While exchanges can be generated, their DoDAF properties (transport times, security classification, etc.) can not be automatically filled in and, therefore, must be defined manually. This makes exchanges persistent architecture data in

102

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 19. Operational Exchanges and need lines

Figure 20. System Exchanges and interfaces

that, once generated and their properties defined, they should not be deleted because their DoDAF property attributes will be lost. Need lines and interfaces, on the other hand, carry no properties and can be deleted and regenerated again as the (activity, system function) model grows and contracts with additional (or subtractive) (activities, system functions), (information, data) inputs/outputs, nodes, and (roles, systems). In ABM, because need lines and interfaces have been identified from the generation of exchanges, both OV-2 and SV-1 diagrams can be graphically populated with nodes and their corresponding need lines and interfaces. In fact, as many individual node-centric OV-2 and SV-1 diagrams can be graphically populated as there are operational and system nodes. This makes OV-2 and SV-1 expendable because they can always be repopulated with nodes and (need lines,

interfaces) and their associated exchanges as the architecture model changes and matures. The OV-3 product is, essentially, a spreadsheet document since it consists of the entire collection of information exchanges (and their properties) within an architecture model. Likewise, SV-6 product is a spreadsheet document since it consists of the entire collection of system data exchanges and their properties.

AnALysIs (stAtIc)
From the top level ABM architecture data model in Figure 15, it can be seen that the basic triple association is very simple and elegant yet very powerful. From this model, one can obtain a more detailed and complete analysis of complex architectures. In fact, one could say that all the

103

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Table 5. DOTMLPF analysis

Doctrine organization training Material Leadership Personnel Facilities Activities, roles, nodes Org units Activities, roles, systems System functions, systems, system nodes Org units, roles, systems Roles Operational nodes, system nodes Examine tactics, techniques, and procedures Examine organizational structure Train personnel on their activities and any systems they use in performing those activities Examine materiel solutionsa new system Examine leadership issues Examine personnel solutionsnew personnel or personnel with better qualifications Examine fixing, building, or modifying facilities

answers to static architecture analysis queries are already in the architecture datathat is the easy part. The hard part is determining the appropriate analysis queries. Four unique but related architecture techniques support the eventual mission outcome decisionmaking process as shown back in Figure 1. Core integrated architecture analysis. DOTMLPF analysis. Gap analysis of to-be architectures. Architect data mining of exchanges.

tion and their relations to system functions at system nodes producing/consuming data. Resource (who) analysis: Roles, systems and their activities and system functions.

dotmLPF Analysis
DOTMLPF analysis leads to better definitions of warfighting capabilities by being able to anticipate effects and assess impact of change on domains and by examining usage (who/what affects something) and references (who/what is affected by something). DOTMLPF domains map to ABM architecture element analysis as shown in Table 5.

core Integrated Architecture Analysis

By examining different sets of relationships between and among the four core architect elements, various types of integrated architecture analyses can be obtained: Functional (how) analysis: Activities and their related system functions. Nodal (wheRe) analysis: Activities and their op nodes and their relationships to system functions and their system nodes. Product (what) analysis: Activities at op nodes producing/consuming informa-

gap Analysis of To-Be Architectures

For to-be architectures, where not all elements are known, gap-analysis can discover those unknowns. Usually, in as-is and to-be architectures, both activities (system functions) and nodes (operational and system) are usually known. Also, in as-is architectures, roles (systems) are usually known. However, for to-be architectures, in most cases roles (systems) may or may not be

104

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

known. Figure 21 shows how gap-analysis of to-be architectures reveals: orphaned activities: Activities at nodes without roles. orphaned systems: System functions at system nodes without systems.

By clustering and aggregating these orphaned elements and by performing gap analysis and assessments, new system and organizational requirements can be derived. This would support justifications for future funding decisions of new systems, components, and supporting operational organizations.

ments on how an enterprise operates. OV-3, SV-6 exchanges together with SV-5, as show in Figure 22, identify connections between producers and consumers at the functional leaf level. This is essential for what if and if what impact assessments between what is required and what is delivered. For example, one could assess the impact of losing a system or a system node on operations (activities, nodes, roles, etc). In addition, one could obtain a set of hidden requirements for an operational node and a role where such requirements would be derived from the indirect relationship between nodes and roles to systems, system nodes, and to system functions.

ArchItecture dAtA mInIng AnALysIs oF exchAnges

Mining architecture data reveals and helps discover hidden patterns, rules, practices, gaps, overlaps, redundancies, relationships, and require-

dynAmIc AnALysIs And trAnsItIon to executAbLe ArchItectures

Static operational models only show that operational activities must be capable of producing and consuming information. They do not provide

Figure 21. To-be gap analysis

105

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Figure 22. Architecture data mining with OV-3/SV-6 exchanges

details on how or under what input/ output conditions PRODUCT (information, data) is produced/ consumed. They also do not explicitly identify, for each activity, the timing details or the number (capacity) of RESOURCES (roles, systems) needed or their ordering for the case when multiple roles perform the same activity (who operates on the first input, who operates on the second, etc). To appropriately assess measures of performance and effectiveness in an operational environment, dynamic modeling and simulation executable process model architectures need to be developed. An executable architecture is defined here as a dynamic (over time) model of sequenced processes/events (concurrent or sequential) performed at a node by roles (within organizations) using resources (systems) to produce and consume information (data). ABM was designed to capture sufficient representations of static architecture model descriptions that enable them to be transitioned into dynamic executable process models. Executable process modelsthe whEN (event) aspect analysisenables time-dependent behavior analysis and dollar cost assessment of complex, dynamic operations, and human and system resource interactions that cannot be identified or properly understood using pure static models.

Dynamic executable process models go beyond must be capable of and define precisely under what conditions information and data is actually produced/consumed and the exact number and ordering of roles. It can be used to show how to transform and evolve organizations, processes, and modes of operation to adapt to new roles, relationships, technologies, and threats. The transition is accomplished by starting with the extracted set of leaf activities to which (among others) dynamic processing time (duration) and any statistical time distribution, average wait time before processing, continuation strategy, activity cost, and input/ output conditions are all defined. By connecting and chaining these leaf activities according to the information exchanges defined between them, we can produce candidate process scenario thread models of sequenced actions. Roles and systems are the human/machine resources used by each process and they may have (among others) single/ periodic (un)availability times, set up times, capacity (quantity), processing strategies (FIFO, etc.), and hourly and fixed cost. External activities serve as sources of inputs and transition to triggers that start the execution process. External activities serving as destinations of outputs transition to outputs that terminate the execution process.

106

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

executable Architecture methodology for Analysis (eAmA)

In a MITRE research effort, a federation of executable architecture simulations were linked, within the context of a mission thread, to dynamically access and measure process performance and force effectiveness, organizational work efforts, resource allocation, communication capability, and ultimately, mission success (Pawlowski, Barr, & Ring, 2004). The federation consisted of a three-way link (via HLA) between an executable operational architecture model of processes and organizations, an executable network and communications model of exchanges and information flow, and a combat simulation model that provided the operational context and warfighting environment for the mission thread. Lockheed-Martin used the EAMA approach in building their Federated Executable Architecture Technology (FEAT) demonstration for the Air Force Agency for Modeling and Simulation (AFAMS) (Harrison, Benjamin, Elliot, Hutt, & Kern, 2005). FEAT is an enabling technology that supplies architecture verification and optimization, multi-resolution distributed simulation, and hybrid simulation of architected scenarios.

mission-level objectives and outcomes in a costeffective manner.

workFLow stePs to An IntegrAted ArchItecture: the Art of ArchItecture

ABM architecture development workflow consists of seven stepsthree modeling steps, one association step, and three automated steps. This ensures a consistent ordering of framework product development associated with the four core architecture elements. The first step in the ABM workflow creates a FUNCTION model together with a PRODUCT model for the two of the core architecture objects. The next step creates the third core object, NODES, and the fourth, RESOURCES. At this point, the core objects have been defined and they can be associated together. ABM considers these first four workflow steps the Art of Architecture (i.e., understanding and identifying the core architecture objects and how they are related). If one considers the FUNCTION, RESOURCE, NODE, and PRODUCT models as an artists canvas and the core architecture elements as a set of paints and paintbrushes, then an architect developing an architecture is similar to an artist creating a masterpiece painting. From this point on, there is sufficient architecture data for automation to take overgenerating exchanges (information, system data) and their related need lines and interfaces. The NODE products, OV-2 and SV-1, can now be graphically completed by auto-connecting each node pair with their corresponding need lines and interfaces. The various DoDAF exchange properties can now be defined. Exchanges, together with their property values, become the OV-3/ SV-6 product. ABM considers the analysis of architectures (as discussed in earlier in the chapter) as the science of architecture. Table 6 and Figure 23 summarize the ABM workflow steps.

Portfolio Investment Analysis

At present, architecture-based portfolio investment decisions are not prevalent in the DoD. Another MITRE research effort showed that linking integrated and executable architectures with portfolio investment analysis tools and techniques provides a robust analytical foundation for capability and architecture-based investment decisions that fully supports critical DoD transformation goals, guidelines, and policies (Ring, Lamar, Heim, & Goyette 2005). A portfolio investment analysis helps decision-makers select the best combination (or portfolio) of investments from a set of potential investment options to achieve

107

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Workflow Steps to an Integrated operational Architecture

The Operational View workflow steps follow the basic ABM workflow steps. Table 7 and Figure 24 illustrates these steps. An OV-5 activity model should consist of a wellformed, balanced, and consistent set of activities, their sub-activities, external (activities, roles, and nodes) and their various inputs and outputs.

Workflow Steps to an Integrated system Architecture

The System View workflow adds two more steps to the workflow for SV-3 and SV-5. Figure 25 and Table 8 illustrates these steps. Like an OV-5 activity model, an SV-4 system function model should consist of a well formed, balanced, and consistent set of system functions, their sub-system function, external (system functions, system nodes, and systems) and their various inputs and outputs.

Table 6. AMB workflow steps and Summary of integrated product set

Steps 1a) Create FUNCTION Model 1b) Create PRODUCT Model 2) Create NODES
Model

3) Create RESOURCES 4) Associate FUNCTIONS with NODES with RESOURCES

Associate

OV Activities - OV-5 Information OV-7 Operational Node OV-2 Role - OV-4 1) Activities with Op Nodes with Roles

SV System Function SV-4 Data SV-11 System Node SV-1 System SV-1 1) System Functions with System Nodes with Systems 2) Activities with System Functions SV-5 1) Generate System Data Exchanges 2) Complete SV-1with Interfaces 3) Generate SV-3 Systems-Systems Matrix 4) Generate SV-6

Automate

5) Generate EXChANGES and fill in properties 6) Complete NODE products OV2, SV-1, with Need Lines and Interfaces 7) Generate EXChANGE Products OV3/SV6

1) Generate Information Exchanges and Need Lines 2) Complete OV-2 with Need Lines 3) Generate OV3

Figure 23. ABM workflow

108

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

comPArIng Abm wIth IdeF0

ABM uses some of the IDEF0 (FIPS 183, 1994) modeling conventions (e.g., parent/child activity decomposition hierarchy) but does not use others (mechanisms and controls). This is because some IDEF0 conventions are incompatible with building consistent DODAF data-centric integrated architectures (e.g., mechanisms can be systems) and other conventions (e.g., outputs as controls, etc.) are incompatible with generating exchanges. Building integrated architectures and generating exchanges are more important and take precedence over adherence to strict IDEF0 modeling conventions and rules.

For example, ABM does not use mechanism or control arrows per se with activities. For mechanisms, a different approach was taken based on the three-way association between FUNCTIONS, NODES, and RESOURCES. Because of the separation of RESOURCES into roles and system, systems can only be only indirectly associated with activities though SV-5. That is, systems are associated with system functions, which in turn, are associated with activities via SV-5. This is incompatible with the IDEF0 definition of a mechanism of an activity as being a system. For controls, a different approach was taken by defining an association between activities (system functions) and standards. Standards (from the DoDAF Technical Standards View) take the

Table 7. Operational View workflow steps

1a. Create OV-5 activity model. 1b. Create OV-7 information model. 2. Create OV-2 nodes. 3. Create OV-4 roles and organizational units. 4. Associate activities with nodes with roles.

5. Generate information exchanges and fill in properties. 6. Complete OV2 with need lines. 7. Generate OV3 operational information exchange matrix.

Figure 24. Operational workflow

109

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

place of controls and can be associated with both activities and system functions. Figure 26 shows an example of this 2-way association. Again, consistency of building integrated architectures and generating exchanges is more important and takes precedence over adherence to strict IDEF0 modeling rules.

Abm syntAx ruLes

ABM syntax rules ensure (i) accurate generation of exchanges between any two functions (activities, system functions) and (ii) consistency in node and resource models. Rule #1: FUNCTION models must include at least two external FUNCTIONS (activities, system functions).

Table 8. System View workflow steps

1a. Create SV-4 system function model. 1b. Create SV-11 data model. 2. Create SV-1 system nodes. 3. Create SV-1 systems. 4. Associate system function with system nodes with systems.

5. Create SV-5--associate system function with activities

6. Generate system data exchanges and fill in properties. 7. Complete SV-1 with interfaces. 8. Generate SV-3 systems-systems matrix product. 9. Generate SV-6 systems data exchange matrix product.

Figure 25. System view workflow

110

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

Rule #2: Leaf FUNCTIONS (activities, system functions) must have at least one input and at least one output (different from each other) from/to either another FUNCTION (activity, system function) or an external FUNCTION (activity, system function). Rule #3: (Need lines, interfaces) within the same NODE (operational, system) or RESOURCE (role, system): one must first decompose the NODE or RESOURCE into sub-NODES and/or sub-RESOURCES and then reassocciate the appropriate FUNCTIONS (activities, system Functions) to the appropriate sub-NODES and or subRESOURCES.

summAry And concLusIon

This chapter presented the activity-based methodology, a rigorous, disciplined, and structured approach to the Art and Science of architectures. A set of architecture requirements showed how actionable information can be produced from actionable architectures that supports a set of core organizational processes. Five pillars of ABM were defined as the foundation of integrated architectures with the fundamental principle that architectural elements should be grouped according to the six interrogatives. The four core architecture elements, how they are symmetrically aligned, and related together in a data-centric architecture description model were explained. How ABM delivers significant architecture development productivity and quality gains was shown. Numerous static and dynamic analysis techniques and strategies were presented to show the value of integrated architectures to decision makers and mission outcomes. Workflow steps for creating integrated architecture were detailed. Architectures are not just paper models to be hung on walls and admired. They are living electronic documents evolving and maturing over

Figure 26. Activity to standard associations

Figure 27. Decision-making roadmap

111

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

time that, through various analysis and assessment techniques, provide real value to an organization, to an enterprise and, ultimately, to a decision maker and mission outcomes and objectives. In conclusion, the roadmap in Figure 27 validates the original premise from Figure 1. Architecture development guidance combined with compliant architecture tools and the activity-based methodology makes possible integrated architectures. Integrated architectures combined with simulation tools and scenarios render executable architectures. Integrated architectures, executable architectures, analytical tools, and methods render quantitative actionable architectures, which, in turns supports such decision-making processes as portfolio management, acquisition, JCIDS, and mission planning in support of mission outcomes.

to warfighters. The C2C architecture was the best true OV-5 representation of Constellation processes and was widely distributed to the C2 community. The architecture was published as part of the U.S. Air Forces Warfighting enterprise architecture (AF EA, 2005).

AcknowLedgments
The authors would like to acknowledge the United States Air Force Deputy Chief of Staff Office, Warfighting Integration (AF/XI), and United States Air Force Chief Architects Office (AF CIO/A) for their support in the development of ABM. The authors would also like to acknowledge the effort of Stanley Harris (of Lockheed-Martin Corporation) for his guidance, assistance, and contributions that made the activity-based methodology possible.

AvAILAbILIty oF Abm
ABM is in the public domain and is commercially available. Three major enterprise architecture technology companies have implemented ABM. Telelogic Corporation (Telelogic) has supported ABM in their System Architect product since 2004. This was followed in 2005 by Troux Technologies (Troux) when they implemented ABM as part of their DoDAF Template 1.1 for their METIS product. Proforma Corporation (Proforma) announced support for ABM in their ProVision product in 2006. These vendor products are widely used throughout DoD and Federal Government. In the recent DoD EA survey (Ring, & Johnson, 2005), 25% of those responding use ABM-based products in their architecture development environment. In one example of ABM usage, the U.S. Air Force employed ABM in the development of the Command and Control Constellation (C2C) v2.0 operational architecture (Sweet & Kanefsky, 2004). The C2C articulates the Air Force vision of a network-centric, peer-based family of systems providing decision-quality information

reFerences
C4ISR Architecture Framework, v2.0 (1997). December 18. Clinger-Cohen Act of 1996: Information Technology Management Reform, Public Law 104-106, Fiscal year 1996 Defense Authorization Act. (DoDAF, 2003) DOD Architecture Framework (DoDAF), V1.0, Vol. I and II, 15 August 2003 (DODI 8115.bb, 2006) DODI 8115.bb, Information Technology Portfolio Management, 2006 (FIPS 183, 1994) Federal information Processing Standards Publications 183, Integration Definition Function Modeling (IDEF0), June 30, 1994. www.idef.com Harrison, G. A., Benjamin, D. C., Elliot, L. G., Hutt, R., & Kern, H. S. (2005, September). Modeling and enhancing C4ISR with executable

112

Activity-Based Methodology for Development and Analysis of Integrated DoD Architectures

architectures. The 2005 Fall Simulation Interoperability workshop, sponsored by Simulation Interoperability Standards Organization, Orlando, FL (pp. 18-23). (JCIDS, 2005) Joint Capabilities Integration And Development system (JCIDS), CJCSI 3170.01, 11 May 2005 Nicholson, D., Mercer, B., & Ang, H. (2005). Addressing conceptual deficiencies in DoDAF through an architecture specification model ASM. In Proceedings of Conference on Defense Transformation and Network-Centric Systems (Vol. 5820), SPIE, Orlando, FL. ORourke, C., Fishman, N., & Selkow, W. (2003). Enterprise architecture using the Zachman framework. Thomson Course Technology Publishing. Pawlowski, T., Barr, P., & Ring, S. J. (2004). Applying executable architectures to support dynamic analysis of C2 systems, #113, 2004. Command and Control Research and Technology Symposium, San Diego, CA. (Proforma) Proforma Corporation, http://www. proformacorp.com/ Ring, S. J., & Johnson, M. (2005). State of DoD Architecting. Command Information Superiority Architectures (CISA) Worldwide Conference, Omaha, NE, December 1, 2005

Ring, S. J., Lamar, B., Heim, J., & Goyette, E., (2005). Integrated architecture-based portfolio investment strategies. The 10th International Command and Control Research and Technology (ICCRTS) Symposium, McLean, VA. Ring, S. J., Nicholson, D., Thilenius, J., & Harris, S., (2005), An activity-based methodology for development and analysis of integrated DoD architectures. 2004 Command and Control Research and Technology Symposium, San Diego, CA. Sweet, N., & Kanefsky, S. (2004). The C2 constellation: A US Air Force network centric warfare program network centric applications and C4ISR architecture. 2004 Command and Control Research and Technology Symposium, San Diego, CA. Telelogic Corporation. www.telelogic.com Troux Technologies, www.troux.com U.S. Air Force Chief Architects Office (2005, May 31). United States Air Force Enterprise Architecture, CD-ROM. Zachman, J. A. (1987), A framework for information systems architecture. IBM System Journal, 26(3). Retrieved from www.zifa.com

113

114

Business Process Modeling as a Blueprint for Enterprise Architecture

Joseph Barjis Georgia Southern University, USA Isaac Barjis City University of New York, USA

Chapter VI

AbstrAct
For a successful study, design and development of the enterprise architecture, a thorough insight into the essence of the work and operation of an enterprise, is a crucial factor. As the well-known Zachman and other modern frameworks illustrate, enterprise processes and process modeling are one of the fundamental components of enterprise architecture for providing such an insight. Like building construction in which construction drawings or blueprints play crucial roles, enterprise process models are critical in developing enterprise architecture. Moreover, one may argue that the role of business process modeling in enterprise architecture is similar to the floor plan that defines the boundaries of a building to be constructed. Therefore, a suitable enterprise process modeling approach that could capture the essential operations and reflect the cross-enterprise (cross-departmental) processes is a needed component to complement enterprise architecture. In this chapter, authors study, discuss, and review the practical role of enterprise process modeling in enterprise architecture using a real life organization-based case study. Authors introduce a modeling methodology that captures essential activities not only within a process but also from the enterprise perspective where cross departmental or enterprise processes are represented.

IntroductIon
For developing business goals-oriented enterprise architecture, system designers need to seriously

focus on enterprise process perspective in such a task. This stand will not only allow organizations to achieve their business goals, but also enable them to better reconcile business and IT that

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

Business Process Modeling as a Blueprint for Enterprise Architecture

consumes millions of dollars invested into the enterprise IT infrastructure. In fact, enterprise architecture provides a high-level description and view of the primary resources of any enterprise (Anaya & Ortiz 2005). These primary resources include users (users), processes (business processes), and technology (hardware and software). However, the process or business process component of enterprise architecture represents the most central and fundamental, because it connects the other two resources (users and technology). Poor definition of business processes in an enterprise architecture leads to a number of problems such as business and IT gap. A number of tools, techniques, and methodologies are developed to support enterprise business process modeling that could ensure a well-developed enterprise architecture that guarantees achievement of business goals. According to Dalal, Kamath, Kolarik, and Sivaraman (2004), among multiple tools are data flow diagrams (DFDs), integration definition for function modeling (IDEF0), and activity diagrams in the unified modeling language that all have their roots in process modeling for software development. Similarly, a number of methodologies for enterprise business process modeling were developed, each taking a different philosophical stand such as organizational semiotics by Stamper (1988, 1997) and DEMO (Design & Engineering Methodology for Organizations) methodology by Dietz (2006). In this chapter, we use the language action perspective paradigm supported by a rigorous modeling technique based on Petri nets. The methodology is illustrated on a case study conducted in a small enterprise. Petri nets have been tested and used in enterprise process modeling and workflow management by many authors (van der Aalst & van Hee, 2002; Deiters, 1998; Jensen, 1997a, 1997b); however, in this chapter we discuss application of Petri nets based on the language action perspective. The main motive on using and adopting Petri nets in enterprise business process

modeling is their capability to model and analyze concurrency, choice, asynchronous completion, as well as their ability to visualize and simulate the modeled process. The type of Petri net introduced in this chapter is based on the language action perspective, or more precisely, on the transaction concept introduced in Dietz (1999). The transaction concept provides a transparent insight into the essence of enterprise processing irrespective of its realization or technical aspects. The concept is based on the notion that an enterprise is a network of business transactions that are exchanged daily while carrying out the mission of the enterprise and interacting with the environment (customers, partners). The remainder of this chapter provides an introduction to Petri nets, the transaction concept, and its underlying paradigmlanguage action perspective. The proposed methodology is illustrated on a case study conducted in a small enterprise. For those readers not familiar with the language action perspective, the background section contains a brief overview of this framework.

business Architecture
The business architecture component (domain, level, or subset) of the enterprise architecture (EA) framework represents an essential component and, therefore, in all different EA Frameworks it is given an important emphasis. In the well-known Zachman framework for enterprise architecture, business architecture is identified as business model. In the open group architecture framework (TOGAF), which provides a comprehensive approach to the planning, design, implementation, and governance of enterprise information architecture, business architecture is called business. Within the TOGAF, there are four types of architecture that are commonly accepted as subsets of an overall enterprise architecture. These subsets or components are:

115

Business Process Modeling as a Blueprint for Enterprise Architecture

A business (or business process) architecture that in particular defines key business processes. An applications architecture that provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization. A data architecture that describes the structure of an organizations logical and physical data assets and data management resources. A technology architecture that describes the software infrastructure intended to support the deployment of core, missioncritical applications. This type of software is sometimes referred to as middleware.

ness process requires a more holistic (integrated) approach rather then an isolated approach (Lopez & Genovese, 2004; Taft, 1996). In developing realistic and accurate enterprise architecture, the modeled business process should be capable of dealing with a very detailed level of analysis. In this respect, McDavid (1999) refers to an old saying the devil is in the details. He suggests that for a useful architectural approach, analysts need to be able to represent and organize the complete range of details relevant to the business processes. Thus, this chapter is an attempt to tackle the details of business processes relevant to the overall objective of a business architecture and enterprise architecture.

bAckground
The third framework that is noteworthy is the one derived from a practical project and a real life system within the U.S. National Institutes of Health (NIH). National Institutes of Health is the part of the U.S. Department of Health and Human Services that serves as a primary Federal agency for conducting and supporting medical research. The enterprise architecture framework of NIH, which is based on the Federal enterprise architecture, consists of three distinct architecture areas: business architecture, information architecture, and technology architecture. The intention of this brief introduction of a few EA frameworks, which resulted from research studies as well as specific projects, is to highlight the critical and strategic place of business architecture within the EA framework. Furthermore, it is important to stress the importance of business process, the need for holistic approach in business process, and detailed level analysis of business process. Since business processes constitute the foundation in a business architecture (Herman, 2001), in this chapter the main emphasis is put on business processes and the use of modeling for process elicitation. Also, it should be noted that in order to develop enterprise architecture, busiThe increasing interest in studies on enterprise architecture and its components is a clear manifest of considering business process management as a backbone of enterprise architecture. Advocates of business process management, within the enterprise context, claim that accurate incorporation of business processes into enterprise architecture development prevent disastrous IT failures. A significant portion of enterprise budgets is consumed by IT (Carr, 2003), that is, IT failure exposes ever-increasing consequences and disaster for businesses. Thus, the inclusion of enterprise business process into enterprise architecture development should be considered of vital importance for success. One of the challenges in enterprise business process study is the adequacy, simplicity, integrity, and computer support of methodologies and tools used for this purpose. The difficulty arises from the fact that different methodologies and tools came out of experiences and expertise of authors with certain predetermined scope. While some methodologies are well zoomed and focused on one aspect, they lack strength in another aspect; for instance, a methodology may provide a profound theoretical

116

Business Process Modeling as a Blueprint for Enterprise Architecture

concept but lack clear diagrammatic notations or computer support. In this chapter, the transaction concept and Petri nets are integrated to furnish enterprise systems designers and developers with better tools. This arsenal is further complemented by rigorous graphical notations of Petri nets extended for the language action perspective. The transaction concept, authored and introduced by Dietz (1994, 1999, 2002), is based on the language action perspective looking at communication as a representation of actions. The transaction concept, that will be discussed later, is about how communication leads to actions and can serve as a basis for capturing essential business processes within an enterprise. It is very natural that people describe their work and activities in a natural language. People use natural language to communicate while conducting business and carrying out tasks, therefore, the transaction concept is a profound tool to watch and observe communication in an organization in order to identify patterns of action. In order to put these patterns of action in a meaningful order, visualize these patterns, build a complete model of these patterns, analyze the model, and communicate the results back to the users, clear and readable graphical notations are needed. For this purpose, the rich graphical notations of Petri nets are combined with the transaction concept that resulted in transaction-oriented Petri nets methodology, or TOP methodology for short. The concept of language action perspective traces its origins to the speech act theory stating that language is not only a means of exchanging information but also a means of social activities or actions (Austin, 1962). Austins historic work, How to do things with word, paved a profound road for extensive research interest resulting into what is now known as the language action perspective and communication modeling. The Austin theory was further advanced and complemented in the works of Searle (1969), who presents a theory

of speech acts relying on the notion of constitutive rules (Habermas, 1984; Medina-Mora, Winograd, Flores, & Flores, 1992; Winograd & Flores, 1986). The work of Winograd and Flores introduced a modeling approach that illustrates conversation for action as sequences of communicative acts involving two actors. Their schema conversation for action was further developed by Dietz (1999) in the concept of business transaction, the core concept of the DEMO methodology. This chapter is based on the transaction concept as introduced within the DEMO framework and using Petri nets as a modeling technique.

PetrI nets (Pn)

Since its introduction in 1962 by Carl Adam Petri in his PhD dissertation, Petri nets have been applied to a variety of application domains such as communications networks, transportation systems, manufacturing systems, defense systems, and biological systems, just to name a few. Its comprehensive graphical notations, powerful formal specification tool, and executable technique for specification, analysis, and design of systems secured a distinguished place among other conventional techniques, methods, and methodologies. Apart from these features, Petri nets are one of the well computer supported tools including free and commercially available software for supporting Petri nets. The application of Petri nets to systems design and modeling has driven tremendous interest among researchers and practitioners, and a huge number of papers, theses, and projects were devoted to this issue. As a result, Petri nets have been extended to various domains, resulting in different types of Petri nets; however, the basic principles of Petri nets and graphical notations remain almost the same. For interested readers, some references on Petri nets include:

117

Business Process Modeling as a Blueprint for Enterprise Architecture

Standard (or elementary/classic/low level) Petri nets (Peterson, 1981) in which token are identical or indistinguishable. Colored Petri nets in which each token has value, thus tokens are different or distinguishable (Jensen, 1997a, 1997b). Hierarchical Petri nets in which certain elements (e.g., a transition) of Petri nets encompasses a subnet or entire Petri nets. High level Petri nets usually represent colored and hierarchical Petri nets (Reisig & Rozenberg, 1998). Stochastic Petri nets add non deterministic time (Haas, 2002). Timed Petri Nets in which transitions are assigned duration weight. Predict/transition nets (Pr/T-nets). Workflow Petri nets (van der Aalst et al., 2002), etc. Definition: Petri nets are a graphical and mathematical modeling tool that is particularly well suited for discrete event systems. The Petri nets diagrammatic structure consists of places, transitions, and directed arcs as depicted in Figure 1. Places can contain tokens (one or more). Graphically, places are represented by circles (or ellipses), transitions by rectangles (or bars), and tokens by black dots (or numbers). Place: (two types) Input place and output place: an input place may represent input data, condition, command, request, or material; an output place may represent a state or a result achieved after its corresponding

activity (transition) takes place. Places can contain tokens that illustrate the current state of the modeled system (the marking). The marking used to describe the initial state of the system is called the initial marking. Transition: A transition represents an action, process, operation, or any activity that changes the state of the system or causes advances and progress in a process. Arc: In its common role, an arc illustrates the course of actions, the flow of processes, or the sequence of operations. Token: Tokens are indicators of the systems state. Thus, an overall distribution of tokens represents the overall state of the system at a given time. The current state of the modeled system is given by the number of tokens in each place or by type if the tokens are colored (distinguishable).

the trAnsActIon concePt

As we previously mentioned, the transaction (or business transaction) concept used in this chapter, originated from the DEMO methodology authored and developed by Dietz (1999, 2002). The concept is based on the idea that an organization and its underlying business processes are a network of business transactions that constitutes the essence of this organization. This concept looks at communication, more precisely, business communication as a tool to capture underlying action patterns that represent the business processes. In this context, the notion of communication is not an exchange of information (words and sentences), but the negotiation, coordination, agreement, and commitment that lead to certain actions. In turn, these actions create new facts, deliver results, and accomplish the mission of an organization. This way of looking at communication became known as the Language-Action Perspective (Dietz, 1999; Goldkuhl, 2005; Goldkuhl, Lind, & Seigerroth, 1998). Thus, the Language-Action Perspective

Figure 1. Graphical notations of Petri nets

Place T Transition Arc (directed) Place with token

118

Business Process Modeling as a Blueprint for Enterprise Architecture

considers communication as a way of acting and carrying out certain tasks. Each business transaction encompasses action and interaction as illustrated in Figure 2. The action is the core of a business transaction; it represents an activity that changes the state of the world or creates a new fact. The interaction is either for initiation of an action or communication of a fact as the result of the action. For example, an interaction can be a request made by one actor toward another actor that leads to creation of a new fact; an interaction can be also click of apply button or submit in an electronic form; or inserting debit card into the ATMs card reader to withdraw cash. Example 1a: A customer applies for a home mortgage to a loan officer in a bank. The first interaction takes place when the customer communicates with the officer to request a loan and submits an application. Then the officer processes the application, checks the documents, and makes a decision, that is, takes an action. The second interaction takes place when the officer, after processing the application, communicates the decision to the customer.

place; these phases are abbreviated as O, E, and R correspondingly. They are also referred to as OER concept illustrated in Figure 3 using Petri net notations. The order (O) and result (R) phases are interactions and the execution (E) phase is an action. In order to distinguish between action and interaction, the action (execution phase) is represented by a different color. This differentiation makes more meaningful sense when conducting modeling. On the left side of Figure 3, a transaction is represented as a sequence of the three phases, while for compactness, the right side of the figure compresses the three phases into one box called a transaction (T). The need of decomposing a transaction into three phases or compressing them into one box arises when modeling complex enterprise processes, in which numerous transactions are chained together and nested into each other. A simple transaction is carried out in a straightforward manner without involving (triggering or causing) another transaction (or transactions) during its entire execution. Thus, it is unnecessary to split a simple transaction into three phases, and therefore a compact notation is used. Using the compressed notation will help to build more compact models of enterprise processes, while the expanded notation will help

As the mortgage example shows, the process has three stages: the first interaction, the action, and the second interaction. Accordingly, as illustrated in Figure 3, the transaction concept states that each business transaction consists of three phases called the order, execution, and result phases. The order phase is the first interaction, the result phase is the second interaction, and the execution phase is where the action takes

Figure 3. The transaction structure using Petri nets diagram (detailed and compact notations)

OER

Figure 2. The business transaction concept

Interaction

+
Action

Transaction

119

Business Process Modeling as a Blueprint for Enterprise Architecture

to show if a transaction is nesting other transaction(-s) within it. Example 1b: In the requesting mortgage transaction, the application processing triggers another transaction checking credit. In order for the officer to approve or decline the application, he or she needs to check the customers credit history with an authorized credit reporting agency. It means the requesting mortgage transaction is a composite transaction that nests the checking credit transaction. Thus, the requesting mortgage transaction starts first and the checking credit transaction starts afterward, but the requesting mortgage transaction cannot be completed until the result of the checking credit transaction is not known.

Executor: officer Result: mortgage is approved Transaction 2: checking credit Initiator: officer Executor: credit agency Result: credit report is generated From the two previous transactions, Transaction T2 must be initiated and executed during Transaction T1, as depicted in Figure 4. Thus, initiation, execution, or completion of a business transaction may lead to initiation and execution of new transactions. In this way, transactions are chained into arbitrarily large structures, called business processes (Dietz, 1999). The actual sequence of actions is shown Figure 4b. According to this diagram, the execution of Transaction 2 takes place as part of the execution phase of Transaction 1. This simple model should be read in the following manner: Transaction T1 starts with order phase (T1/O); the execution phase of this transaction (T1/E) nests Transaction T2, that is, the execution phase of Transaction T1 starts and then it triggers Transaction T2 that should be completely executed and the result should be

Based on the previously modified description of the mortgage process, the following is a business process model using the transaction concept: Transaction 1: requesting mortgage Initiator: customer

Figure 4. (a) A composite transaction; (b) A composite transaction indicating the action flow and process boundary

T1/O

T1/O

Bank
T2 T1/E T1/E T1/E T2

T1/R

T1/R

(a)

( b)

120

Business Process Modeling as a Blueprint for Enterprise Architecture

returned back to T1/E in order to complete T1/E. Once the result of Transaction T2 is returned and the execution phase of Transaction T1 (T1/E) is also completed, it proceeds to the result phase (T1/R). The result phase of Transaction T1 means that the mortgage decision is communicated to the customer. In real life, enterprise processes are more complex than the mortgage example that is intentionally simplified in order to evade an indepth discussion at this stage. Now that the transaction structure is explained, it is necessary to look at the roles of the actors involved in a business transaction. As is apparent from the mortgage example, each transaction involves two actors. The actor that initiates the transaction is called the initiator of the transaction (e.g., customer, client, consumer, submitter of electronic form), while the actor that executes the transaction is called the executor of the transaction (e.g., supplier, server, provider, IT application). Actors can be humans, software agents, or machines. For example, if the mortgage application is submitted online, a software agent will collect data and process the application instead of the loan officer and make preliminary estimates for later approval by a human actor (the loan officer). Now that the transaction concept is introduced, it is appropriate to give a definition of business transaction used in this chapter. Definition: A business transaction is a generic pattern of activity carried out in a close interaction between two distinct actors called the initiator and executor. The activity is carried out in three phases, called the order phase (O), execution phase (E), and result phase (R), that create a new fact or change the state of the world. These three phases are made up of interaction and action, in which the order and result phases represent the interaction and the execution phase represents the action.

The following is a definition of enterprise process in the framework of the methodology that is applied in this chapter based on the transaction concept. Definition: An enterprise business process is a network of interrelated business transactions that delivers value (good or service) to a customer having one start point and one end point. It starts with a request by an actor and ends with a result communicated to the same actor. Usually a business process is one super transaction that nests multiple transactions in it.

trAnsActIon-orIented PetrI nets

In order to use Petri nets for enterprise process modeling based on the language action perspective, a few minor extensions to the graphical notations of the standard Petri nets are suggested in this chapter. These extensions add important modeling features such as capabilities depicting process boundary, distinguishing between intraand inter-departmental, intra- and inter-organizational levels of interaction, and indicating the start and the end points of certain processes. These extensions make the models easily understandable, intuitively readable, and a straightforward input for further analysis, simulation, verification, or comparison of different model scenarios. As the notations in Table 1 illustrate, there are distinct graphical elements for action (rectangle with plain line filled in grey), interaction (rectangle with plain line), a complete transaction where action and interaction are represented together (rectangle with a bold line), and composite transaction where a transaction is nesting one or more transactions (multiple rectangles with a plain line). A transaction is called composite if its completion requires execution of another transaction(s). In terms of the Petri nets concept, all these elements

121

Business Process Modeling as a Blueprint for Enterprise Architecture

are transitions and thus represented by different types of rectangles. Further, the proposed extensions suggest two places, a start place and an end place that indicate where a process starts and where it eventually ends. These two new places are used along with the standard Petri nets element called state that shows the intermediate states of processes (transactions). Again, in terms of the Petri nets concept, all these elements are places and thus represented by different types of circle. For distinguishing between intra-organizational and inter-organizational processes, the process boundary element is added. Introduction of this element helps when analysts need to model or illustrate the interaction of one process with another process within an organization or with the environment. This interaction can be modeled with a set of places between the process boundaries. The final extension concerns the introduction of an optional link. In standard Petri nets, all input places must hold in order for a transition to be executed, that is, execution of a transition

is guaranteed only whenever all its input places have a token in them. Optional links weaken this assumption and therefore allow the analyst to represent situations where the transition is executed, even when a state represented by its input places does not hold. For instance, prior to applying for a policy, customers usually request a quote. However, it is entirely possible for customers to apply for a policy without first requesting a quote. Thus, the relationship between requesting a quote and applying for a policy is an optional one.

The TOP MeThOdOlOgy FraMewOrk

For a successful enterprise processes study, a practitioner needs to follow some formal framework (steps) that would help to determine where to look for pieces of essential or business related information. Since we are applying the TOP methodology, this methodology suggests that first an organization is described in terms of major business processes (order processing, customer

Table 1. Notations of the TOP methodology

122

Business Process Modeling as a Blueprint for Enterprise Architecture

call processing, inventory control, admission to hospital, new member enrollment, insurance claim processing, etc.). Then each of these major business processes is studied and described as a network of business transactions (essential activities), in which each transaction involves two actors, one initiator of the activity and one executor of it. According to the transaction concept, an activity is considered as a business transaction if it creates a new fact, changes the status of the system, or brings results. Now having this in mind, the following is a high-level framework to follow: Definition of major business processes: This step is a high-level definition of major processes that can be done by reading the documentation of an organization. Examples of a major process can be order processing, goods delivery, procurement, restocking, etc. Usually, these major processes are interrelated and all together constitute the mission of the organization. Description of each major business process: This step is either based on documentation of an organization where processes and procedures are described, or such a description can be prepared through interviews with the manager of a specific business process. Experience shows that even if a written documentation is available, interviews still need to be conducted for clarification and further information. Identification of business transactions (core activities or key processes) and relevant actors for each major business process: In this step, identify transactions (main activities) that cause changes in the states of the process and advance the process. Identify who is the initiator and who is the executor for each transaction. According to the transaction concept, the initiator and the executor are two distinct actors. Construction of model(s) of each major business process: In this step, using the

notations of the TOP methodology, all the identified transactions are put together in sequential order. These steps and the TOP methodology are applied and tested through a series of case studies. The following section will discuss one of these case examples.

APPlIcAtIon oF the toP Methodology

This section represents a case study conducted in a multinational insurance company identified by a fictitious name SSM Insurance company. As one of the worlds largest financial institutions, SSM currently includes approximately 80,200 employees and 17,000 agents servicing more than 70 million policies in the United States and Canada.

business Architecture of ssM

For the application of the TOP methodology to a specific business process, it is essential to first draw the big picture in the form of capturing the SSM Business Architecture that reflects essential major processes. The SSM Business Architecture comprises major business processes such as reviewing new applicants, generating contracts, reviewing claims, and reviewing current applicants, as depicted in Figure 5. By decomposing each of these major processes, it will reveal more detailed business activities in SSM. The SSM business architecture is an essential component or subset of the SSM enterprise architecture in general. Although enterprise business processes would be completely studied only if all the models are developed and the interactions between the models are identified and illustrated, in the following sections, we focus on the details of business processes relevant to a new policy issuance.

123

Business Process Modeling as a Blueprint for Enterprise Architecture

Figure 5. SSM business architecture

Reviewing New Applicatants Reviewing Claims Reviewing Current Applications
Business Architecture Scope: -WhatType of activities -WhoActor involved -WhichInformation -WhereVenue of activities

Major business Processes

As depicted in the SSM business architecture, the major business processes within SSM insurance excluding the agents are reviewing new applicants, generating contracts, reviewing claims, reviewing current applicants, and serving customers daily. The first two actually comprise the policy issuance process studied in the next subsection. The agent is a part of the insurance company in that they are the face of the company. They are the ones that directly and personally interact with customers.

description: Applying for Insurance Process

If a person wants SSM insurance company to be his or her insurance agency, he or she contacts an SSM insurance company agent. These agents then offer plans and the prices to best fit the person. The premium offered is based on the customers driving record (number of tickets and accidents), age, marital status, residence, car type, etc. Also, the premium is based on customer claims, which are obtained from a consumer reporting agency. If the person wishes to purchase the insurance, then an application may be filed with the insurance agent. The agent then sends the application to one of the regional offices. The regional office checks the background of the applicant. The background check consists of traffic tickets and claims made. Claims typically made are any type that have been requested by that customer in the past. Claims can

consist of auto claims and homeowner claims. If approved, the regional office notifies the agent and the agent tells the client that they are approved and a contract is generated. All contracts are pre-made by the system with added information about the customer and car. The contracts are produced at the regional office and sent to the customers agent who adds the type of coverage the customer has. The agent then explains what is and is not covered under the plan and asks the client to sign the contract. By signing the contract, the customer pays an initial payment to start the coverage when approved. The customer is issued a temporary insurance card, and the official card is mailed to the customer at a later date. If the client is not approved by the regional office, the agent notifies the client and all transactions between the client and agent end there. SSM insurance companys regional office does not deal with customers directly. The agents are the primary contact for customers.

Identification of Business transactions and Actors

Now, based on the description of the business process in regard to the policy issuance, business transactions and their relevant actors are identified using the transaction concept. As mentioned, each business transaction should have two distinct actors and create a new result or fact. Following this concept, the first business transaction can be identified as obtaining a quote or requesting a quote.

124

Business Process Modeling as a Blueprint for Enterprise Architecture

T1: Requesting for a quote Initiator: customer Executor: agent Result: a quote is given After completion of this transaction, the customer may decline or consider applying for an insurance policy. If the customer decides to apply for a policy, this will constitute the second transaction: T2: Applying for a policy Initiator: customer Executor: agent Result: a policy is issued In order for the agent to proceed, the agent must request approval of the regional office, which checks the customers background: T3: Requesting regional approval Initiator: agent Executor: regional office Result: approved/declined If the approval is given, the agent asks the regional office to generate a contract based on the inputs of the customer: T4: Generating a contract Initiator: agent Executor: regional office Result: a contract is generated Now the agent reviews and explains the prepared contract to the customer (agent and customer). If the customer agrees to the terms and conditions of the contract, the agent requests the customer to sign the contract and make the initial payment: T5: Paying for the policy Initiator: agent

Executor: customer Result: policy is paid

developing an enterprise Process Model of ssM Insurance

After having all the business transactions identified, the TOP graphical elements are applied to construct an enterprise process model based on the identified transactions by first grouping and drawing the boundary of the two departments, the agent office and the regional office. Second, transactions that are executed with the agents office, regional office, and environment are grouped. Figure 6 shows all the transactions in sequential order and their relation in regard to the organizations boundaries. In the Figure 6, the organization boundary is represented by the thick gray rectangle with rounded angles (e.g., agent office, regional office). The figure should be read in the following manner: The two circles with black dots (tokens) represent the start point; correspondingly, the two circles with the holes represent the end point of the processes, where the processes terminate. Transaction T1 starts in the environment and the result is also communicated to the environment. This is a simple transaction and is, therefore, executed completely at once. Its result can serve as a conditional link for the initiation of Transaction T2; therefore, the dotted arrow connects the result of transaction T1 to Transaction T2; therefore, a dotted arrow is drawn between T1 and T2. Now, Transaction T2 is a composite transaction that nests Transactions T3, T4, and T5; therefore, this transaction is split into three phases showing that for the completion of Transaction T2, Transactions T3, T4, and T5 are initiated and should be completed before proceeding with Transaction T2. As for Transactions T3 and T4, they are initiated in the agent office, executed in the regional office, and the results are communicated back to the agent office. Transaction T5, payment for the policy, is

125

Business Process Modeling as a Blueprint for Enterprise Architecture

Figure 6. Transactional model of policy issuing process

T2/O

T1

T3 T2/E

T5

T4

Environment

Agent office

T2/R

Regional office

initiated in the agent office, executed in the environment, and the result is communicated back to the agent office. Finally, the circles positioned between the agent office and the regional office models intra-organizational processes. One more aspect of the Figure 6 is the distinction between intra-organizational and inter-organizational processes. For example, Transactions T3 and T4 are inter-organizational processes. In this case, the actors involved are not persons but rather organizations; however, detailed discussion of this matter will be left for a future opportunity. In Figure 6, focus is placed on the insurance policy issuance process; therefore, the other processes such as reviewing claims and reviewing current members are not discussed; however, their analysis and modeling should not be difficult following the same manner as with the policy issuance process.

back to business Architecture and eA Framework

The studied example and the methodology illustrate how enterprise processes can be modeled for incorporation into the EA development process. Although the studied example is only one of the few major business processes of SSM, for real projects, the ultimate goal should be the development of a series of such models that capture all essential processes that support the mission of an enterprise. Next to the modeling part, it should be studied how to align the process models to the supporting IT components or how to build a one-to-one accordance between the business processes and IT functionalities. In concluding the chapter, it should be stated that a strategic factor in the success of enterprise architecture is the degree to which the enterprise architecture is based and linked to business re-

126

Business Process Modeling as a Blueprint for Enterprise Architecture

quirements, and demonstrably supporting and facilitating the enterprise to achieve its business objectives.

reFerences
Anaya, V., & Ortiz, A. (2005). How enterprise architectures can support integration. In Proceedings of the 1st International Workshop on Interoperability of Heterogeneous Information systems. Austin, J. L. (1962). How to do things with words. Cambridge, MA: Harvard University Press. Carr, N. G. (2003). IT doesnt matter. Harvard Business Review, 81(5). Dalal, N. P., Kamath, M., Kolarik, W. J., & Sivaraman, E. (2004). Toward an integrated framework for modeling enterprise processes. Communications of the ACM, 47(3). Deiters, W. (1998). Information gathering and process modeling in a Petri net-based approach. In W. van der Aalst, J. Desel, & A. Oberweis (Eds.), Business process management: Models, techniques, and empirical studies. Berlin; Heidelberg; New York: Springer-Verlag. Dietz, J. L. G. (1994). Business modeling for business redesign. In Proceedings of the 27th Hawaii International Conference on System Sciences (pp. 723-732). Los Alamitos; IEEE Computer Society Press. Dietz, J. L. G. (1999, November). Understanding and modelling business processes with DEMO. In Proceedings of the Annual International Conference on Conceptual Modelling (ER99), Paris. Dietz, J. L. G. (2002). The atoms, molecules, and matter of organizations. In Proceedings of the 7th International Workshop on the LAP, Delft, The Netherlands. Dietz, J. L. G. (2006). Enterprise ontologyTheory and methodology. Springer.

conclusIon
This chapter discussed both the role of business architecture as a subset of enterprise architecture framework and business processes as the foundation of business architecture. The discussion opened with consideration of enterprise process modeling as a crucial component in developing adequate enterprise architecture. In order to study, model, and visualize enterprise processes, the chapter introduced a comprehensive methodology based on language action perspective. The applicability of the methodology is tested on a small case study demonstrating that enterprise processes are cross departmental and cross organizational by nature. Although more complex examples and case studies are needed to explore the full benefit of process modeling in developing detailed enterprise architecture, it is not difficult to draw some conclusions based on the enterprise case study discussed. Enterprise processes are cross departmental with interaction with the business environment. Transactions exchanged between different actors may cross boundaries of a single process and expect results from other processes. Thus, enterprise processes are truly a collaborative network of business transactions. Revelation of these characteristics of enterprise processes greatly help system designers, especially enterprise architectures, to define the boundaries and underlying IT infrastructure more precisely in order to support the enterprise processes. Therefore, definition of enterprise processes may serve as a blueprint in developing enterprise architecture.

127

Business Process Modeling as a Blueprint for Enterprise Architecture

Goldkuhl, G. (2005, June). Beyond communication loopsArticulating the principle of multiresponsiveness. In Proceedings of the 10th International Working Conference on the Language Action Perspective on Communication Modeling. Kiruna, Sweden. Goldkuhl, G., Lind, M., & Seigerroth, U. (1998). The language action perspective on communication modelling. In Proceedings of the 3rd International Workshop on LAP, Department of Informatics, Jnkping International Business School, Sweden. Haas, P. (2002). Stochastic Petri nets: Modelling, stability, simulation. New York: SpringerVerlag. Habermas, J. (1984). The theory of communicative action: Reason and rationalization of society. Cambridge: Polity Press. Herman, J. (2001). Creating a business architecture. Business Communication Review, 22-23, December. Jensen, K. (1997a). Coloured Petri nets. Basic concepts, analysis methods and practical use. Volume 1, Basic Concepts. Monographs in Theoretical Computer Science, Springer-Verlag, 2nd ed. ISBN: 3-540-60943-1. Jensen, K. (1997b). Coloured Petri nets. Basic concepts, analysis methods and practical use. Volume 2, Analysis Methods. Monographs in Theoretical Computer Science, Springer-Verlag, 2nd ed. ISBN: 3-540-58276-2. Lopez, J., & Genovese, Y. (2004). Shift to integrated business architecture. Gartner, Inc.

McDavid, D. W. (1999). A standard for business architecture description. IBM Systems Journal, 38(1), 12. Medina-Mora, R., Winograd, T., Flores, R., & Flores, F. (1992). The action workflow approach to workflow management technology. In J. Turner, & R. Kraut (Eds.), In Proceedings of the Conference on Computer-Supported Cooperative Work, CSCW92. New York: ACM Press Peterson, J. L. (1981) Petri net theory and the modelling of systems. Englewood Cliffs, NJ: Prentice-Hall, Inc.. Reisig, W., & Rozenberg, G. (1998). Lectures on Petri nets I: Basic models. Advances in Petri Nets, Lecture Notes in Computer Science, Vol. 1491. Springer-Verlag. Searle, J. (1969). Speech acts: An essay in the philosophy of language. Cambridge: Cambridge University Press. Stamper, R. K. (1988). MEASUR. University of Twente, Enschede, The Netherlands. Stamper, R. K. (1997). Organizational semiotics. In J. Mingers, & F. Stowell (Eds.), Information systems: An emerging discipline. London: McGraw Hill. Taft, D. K. (1996, October). Anderson sets enterprise blueprint. Computer Reseller News, October 28, p. 132. van der Aalst, W., & van Hee, K. (2002). Workflow management: Models, methods, and systems. MIT Press. Winograd, T., & Flores, F. (1986). Understanding computers and cognition: A new foundation for design. Ablex, Norwood.

128

129

Enterprise Architecture in the Singapore Government

Tan Eng Pheng Infocomm Development Authority of Singapore, Singapore Gan Wei Boon Infocomm Development Authority of Singapore, Singapore

Chapter VII

ABSTRACT
The Singapore government enterprise architecture is a blueprint that will provide a holistic view of business functions, supporting data standards, and IT systems and services, regardless of the organisational structure and ownership of these functions and systems. The blueprint will also enable analysis of IT investments and their alignment to business functions, as well as facilitate collaboration among government agencies. When implemented, the Singapore government enterprise architecture will help bring about transformation in public sector by yielding optimised end-to-end business processes and system capabilities in alignment with government enterprise needs and missions.This chapter presents the considerations and approach taken to develop the Singapore government enterprise architecture. It examines the linkages of enterprise architecture with other initiatives such as the e-government action plans, policies, and processes related to IT governance, as well as summaries of lessons learned.

INTRODUCTION
The Singapore government enterprise architecture is a blueprint that will provide a holistic view of business functions, supporting data standards, and information technology (IT) systems and services, regardless of the organisational structure

and ownership of these functions and systems. It comprises four elements and reference models for the business, information, solution, and technical architectures. Of the four elements, the technical architecture has been developed in 2002 while the other three are currently being developed.

Copyright 2007, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited.

Enterprise Architecture in the Singapore Government

The Singapore government enterprise architecture is to support e-government, and in particular, realise the outcomes of networked government where many agencies integrate across organisational boundaries to provide citizencentric services.

SINGAPORE E-GOVERNMENT
E-government is about enabling our government to harness info-communications technology (ICT) to better serve our citizens and businesses, and to deliver public services with greater convenience, effectiveness, and efficiency. For the Singapore public service, our e-government journey started in 1980 with the launch of the Civil Service Computerisation Programme.

the public sector in the delivery of public services by harnessing ICT technology. Launched in June 2000, the vision of the first eGAP was to be a leading e-government to better serve Singapore and Singaporeans in the new knowledge-based economy. The objective was to foster a shared vision of a leading e-government in the new millennium, develop a public sector that could contribute positively and work actively at propelling Singapore forward in the new economy, and provide a framework for informed, coordinated, and flexible ICT deployment. To move businesses, citizens, public officers, and the government toward the e-government vision, the first eGAP prescribed the broad directions of ICT deployment with five strategic thrusts and six programmes. The five strategic thrusts of the first eGAP were: 1. 2. Re-inventing government in the digital economy. Delivering integrated electronic service delivery. Being proactive and responsive. Using infocomm technologies to build new capabilities and capacities. Innovating with infocomm technologies.

1980-1999: Civil Service Computerisation Programme (CSCP)

The Civil Service Computerisation Programme (CSCP) was conceived with a clear direction of turning the Singapore government into a worldclass exploiter of IT. It marked the beginning of computerisation in the Singapore public sector that focused on improving internal operational efficiencies through the automation of traditional work functions and reducing paperwork. In the 20-year period, we evolved from using IT as a tool to improve productivity to leveraging the Internet to deliver 247 electronic services to our customers. By the late 1990s, the convergence of IT and telecommunications transformed the concept of service delivery. This required a paradigm shift in the way government services were delivered and the first e-government action plan was born.

3. 4. 5.

The six programmes identified to drive the strategic thrusts in the first eGAP include: 1. 2. 3. 4. 5. 6. Knowledge-based workplace. Electronic services delivery. Technology experimentation. Operational efficiency improvement. Adaptive and robust infocomm infrastructure. Infocomm education.

2000-2003: E-Government Action Plan I (eGAP I)

The e-government action plan (eGAP) is the primary vehicle for a strategic transformation of

The key focus of the first eGAP was transforming the way the public sector interacts with its customers. Primarily, all public services deemed feasible for electronic delivery were designated for this transformation. The public sector would

130

Enterprise Architecture in the Singapore Government

need to better understand the impact of ICT, continually innovating and adapting business and operational processes to re-engineer, and totally transform the way things were done. In line with Singapores vision for service excellence, this plan would see an increase in the number of electronic services or e-service provisions to customers in three frontscitizens, businesses, and within the public service. The first eGAP covered the period 2000 to 2003. By the time it concluded in 2003, its achievements and accolades include the following: 1. One of the most advanced e-governments in the world as reflected in international benchmark studies by third parties. Singapore was ranked among the top leading e-governments by both accenture and the world economic forum, and also won several international e-government awards. Over 1,600 public e-services have been implemented. In a study of e-governments

3.

worldwide, Singapore was ranked second by Brown University at putting public services and information online. Our citizens are generally satisfied with e-government and with the quality of our e-services.

2.

While the first eGAP had provided the common vision for agencies in their ICT deployment, it was important to continue to engage all agencies in the conceptualisation and implementation of common systems, especially with gradual decentralisation of budgets as well as ICT deployment decisions to these agencies. Continual efforts would have to be put in to encourage and ensure that agencies pool their resources in the development of ICT applications with similar functionalities. Such engagement and customer-centric approach to delivering public services from the foundation laid by first eGAP would continue into the second eGAP.

Figure 1. E-government action plan II (2002-2006) outcomes

E-Government Strategic Framework

Strategies To Realise The Vision et Outcomes
Delighted Customers e-Services Advantage Increasing awareness of et convenient access to e-services Improving the e-service experience Connected Citizens Supporting Active Citzenry Engaging Citizens through Active Consultation et Virtual Communities

Networked Government
Fostering Inter-Agency Collaboration

131

Enterprise Architecture in the Singapore Government

2003-2006: E-Government Action Plan II (eGAP II)

The focus of the e-government action plan II (GAP II) covering 2003 to 2006 was to transform the public service into a networked government that delivers accessible, integrated, and value-adding e-services to our customers and helps bring citizens closer together. The eGAP II was to achieve three distinct outcomes: (1) Delighted customers, (2) Connected citizens, and (3) Networked government as shown in Figure 1. To enable the two desired outcomes of delighted customers and connected citizens in e-GAP II, the networked government outcome must first be realised. A networked government is one where our many agencies move beyond seeing themselves as separate and distinct entities to one government. That is, one that collaborates, shares information, and leverages on its collective knowledge enabled by infocomm, to serve the public seamlessly and effectively. E-governments contribution toward building a networked government is in the interconnection of our government agencies through common infrastructure, information management, and technical standards, as well as collaborative undertakings to deliver citizen-centric services. At the close of eGAP II in 2006, at least 10 new cross-agency integrated e-services were implemented, and improvements were made to customers e-service experience and their ease-ofuse. Some of the significant initiatives were: (1) an enhanced My.eCitizen personalised front-end for the eCitizen portal, (2) the TrustSg accreditation scheme for government Web sites to help instil customer confidence in online transactions, (3) the installation of over 1,200 self-service internet terminals across 150 public service locations so as to increase accessibility, and (4) the publicity campaigns to raise awareness and reward citizens who transacted electronically with the government.

Our efforts in implementing e-services have been recognised internationally as well. Notably, we received the United Nations Public Service Award 2005 for the Online Business Licensing Service (www.business.gov.sg), an integrated e-service, which offers businesses a total of 69 licenses from 19 government agencies and allows 80% of all start-ups in Singapore to apply online for the licenses needed to start their businesses. The award was given to recognise the governments efforts to streamline, simplify, and integrate the application of licences from various agencies to save time and costs for enterprises. Overall, we have continued to do reasonably well for eGAP II and our achievements have ensured that Singapore continues to be ranked amongst the leading e-governments by international benchmarking studies conducted by the World Economic Forum, Accenture, and United Nations e-government survey.

TECHNICAL ARCHITECTURE EARLY ENTERPRISE ARCHITECTURE

When the Singapore government embarked on eGAP, it became apparent that we needed a welldesigned, reliable, and scalable infrastructure to support our e-government initiatives. In addition, the public sector needed a coherent collection of policies, standards, and guidelines to guide government agencies in the design, acquisition, implementation, and management of ICT. This was particularly so at a time when the rapid convergence of telecommunications, broadcasting, and information technology had opened up possibilities for a networked government. Until then, architecture development had only been done at intra-agency level at some agencies. With the push toward the delivery of e-services for citizens and businesses and emergence of cross-agency integrated e-services, systems interoperability and the bridging of systems

132

Enterprise Architecture in the Singapore Government

platforms across agencies became paramount. Moreover, cost benefits could be realised through the use of common systems and platforms for the deployment of e-services, and demand aggregation for the procurement of compatible technology products. Hence, a practical approach by way of a public sector service-wide technology standard for agencies was necessary. This technology standard blueprint called the service-wide technical architecture (SWTA) was developed to provide a consistent framework for the effective management and protection of the public sectors IT assets that were implemented across the agencies. According to META Group (1999b), the development of such a technical architecture still offered the greatest opportunity for IT organisations to deliver prompt value to their business.

The SWTA, which was one of the key initiatives under the first eGAP, helped to create a better environment for interoperability and information sharing within the public service. The first five domain architectures in SWTA were published in October 2002. By April 2003, a total of nine domain architectures, as shown in Figure 2, were developed and published.

REVIEWS ON GOVERNMENT ENTERPRISE ARCHITECTURE

Achieving a networked government does not stop at just putting in place one of the technical enablersviz technical architecture. The next step of development for ICT standards and

Figure 2. Architecture domains in service-wide technical architecture (SWTA)

Application

Internet & Intranet

Data Management

Middleware

Platfo (Clien t)

rm (S

erver)

nmen nviro uted E ment ib ge Distr Mana

Collaboration & Workflow

Security

133

Enterprise Architecture in the Singapore Government

architectures was to explore the development of enterprise architecture. This programme, identified in eGAP II, would increase cross-agency collaboration and systems integration, enable more innovative and business-transforming projects to be initiated and completed, and improve the public services ability to anticipate and respond to rapid changes in the technology landscape when successfully executed. Reviews were conducted to glean insights into enterprise architecture practices, their implementation at a government-wide level, and the approaches taken by other e-governments. Some of the key findings are summarised next starting from enterprise architecture components and concepts, and expanding into their implementations in other countries. 1. Enterprise architecture would comprise four elements, namely the business, information or data, solution or application, and technical architectures according to META Group (1999a, 1999b), U.S. CIO Council (1999) and the Open Group (2002). An architectural framework provided a logical structure for classification and organisation of the four architecture elements, as well as guidance for developing architecture and systems implementation. TOGAF and Zachman were some of the frameworks reviewed. The open group architectural framework or TOGAF, originally used for developing technical architectures, was enhanced in the current version to develop other enterprise architectures elements as well. TOGAFs strength would be its architecture development method, a generic process consisting of eight phases for developing architecture (Open Group, 2002). The Zachman framework consisted of a two-dimensional matrix classification scheme in six columns (by what, how, where, who, when, and why) and five rows (by plan-

3.

4.

2.

ner, owner, designer, builder, and contractor perspectives) for describing an enterprise appears comprehensive (Zachman, 1997). However, the Zachman framework did not have a process for developing an enterprise architecture, and the completion of such a matrix, either partially or full, for the wholeof-government seemed daunting. In a government environment, enterprise architecture was deemed to be applicable at both government-wide and agency levels. Although both enterprise architecture implementations were conceptually similar, the construct was more complex in a government-wide context due to the scale and range of functions and diversity of the environment. Government-wide enterprise architecture provides a service-wide perspective of business functions and their IT initiatives. In this context, the Canadian and U.S. Federal Governments have published reference models. The enterprise architecture effort in Canada comprises the business transformation enablement program and the governments of Canada strategic reference models, which had evolved over the last 15 years from the municipal level governments reference model called the public service reference model to the provincial level government 10 years ago (Canada Treasury Board Secretariat, 2004). In the United States, the federal enterprise architecture reference model framework comprised the performance, business, service component, data, and technical reference models. These five reference models provided a classification scheme for government business operations and IT assets, and enabled the U.S. Federal Governments identification of collaboration opportunities and initiatives within five lines of business. In addition, it also facilitated the analysis of IT budgets and investments (U.S. Government Accountability Office, 2004;

134

Enterprise Architecture in the Singapore Government

5.

U.S. Office of Management and Budget, 2005). It was also noted that the deliverables, documentation, and approaches for enterprise architecture were varied. Carbone (2004) had described that existing enterprise architecture approaches were too complex and theoretical and had proposed a simpler and improvised approach, such as the use of the Gane/Sarson methodology for diagramming. Whittle and Myrick (2005) asserted that formal models and architectures were virtually nonexistent for business enterprises and highlighted several models to describe a business architecture enterprise. Lastly, Perks and Beveridge (2002) had

articulated the well-established processcentric TOGAF phases with clearer descriptions and details for practitioners use. These reviews from authors-practitioners showed that enterprise architecture deliverables and approaches needed to be fit for purpose intended and required customisation. Hence, the Singapore government would adopt a federated architecture approach similar to the United States government. Reference models would need to be developed to serve as the wholeof-government enterprise architecture framework, with a suitable methodology and/or process as part of the framework to provide the guidance for architectural development. These reference models would enable new initiatives and projects

Figure 3. Elements of Singapore government enterprise architecture

135

Enterprise Architecture in the Singapore Government

on common business functions and IT assets to be identified. The architectural documentation requirements would require continual research and localisation.

4.

delivery in a systematic and well-disciplined manner. Technical architecture: This element details the organisations technology strategies, its extended technology linkages, and their impact on business initiatives.

SINGAPORE GOVERNMENT ENTERPRISE ARCHITECTURE Elements of Singapore Government Enterprise Architecture

The Singapore government enterprise architecture (SGEA) programme was established to support and enable the business strategies, objectives, and vision of a networked government. Under this programme, a set of blueprints would be developed to provide a government-wide perspective of business functions, supporting data standards and ICT systems and services, regardless of the organisational structure and ownership of these functions and systems as shown in Figure 3 and descriptions next. 1. Business architecture: A holistic view of the organisations key strategies and their impact on business. The contents define the lines of business and business functions performed by Singapore government agencies, as well as the grouping of common business processes. Information architecture: A set of data models that examine the key information assets of Singapore government agencies with the aim of providing a shared, distributed, and consistent data resource. It also identifies individual responsibilities for managing information. Solution architecture: A portfolio of integrated application systems required to satisfy business information needs and solutions, which facilitate rapid development and

Our Approach
Out of the four elements in SGEA, only the business, information, and solution architectures would need to be developed as the technical architecture element was already addressed by the SWTA. The development of these EA elements would require substantial time and resource, and the same for its maintenance as well. Some of the key considerations underpinning the formulation of the strategy for the SGEA programme are as follows: The implementation of a government-wide EA would enable the identification of common business processes to be streamlined, duplicative systems to be consolidated, and common systems to be implemented, leading to overall efficiency and effectiveness. The Singapore government had previously implemented several service-wide initiatives, which effectively constitute components of an EA. In developing the three remaining elements in SGEA, the strategy would be to leverage on these existing initiatives rather than start from scratch. There was a need for early results to demonstrate value and relevance of enterprise architecture to all stakeholders. Hence, the EA deliverables were intended to be purpose-driven, focusing on usefulness and relevance rather than comprehensiveness. Lastly, the implementation of SGEA would be a means to effect business transformation in the Singapore public sector.

2.

3.

136

Enterprise Architecture in the Singapore Government

Government Business Architecture

The government business architecture (BA) was the first amongst three elements that we embarked on in the development of SGEA. The government BA was the key element in the SGEA, as it influenced the development of the other EA elements. The government BA, however, was also the most complex element. First, unlike most organisations whose core businesses were clearer and more instinctive, there was voluminous information to be analysed due to the diversity of government business and absence of a singular set of overarching whole-ofgovernment business objectives and performance measures. Second, there was no government-wide view of the lines of business and business functions. It was not practical to achieve a business architecture, which encompasses all business processes across the government either. The government BA to be developed would be comprised of a high-level representation of

government-wide lines of businesses and business functions. This would be sufficient to methodically identify agency collaboration opportunities or determine the need for common service-wide initiatives. A top-down whole-of-government and business-driven approach was preferred for the development of government BA. Executive sponsorship and strong participation of business personnel was key to the success of the government BA effort. The stakeholders included chief information officers and corporate planning and strategic planning directors who were engaged for their directions throughout the BA development process. Their inputs and information on the business functions and agency level priorities were analysed and integrated into the government BA. This enabled government leaders to focus on priority areas instead of being overwhelmed by the voluminous information available. The information for government BA was compiled into a structured format called the Singapore

Figure 4. Singapore government business reference model

Legal & Judicial Activities

Urban Planning, Intra Dev, Public Facilities & Housing

Community Development

Monetary Controls & Public Funds Management

Economic Development

Crime Prevention & Protection

International & Trade Relations

Emergency & Crisis Management

Family Development

Homeland Security

National Defense

Culture &Recreation

Energy Management

Environmental Mangement

Regulary Compliance & Enforcement

Financial Assistance

Monetary Collection

Workforce Management

Information Mangement & Consulting

Research & Development

Asset Management

Project & Logistics Management

Administrative Services

Corporate Planning & Development

Information Technology Management

Public Communications

Policy Development, Planning & Management

Professional Services

Finance

Human Resource

Transportation

Education

Health

137

Enterprise Architecture in the Singapore Government

government business reference model, which defined the business operations of the government using terminologies that were common across all government agencies as shown in Figure 4 diagram and described next. 1. The business reference model in Figure 4 has two broad categories of lines of businesses. Under the services to public category are 24 lines of businesses, which are external facing services that the Singapore government provides to citizens, businesses, and external stakeholders. Examples of these include the family development, public transportation, and revenue collection lines of businesses. Under the corporate & supporting services category are nine lines of businesses representing all activities that support the delivery of services provided by the Singapore government to the public and all activities to operate the government effectively. Examples of these include project & logistics management, human resources, finance etc. Within each line of business are a set of related business functions and descriptions. For instance, continuing education & training and primary and secondary education are two business functions under the education line of business. In addition, the business reference model would also include a set of cross-functional matrix of business functions performed by government agencies.

streamlining opportunities, resulting in generic business processes for use across the government or within a sector. The generic business processes and related information will then be incorporated as part of the desired future state (i.e., target architectures).

Government Information Architecture

The government information architecture (IA)the second element to be developed in SGEAfocuses on the effective and efficient sharing of information among agencies and supports the business functions identified in the government BA. Essentially, service-wide data standards would be developed to form a data reference model (Gartner, 2005). These efforts would be accompanied by the development of relevant data administration policy to establish proper accountability for the data as this would especially be crucial to address the privacy issue and protection of sensitive data. To facilitate seamless sharing of data across the public sector, an information exchange framework to standardise data definitions of commonly used structured data across government would be developed and would leverage on existing initiatives such as the data hubs. Additional data definitions would be added into the information exchange framework from new initiatives identified in the government BA exercise. In the development of DRM, the guiding principles used in defining data elements covered the following: (a) national and international standards, (b) data definitions in the existing data hubs, and (c) other standardised data definitions. When completed, the DRM content would consist of at least the data definition as follows: 1. 2. 3. 4. Data element name; Description; Format; Allowed values or validation rules;

2.

3.

The Singapore government business reference model will be used to identify business functions that: (a) are resource-intensive or (b) are potential candidates for inter-agency collaboration. Each common business function within could comprise business processes with the potential for streamlining. The identification of such common business processes would facilitate optimisation and

138

Enterprise Architecture in the Singapore Government

5. 6. 7.

Special values; Data element owner; and Usage guidelines.

At the point of writing, the focus for the DRM was on the data elements in the existing three data hubspeople hub, business hub, and land hub. At present, the three data hubs have mechanisms established to facilitate the sharing of commonly used people, land, and businesses-related data. The people hub is a centralized database on common non-sensitive people data (e.g., contains unique identification number (UIN) for all Singapore citizens and residents). The land hub is a one-stop resource centre for comprehensive and accurate digitised land data in map and textual forms. The fundamental land base information includes buildings, roads, and cadastral data, which are the basic land information that are required in the development of most map-based systems. The business hub is a centralized database containing a comprehensive range of information pertaining

to businesses in Singapore. The types of business data captured include company/business identification number and particulars, company/business profile, name history, capital, and shareholders share details. The initial DRM is planned for release in 2006. The envisioned seamless information exchange between data owners, government agencies, and the public resulting from the use of the DRM and implementation of government IA is depicted in Figure 5.

Government Solution Architecture

The third element that needs to be developed is the government solution architecture (SA), which focuses on the ICT solutions and the systems and services required to address the needs of the government BA and IA. The core deliverables for government SA would be a portfolio of service-wide and/or sectorwide systems and services. These will be shared

Figure 5. Implementation of government IA

Government Agencies Industry & Business MetaData Registry Systems

E-Services Data Source Individual Data Owners

139

Enterprise Architecture in the Singapore Government

systems and services identified from collaboration opportunities and common business processes drawn from the government BA and existing ICT systems consolidated and implemented as shared components, which are reusable by agencies. Cost savings can then be better realised through such consolidation and standardization efforts. At the point of writing, the government SA was at the stage of development. The government SA is targeted for implementation from 2007-2010 and would cover several public facing services as well as corporate and supporting services.

Government Technical Architecture

The service-wide technical architecture (SWTA) implemented in 2002 fulfils the role of a government technical architecture (TA). It has achieved inter-operability for systems in the government and was implemented for very practical reasons. The SWTA is a logically consistent set of principles, standards, and guidelines that guide the public sector agencies in the design, acquisition, implementation, and management of ICT. This common set of principles and standards

provides a semantic framework for information sharing and interoperability of systems amongst all agencies. A review process is carried out every half-yearly with agencies to ensure the currency of SWTA and its relevance to enterprise architecture development. The SWTA architectural principles are highlevel statements that describe preferred practices followed in the design and deployment of ICT in the public sector. The principles covered the following: (a) infrastructure reuse, (b) modular architecture, (c) open standards, (d) robustness, scalability, adaptiveness, and performance. The SWTA framework consists of domain architectures, which are logical groups of related technologies. The content of each domain architecture includes: 1. 2. Technology components: Description of relevant technology components. Technology standards: International and industry standards that apply to the technology components selected and their status in terms of technology maturity. Products: These are specific products in this domain.

3.

Figure 6. SWTA domain architecture and technology components

140

Enterprise Architecture in the Singapore Government

4.

5.

6.

7.

Interoperability standards: The standards and requirements that are mandatory for inter-agency interoperability. Central services: Government-wide services that have been implemented and may be leveraged in this domain. Best practices: Guidelines or practical advice based on the experience and research of project teams for implementing specific domain technology components or products. Technology watch: Promising technologies that warrant further research and analysis for purpose of the domain.

(f) middleware, (g) platform, (h) network, and (i) security. A diagram showing the nine SWTA domain architectures within is given in Figure 6.

Key Learning Points

Some of the key learning points over the last 12 months of our enterprise architecture journey are: EA development takes time and money. The first step is to get stakeholder buy-in, and senior leadership support is critical. There is a need to communicate to stakeholders the value of EA, particularly in relation to organisational goals and strategies. Effective communication means communication of outcome. For senior management and business owners, visual models should

There are nine domain architectures and these include: (a) application, (b) collaboration and workflow, (c) data management, (d) distributed environment management, (e) internet/intranet,

Figure 7. ICT governance framework in the Singapore government

IM 8
RISK BUSINESS NT MANAGEME (BCP, DRP)

ess oc e Pr hangIT C nd ing y a nn log Pla hodo et M

MA SECU NA RIT GE Y ME NT

RCE OU ING RES NN PLA C GI TE G RA IN ST ANN PL

lu Va tal dy To Stu
UE AL L V TION TA TO LUA EVA

COBIT

AUDITING
S SYSTEM Y UIT CONTIN ENT ASSESSM
PROCUREMENT / BESTSOURCIN G MANAGEMENT

Project s Review ks Framewor

CT G OJE PR EWIN VI RE

M CH AN A A N GE GE M EN T

CT T RA EN NT EM CO AG AN T JEC NT PRO EME G NA

UCTURE INFRASTR ENT MANAGEM

MA

ITIL
CMMI

SERV ICE S UPPO /D EV RT MAN LIVERY AGE MEN T

APPLICATION MANAGEME NT

IO GC PM S QMKey s ces Pro

IM

141

Enterprise Architecture in the Singapore Government

be used to help them understand EA better and focus on showing the outcome. It is necessary to leave the technical blueprints in the boiler room. Work on some easier areas that will meet less resistance from business owners to demonstrate quick wins and successes. EA is developed iteratively and evolves over time. Look at common areas and pick out three priority areas to focus on. Good governance is critical to the EA programme. The governance structure of an EA programme typically involves many stakeholder and working level committees. Leverage on existing committees and structures, where possible. Integrate EA into established forums for IT Governance within the organisation, if possible.

ICT deployment, and describes the positioning of the governance pieces as shown in Figure 7. The framework adopts a lifecycle approach positioning IT governance needs and concerns around the agencys long term IT vision. The tools, policies, and methodologies are also positioned in the overview so that agencies can understand how these aids can help them. It is structured as a three concentric-layered onion with the IT vision of the agency in the centre: 1. 2. The first layer consists of the four-lifecycle stages of plan, invest, deploy, and control. The second layer breaks this down into processes that an agency should consider for each stage. The third layer identifies the policies, methodologies, and tools that best serve the agency in addressing the processes.

3.

GOVERNANCE FOR ENTERPRISE ARCHITECTURE

Over the past few years, the Singapore public sector has been actively seeking improvements in IT governance. The Singapore government instruction manual on information technology or IM8, a comprehensive set of guiding policies that spells out the requirements for agency compliance on IT matters, is in place. The Singapore government recognises that the public sector will need to continue to work collectively to ensure investment in IT generates the best possible benefits. As one of the largest spenders on IT in Singapore, the public sector will need to invest wisely to deliver optimal results from public funds. It is important to enhance IT management and governance capabilities servicewide and leverage on common architectures and shared infrastructures to promote cross-agency collaboration and optimise resource allocation. The integrated ICT Governance framework in the pipeline is to provide a logical and holistic overview of the work involved in the public sectors

This framework helps chief information officers and IT managers to first understand the considerations necessary to achieve IT effectiveness. It then directs their attention toward the tools and policies that address the individual considerations. The agency starts in the plan stage of the framework and examines and establishes the alignment of ICT and business goals through strategic planning and other processes including enterprise architecture. All of these processes require long-term mapping and need to be done at the beginning stage of the lifecycle. With the plan for the next few years in place, the agency then moves to the invest, deploy, and control stages for its IT investments where there are other tools like IT portfolio management and risk management methodology to provide guidance. The positioning of enterprise architecture within this framework, which according to SloanMIT Research, form part of the IT governance equation (Weill & Ross, 2004). This will help agencies to better align IT