Model-Driven Business Process Engineering [1 ed.] 9781608058921, 9781608058938

Citation preview

Model-Driven Business Process Engineering Edited By

Kevin Lano Department of Informatics King's College London UK

Ravinder Singh Zandu Department of Informatics King's College London UK &

Krikor Maroukian Department of Informatics King's College London and Printec Group Greece

Bentham Science Publishers Ltd. Executive Suite Y - 2 PO Box 7917, Saif Zone Sharjah, U.A.E. [email protected] All rights reserved-© 2014 Bentham Science Publishers Ltd. Please read this license agreement carefully before using this eBook. Your use of this eBook/chapter constitutes your agreement to the terms and conditions set forth in this License Agreement. This work is protected under copyright by Bentham Science Publishers Ltd. to grant the user of this eBook/chapter, a non-exclusive, nontransferable license to download and use this eBook/chapter under the following terms and conditions: 1. This eBook/chapter may be downloaded and used by one user on one computer. The user may make one back-up copy of this publication to avoid losing it. The user may not give copies of this publication to others, or make it available for others to copy or download. For a multiuser license contact [email protected] 2. All rights reserved: All content in this publication is copyrighted and Bentham Science Publishers Ltd. own the copyright. You may not copy, reproduce, modify, remove, delete, augment, add to, publish, transmit, sell, resell, create derivative works from, or in any way exploit any of this publication’s content, in any form by any means, in whole or in part, without the prior written permission from Bentham Science Publishers Ltd.. 3. The user may print one or more copies/pages of this eBook/chapter for their personal use. The user may not print pages from this eBook/chapter or the entire printed eBook/chapter for general distribution, for promotion, for creating new works, or for resale. Specific permission must be obtained from the publisher for such requirements. Requests must be sent to the permissions department at E-mail: [email protected] 4. The unauthorized use or distribution of copyrighted or other proprietary content is illegal and could subject the purchaser to substantial money damages. The purchaser will be liable for any damage resulting from misuse of this publication or any violation of this License Agreement, including any infringement of copyrights or proprietary rights. 5. The following DRM (Digital Rights Management) policy is applicable on this eBook for the non-library / personal / single-user. Library / institutional / multi-users will get a DRM free copy and they may implement their own institutional DRM policy. • 25 ‘Copy’ commands can be executed every 7 days. The text selected for copying cannot extend to more than one single page. • 25 pages can be printed every 7 days. • eBook files are not transferable to multiple computer/devices. If you wish to use the eBook on another device, you must send a request to [email protected] along with the original order number that you received when the order was placed. Warranty Disclaimer: The publisher does not guarantee that the information in this publication is error-free, or warrants that it will meet the users’ requirements or that the operation of the publication will be uninterrupted or error-free. This publication is provided "as is" without warranty of any kind, either express or implied or statutory, including, without limitation, implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the results and performance of this publication is assumed by the user. In no event will the publisher be liable for any damages, including, without limitation, incidental and consequential damages and damages for lost data or profits arising out of the use or inability to use the publication. The entire liability of the publisher shall be limited to the amount actually paid by the user for the eBook or eBook license agreement. Limitation of Liability: Under no circumstances shall Bentham Science Publishers Ltd., its staff, editors and authors, be liable for any special or consequential damages that result from the use of, or the inability to use, the materials in this site. eBook Product Disclaimer: No responsibility is assumed by Bentham Science Publishers Ltd., its staff or members of the editorial board for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products instruction, advertisements or ideas contained in the publication purchased or read by the user(s). Any dispute will be governed exclusively by the laws of the U.A.E. and will be settled exclusively by the competent Court at the city of Dubai, U.A.E. You (the user) acknowledge that you have read this Agreement, and agree to be bound by its terms and conditions. Permission for Use of Material and Reproduction Permission Information for Users Outside the USA: Bentham Science Publishers Ltd. grants authorization for individuals to photocopy copyright material for private research use, on the sole basis that requests for such use are referred directly to the requestor's local Reproduction Rights Organization (RRO). The copyright fee is US $25.00 per copy per article exclusive of any charge or fee levied. In order to contact your local RRO, please contact the International Federation of Reproduction Rights Organisations (IFRRO), Rue Joseph II, 9-13 I000 Brussels, Belgium; Tel: +32 2 234 62 60; Fax: +32 2 234 62 69; E-mail: [email protected]; url: www.ifrro.org This authorization does not extend to any other kind of copying by any means, in any form, and for any purpose other than private research use. Permission Information for Users in the USA: Authorization to photocopy items for internal or personal use, or the internal or personal use of specific clients, is granted by Bentham Science Publishers Ltd. for libraries and other users registered with the Copyright Clearance Center (CCC) Transactional Reporting Services, provided that the appropriate fee of US $25.00 per copy per chapter is paid directly to Copyright Clearance Center, 222 Rosewood Drive, Danvers MA 01923, USA. Refer also to www.copyright.com

CONTENTS Foreword

i

Preface

iii

List of Contributors

iv

CHAPTERS 1. Model-Driven Development and Business Process Engineering Kevin Lano 2. Analysis of Previous Research Work on Models Methodologies in Programme and Project Management Ravinder Singh Zandu and Kevin Lano

and

3. Change Management within Project Management: An Integrated Structured Business Process Approach Charalampos Apostolopoulos, George Halikias, Apostolopos Leros and George Tsaramirsis 4. Generation of UML2 Use Cases from MEASUR’s Ontology Charts: A MDA Approach George Tsaramirsis and Mohammad Yamin 5. An Analysis of Enterprise Architecture Frameworks Faisal Almisned 6. Model Driven Approach for Programme Management Ravinder Singh Zandu and Kevin Lano Index

3

12

37

67

77

109

143

i

FOREWORD The software engineering business domain involves the fulfilment of business requirements with humans interacting to build a set of specifications. Human interaction in its turn can lead to frequently changing and ambiguously recorded information where different parties can provide different meaning to similar terminology. Such reasons increase significantly the possibility of failure to deliver enterprise systems, with failure rates reaching 70% of large scale projects. Nowadays, rapidly changing business environments require strategic business planning and especially business modeling to capture change and direct the business accordingly. However, the current industrial landscape predisposes business solutions with a number of defects in terms of lack of understanding and implementing frameworks, methodologies and best practices. As a consequence, informal models or even non-modelled business solutions offer limited value to the business. Such informalities, may lead to a number of limitations such as the requirement for model specific training, difficulty in capturing changing business requirements, the use of inconsistent models which are not often updated and thus the lack in reusing them; in effect, leading to changes that will not be included in all the corresponding models creating inconsistencies since the models will no longer reflect the actual business concepts and environment. Model Driven Architecture (MDA) contributed extensively in improving different facets of the software development product, such as quality, maintainability and, of the process, such as cost-efficiency and predictability. Achieving these aspects in software development required the orchestration of higher levels of abstraction where the use of metadata under transformation rules became dominant and where repetitive data of lower abstraction levels, such as actual software code, was eliminated. The antipodal point of MDA is, of course, Business Process Architecture (BPA) whereby attempts to raise the abstraction level of business processes led to the creation and mainstream adoption of a standardised notation for modeling; Business Process Model and Notation (BPMN) by OMG. Likewise, MDA is a powerful software development method proposed by the Object Management Group (OMG) which has experienced strong support by the software industry and academia.

ii

In this sense, the organisation of the Model Driven Business Process Engineering Workshop held in 2012 at King’s College London, is an attempt on the marriage of the notion of the relatively new research area of the application of best practices from MDA techniques on BPA with examples from Software Development (Lano; Tsaramirsis), Project Management Frameworks (Zandu), Project Change Management (Apostolopoulos) and Enterprise Architecture (Almisned) arenas. It is the aim of MDBPE to become a business solutions development method based on the use of models for the specification, design, analysis, synthesis, deployment, testing and maintenance of complex project environments to produce quality solutions that can significantly contribute to corporate decision making at a strategic level. Considering the ever increasing complexity and cost of the development of business solutions, MDBPE is an initiative that recognises the corporate needs of the global industrial landscape.

Krikor Maroukian Department of Informatics King's College London Strand, London UK

iii

PREFACE This volume contains the papers presented at the first international workshop on Model-based Business Process Engineering, held at King's College London in April 2012. The fields of Model-based Engineering (MBE) and Business Process Modeling (BPM) have many synergies and potential relationships, with process notations such as Petri Nets and Activity Diagrams being used in both fields to model processes and workflows, and model transformations being used to map Platformindependent models to Platform-specific models (in MBE) and to map one workflow models in one notation to models in another notation (in BPM). This workshop was organised to investigate more substantial integrations of the concepts of MBE and BPM. We consider that this combination of fields should be named as “Model-based Business Process Engineering” to denote the use of MBE techniques to construct, transform, migrate and translate business process models. Under such an approach, we include, for example, business analysts creating Framework-independent business process models, then using model transformation tools to map these to Framework-specific models in frameworks such as PMBOK or PRINCE-2. Model-based engineering techniques could also be applied to check the consistency of different business process models, to identify potential workflow patterns within a model, or to check the conformance of a business process model to a framework. In general, MBE provides the benefits of automation, repeatability and abstraction to BPM, helping to produce more consistent, flexible and reusable business process models.

Krikor Maroukian Department of Informatics King's College London and Printec Group Greece

Kevin Lano Department of Informatics King's College London Strand, London UK

iv

List of Contributors Apostolos Leros, School of Technological Applications, Department of Automation, Technological Educational Institute of Chalkis, 34400 Psachna, Evia, Greece Charalampos Apostolopoulos, School of Engineering and Mathematical Sciences, City University London, Northampton Square, London WC1V 0HB, UK David Stupples, School of Engineering and Mathematical Sciences, City University London, Northampton Square, London WC1V 0HB, UK Faisal Almisned, Department of Informatics, King's College London, Strand, London, WC2R 2LS, UK George Halikias, School of Engineering and Mathematical Sciences, City University London, Northampton Square, London WC1V 0HB, UK Georgios Tsaramirsis, 29 Whitmore Close, London, N11 1PB, UK Kevin Lano, Department of Informatics, King's College London, Strand, London, WC2R 2LS, UK Krikor Maroukian, Department of Informatics, King's College London, Strand, London, WC2R 2LS, UK Mohammed Yamin, Department of Information Systems Management, King Abdoulaziz University, Jedah, Saudi Arabia Ravinder Singh Zandu, Department of Informatics, King's College London, Strand, London, WC2R 2LS, UK

Send Orders for Reprints to [email protected] Model-Driven Business Process Engineering, 2014, 3-11

3

CHAPTER 1 Model-Driven Development and Business Process Engineering Kevin Lano* Department of Informatics, King's College London, Strand, London, UK Abstract: In this chapter we give an overview of model-driven development (MDD) and explain its relevance to business process engineering.

Keywords: Model-driven development, model-driven architecture, business process engineering. INTRODUCTION Model Driven Development (MDD) is the development of software systems by means of the construction and transformation of models. MDD can be used to rapidly develop software from high-level specifications, by means of the transformation of abstract models into more refined models, and the automated generation of executable code from models. MDD was devised to make the production of software systems more reliable and efficient by freeing developers from the complexity of implementation details on particular platforms, and by facilitating the reuse of software by retaining the core functionality of a system despite changes in its technology. The concepts of model-driven development are also relevant to business process modelling: project management methodologies such as PRINCE2 [1] and PMBOK [2] prescribe a number of stages in a project, and different levels of detail in modelling of the process and artifacts of a project, and these models may be related and derived from each other by transformations. At another level, a general business or project management process suitable for a range of specific operations or projects could be defined, and this process could then be refined by transformations to instantiate it for a particular project. *Address correspondence to Kevin Lano: Department of Informatics, King's College London, Strand, London, WC2R 2LS, UK; Tel: 0207 848 2832; Fax: 0207 848 2851; E-mail: [email protected] Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

4 Model-Driven Business Process Engineering

Kevin Lano

In this chapter we describe the model-driven architecture (MDA) approach to MDD, and the concept of model transformations, and we discuss the potential for application of MDA and transformations to business process modelling. These possible applications are described in more details in subsequent chapters. MODEL-DRIVEN ARCHITECTURE The main approach to model-driven development which we will consider in this book is the Model-Driven Architecture (MDA) [3]. The MDA is oriented to supporting cost-effective adaption of a system to new technologies and environments by separating technology-independent models of the data and functionality of a system from technology-specific models. The key concepts of model-driven development using MDA are PlatformIndependent Models (PIMs), Platform-Specific Models (PSMs), and Model Transformations. Fig. 1 shows an example of how these fit together to provide software development based on reusable specifications.

Figure 1: MDA process example.

Platform-Independent Model A PIM is a system specification or design model which models a system in terms of domain concepts and implementation-independent constructs of the modelling

Model-Driven Development and Business Process

Model-Driven Business Process Engineering 5

language. It should express the 'business rules' that are the core definition of the functionalities of the system. It should ideally be reusable across many different platforms via the use of PSMs, and be flexible to accommodate enhancements and other backwards-compatible changes. If the PIM is defined in a manner which abstracts from particular algorithms and computation procedures, the model can be referred to as a Computation Independent Model (CIM). Platform-Specific Model A PSM is a system specification or design model of the system tailored to a specific software platform and programming language, such as J2EE and Java. It defines the functionalities of the system in sufficient detail that they can be directly programmed from the model. The PSM to implementation transformation step should ideally be automatable apart from configuration information supplied by the developer. Model Transformations Model transformations produce a new model from an existing model, either to improve the quality of the model (e.g., by removing redundancies, or factoring out common elements of classes or operations) or to refine a PIM towards a PSM, or a PSM to an implementation. Typical transformations include the introduction of design patterns or the elimination of model elements which are not supported by a particular platform (such as multiple inheritance, or many-many associations). OTHER MDD APPROACHES Other approaches to model-driven development include Constraint-Driven Development (CDD), [4], which considers that constraints should be the primary element of a system specification. CDD aims to apply automated code generation from highly abstract models, such as CIMs, using the constraints to guide code generation. Heuristics can be used to select algorithms to solve particular problem specifications. Fig. 2 shows the CDD process.

6 Model-Driven Business Process Engineering

Kevin Lano

Figure 2: CDD process example.

The disadvantage of this approach is that the automatically generated code may be inefficient compared to hand-written code. The developer also has little control over the design and implementation choices. UNIFIED MODELLING LANGUAGE NOTATION The Unified Modelling Language (UML) is the result of unification efforts in the early-mid 90's which combined the key notations of the leading object-oriented analysis and design notations: OMT, Booch and Objectory, into a single language. Standardisation, under the auspices of the Object Management Group (OMG) led to further refinement and spread in the uptake of UML. UML consists of several inter-related diagrammatic and textual notations [5]. These include: 1.

Use case diagrams.

2.

Class diagrams and object diagrams.

3.

State machine diagrams.

Model-Driven Development and Business Process

Model-Driven Business Process Engineering 7

4.

Object constraint language (OCL).

5.

Activity diagrams.

6.

Interactions, sequence diagrams and communication diagrams are special cases of interactions.

Use case diagrams show the services provided by a system, and which users/agents these services interact with. The detailed behaviour of these functionalities and interactions are described using other notations, such as state machines or activities. Class diagrams describe the structure of the entities involved in a system, their internal attributes, and the relationships between these entities. Fig. 3 shows an example, from a banking system where each customer may have any number of owned accounts and each account has either one or two accountholders. Each customer has a name and address, and each account has a name, unique number, current balance and an overdraft limit. The operations credit and debit on an account change its data by adding or deducting a specified amount from its balance.

Figure 3: Example class diagram.

8 Model-Driven Business Process Engineering

Kevin Lano

Classes can represent business entities involved in the system, or other more conceptual data relevant to the system. State machine diagrams describe the behaviour of objects, and the execution steps of individual operations of objects. Fig. 4 shows a state machine for the bank account of Fig. 3, which defines two states Not Overdrawn and Overdrawn which a bank account may be in, and the transitions which can take place between these states, due to executions of credit and debit. By omitting any transition for debit on the Overdrawn state, the diagram expresses the fact that no further debits can be made once an account becomes overdrawn.

Figure 4: Example state machine.

OCL enables developers to describe the properties of classes, associations and state machines in detail, using a textual language. In Fig. 3 the operation credit could be defined by two OCL constraints: A precondition x > 0 asserting that the operation should only be executed if the parameter x is positive. A postcondition balance = balance@pre + x asserting that the new balance is the old balance plus x.

Model-Driven Development and Business Process

Model-Driven Business Process Engineering 9

Activity diagrams show processes as sets of process steps, connected by dependencies (i.e., defining that one step must be preceded by one or more other steps). They can represent software algorithms or organisational workflows, and are often used for business process modelling. Interaction diagrams show the detailed interaction steps involved in particular use cases, and particular sequences of interactions between objects of a system. They are therefore more often used for design, and for illustrating how the system should behave in particular scenarios. Use cases and class diagrams are used at the earliest development stage of a system, to define the services which the system will provide to different groups of users, and the data which it needs to process. Subsequently, more detailed models such as class diagrams and activities are defined to describe how individual use cases should operate. Using a code generator, such as those provided by the UML2Web tool, implementations in Java or other programming languages can be produced from these detailed models. Many existing code generators produce only outline code without operation definitions, however by taking account of constraints, the UML2Web tool is able to produce such definitions automatically. MODEL TRANSFORMATIONS Model transformations are processes which take one or more source models and produce one or more target models as transformed versions of the source. For example, a transformation could take as input a UML class diagram, and produce a design for an enterprise information system that operates on the data of the class diagram. Transformations may operate on a single model, rewriting or restructuring that model (so-called update-in-place mode), for example, restructuring a class diagram to eliminate multiple inheritance from it. Transformations can be implemented using a conventional programming language, such as Java, or by using a special-purpose transformation language, such as Kermeta, ATL, QVT or ETL. Such languages provide a specialised syntax

10 Model-Driven Business Process Engineering

Kevin Lano

and language constructs to define transformations as collections of transformation rules. Individual rules usually map a specific kind of source element to corresponding target elements. An alternative approach to define transformations is to use the existing facilities of UML (use cases, class diagrams and OCL) to specify transformations, and then to utilise code synthesis tools to generate the transformation implementation. This is the approach adopted in UML-RSDS [6]. Instead of transformation rules, individual constraints define the mapping of source elements to target elements. APPLICATION OF MDA TO BUSINESS PROCESS ENGINEERING Business process descriptions are often written in a highly specific manner, conforming to particular frameworks and methodologies. They are thus difficult to adapt or reuse. These problems are analogous to the problems with software, which inspired the establishment of MDD approaches. A corresponding solution in the domain of business process modelling is to provide higher and more abstract levels of business process modelling, from which more detailed and specific models can be derived by means of transformations. In particular, we could model a process independently of specific methodologies (such as PRINCE2 or PMBOK) in order to ease the migration from one methodology to another. Transformations are also applicable to establishing or checking consistency between two different models within the modelling of a business process, or to support the derivation of one model from one or more others. Model-based tools for business process engineering could alert users to incomplete models or stages in a business process definition, and provide advice on model construction using established solutions (for example, workflow patterns). Further aspects of the application of model driven development to business process engineering are considered in the following chapters of this book. In Chapter 2, Ravinder Singh Zandu provides a comprehensive survey and analysis of existing research in applications of modelling to programme and project

Model-Driven Development and Business Process

Model-Driven Business Process Engineering 11

management. In Chapter 3, Charalampos Apostolopoulos and co-authors analyse the requirements of modelling approaches for change management, based on a survey of software project management professionals. In Chapter 4, Faisal Almisned introduces the concept of Enterprise Architecture Frameworks as a basis for model-driven business process engineering. In Chapter 5, George Tsaramirsis and Mohammed Yamin give an application of model transformations to the mapping of different project modelling notations (Use cases and Ontology charts). Finally, in Chapter 6, Ravinder Singh Zandu and Kevin Lano propose a model-driven approach for programme management. ACKNOWLEDGEMENTS Declared none. CONFLICT OF INTEREST The author confirms that this chapter contents have no conflict of interest. REFERENCES [1] [2] [3] [4] [5] [6]

OGC, Managing successful projects with PRINCE2, UK, 2009. PMI, A guide to the Project Management Body of Knowledge, 4th edition, USA, 2008. Object Management Group, Model driven architecture, http://www.omg.org, 2012. K. Lano, "Constraint-driven Development", Information and Software Technology, 50: 406--423, 2008. Object Management Group, UML 2 Standard, http://www.omg.org, 2012. K. Lano, "The UML-RSDS Manual", Department of Informatics, King's College London, http://www.dcs.kcl.ac.uk/staff/kcl/uml2web, 2012.

Send Orders for Reprints to [email protected] 12

Model-Driven Business Process Engineering, 2014, 12-36

CHAPTER 2 Analysis of Previous Research Work on Models Methodologies in Programme and Project Management

and

Ravinder Singh Zandu* and Kevin Lano Department of Informatics, King's College London, Strand, London, UK Abstract: This paper surveys the relevant literature and work carried out in the area of project management using different models, methodologies, and frameworks. Project Management (PM) broadly means programme management, portfolio management, practice management, etc. A project management system has a set of processes, procedures, framework, methods, tools, methodologies, techniques, resources, etc. which are used to manage the full life cycle of projects. This also means to create risk, quality, performance, and other management plans to monitor and manage projects efficiently and effectively.

Keywords: Programme/program management, project management, maturity models, onshore-offshore management, leadership and management, global distributed projects. INTRODUCTION Projects can be considered at all levels of organization, which may involve one or many business units and can involve one or hundreds of persons. The duration of projects can vary from a few weeks to many years. Projects can be simple to highly complex and may be implemented at one location or in multiple locations across multiple countries. There are two main project management (PM) standards i.e. Project Management Body of Knowledge (PMBOK) by PMI, USA, and PRINCE-2 by APMG, UK. Considering the PMBOK and PRINCE-2 standards as the base, models may be defined for the process and knowledge management areas of PM. The benefits of

*Address correspondence to Ravinder Singh Zandu: Department of Informatics, King's College London, Strand, London WC2R 2LS, UK; Tel/Fax: 07725991038; E-mails: [email protected]; [email protected]; [email protected] Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 13

having models include support for defining tools for project management, deliverables and documentation, and improvement of consistency between different areas and processes of PMBOK. Such models may be able to benefit other projects as the tools, documents and deliverables of a project can be reused. The use of modeling will also bring consistency and reliability in the management of various projects. This will make project monitoring and controlling easier during the execution and whole life cycle of the project. The final advantage will come in the form of delivering good quality projects on time, budget and scope with improved quality. This will lead to overall customer satisfaction as risk and issues will be managed efficiently and effectively. An independent study, undertaken and conducted by Loudhouse Research, on behalf of the CA in 2007 on “The changing face of project management” studied the Project panorama in UK corporates, and evaluated issues of project failure as well as excellence. This study redefined the issue of project failure, emphasising the strategic value that projects deliver rather than exclusively on delivery within budget and time. The survey identified that: 

26% of surveyed companies are spending more than half of their IT budget on IT projects.



The average company is managing 29 projects at once and 1 in 10 companies is managing more than 100 projects at a time.



More than half of IT Directors (52%) think that projects are more complex than 5 years ago, fuelled by increased demand from business (62%) and a more pressurised regulatory environment (55%).



For 59% of companies, less than half of their initiatives are strategic.



53% projects are based on business processes improvement, 36% on growing revenues, and 32% on introducing new products/ services.

The survey also covered various issues in managing projects effectively. Some of these are as follows:

14 Model-Driven Business Process Engineering

Zandu and Lano



A typical budget over-runs 30%; 1 in 6 projects go more than 50 % over budget; only 10 out of 29 projects in progress at one time will come in on or under budget.



Inaccurate scoping and forecasting is blamed for budget over-runs in half of cases (50%), with scope creep responsible in 4 out of 10 cases.



Only a 3rd (35%) of businesses check that initiatives are aligned with business objectives, with only 1 in 8 companies basing this decision on real time, accurate information.



74% of businesses struggle to access critical skills.



39% of IT Directors don’t have complete visibility over all IT initiatives in progress.



42% of IT directors know within a day if an initiative is off-course.

These problems indicate that a more rigorous methodology is required to deliver projects efficiently and effectively within time and budget. There are two main standards for project management: the Project Management Body of Knowledge (PMBOK) by PMI, USA and PRINCE-2 by APMG, UK. PMBOK is the dominant standard as this is used in more than 75% of the projects around the world. Software/IT projects use various methodologies such as SSADM, RUP, Spiral Model, Scrum, Extreme Programming, etc. and management methodologies such as PMBOK, PRINCE2. According to PMBOK [1], a project is a temporary endeavour undertaken to create a unique product, service or result. According to PMBOK, project management is realised through the combination and practice of five project management processes: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. PMBOK divides project management into nine knowledge areas of Integration, Scope, Time, Cost, Quality, Human Resource, Communication, Risk, and Procurement Management. Project management is the effective use of processes, procedures, tools, techniques along with knowledge, and skills to meet project objectives. Project managers have to manage the

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 15

traditional Triple constraints – “Scope, Time, and Cost”, which have been enhanced in recent versions of the PMBOK standard with three more constraints called “Quality, Risk and Customer Satisfaction”. PRINCE2 [2] describes a project as “A management environment that is created for the purpose of delivering one or more business products according to specified business needs”. The PRINCE2 process model comprises of eight distinctive management processes namely: Starting up a Project (SU), Directing a Project (DP), Initiating A Project (IP), Planning (PL), Managing Stage Boundaries (SB), Controlling a Stage (CS), Managing Product Delivery (MP), Closing a Project (CP) which covers the full life cycle of a project. PRINCE2 is a de facto standard used extensively in UK government. A key standard amongst maturity models for Portfolio, Programme, and Project Management is P3M3 [3]. This offers a framework for organizations by which they can assess their current performance and develop/ implement improvement plans with measurable outcomes based on industry best practice. LITERATURE SURVEY Previous research has focused on different aspects of program and project management, such as the study of models and frameworks, empirical analysis, and statistical studies. The research has been conducted in different industrial sectors but most of the research has been in the software and IT industry. Project Management Models/Frameworks The following papers [4-8] have investigated existing project management models and/or frameworks and have proposed modifications and amendments to make the models and frameworks more effective and efficient. Rehman [4] discussed and compared project management frameworks for managing software projects. This paper compares five different approaches to PMBOK and then proposes a generic PM approach. This research can be of benefit for project managers to decide on particular methodologies for different projects.

16 Model-Driven Business Process Engineering

Zandu and Lano

Schweyer [5] discussed three concepts/stages for a project management approach starting with (i) a global project framework to define objectives, project life cycles and steps; (ii) to create project specifications, plans, and measurement baselines to manage the project; (iii) to define resources, timelines, milestones, etc. for the project manager and teams. The paper also proposes dynamically changing the project with a modular and flexible approach. Cederling et al., [6] decomposed industrial system development into a number of phases. Their organisation process defines the results and deliverables i.e. a document or a system component which is to be transitioned from one phase to the next phase(s) to follow. They studied three systems and developed a new model. The new model was evaluated by applying the model to a fourth system. In order to make better coordination of complex projects, object based models were created by Bailetti et al., [7]. The models have been used on three chip design projects and the problems and challenges were identified in the coordination of activities based on PM tools. Object based models were created to overcome these issues and to summarize the stages of the project as required by the project manager. This model increases the coordination between a structured approach and PM tools and adds value to the management of projects in which activities are uncertain, unstable, and complex. Milosevic [8] emphasised the use of standardised project management, and considered that project managers should create required processes, procedures, documents by using various available methods, tools and techniques. This will help to synergise the project activities, metrics, resources, and budget etc. Use of Modelling in Project Management The following papers [9-12] have tried to implement system modelling, estimation and object oriented concepts for better project management. Alexandre [9] proposed a methodology to integrate the use of the System Dynamics approach within the existing project management process. Since project risks are dynamic and difficult to understand, the paper proposed the use of SD modelling as a useful framework for managing risk dynamics within the PMBOK risk management process.

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 17

Silva and Paulo [10] propose the use of System Modelling as a communication tool to evaluate and gather stakeholder expectations and requirements in a more efficient and effective manner. This is essential to fill the gap between project manager and customer expectations due to different communication skills. This gives rise to scope changes which eventually result in changes to the budget, time, and quality of the project. They utilise the system modelling technique in the MIT-Portugal Green Islands project. The results clearly suggest that it is possible to bridge the gap between clients and project manager with respect to project objectives and requirements. Object oriented models for project management and control are proposed by Jyhjong and Chunshu [11]. The model represents project activities and components in text and graphical forms. A hierarchical structure is used to represent various parts of the software development process and to provide a view of respective levels of information for project managers. Relations of objects are defined to represent interactivity among various components and objects. R. Ashman [12] provides an estimation model for determining project effort based on use-cases. This model takes into account the relation between actual and estimated data so as to improve the estimates in future. This model works better in iterative development process and allows comparing of successive developments. Project Management in IT and Software Projects Research on software and IT projects is discussed in the research papers [13-22]. The authors explore not only the standard project management methodologies like PMBOK, PRINCE2, RUP but also the new practices of Agile, JAD, RAD and extreme programming. Researchers also suggest adaptations of project management models for managing complex projects in the software and IT industry. Walt Scacchi [13] discusses various process models in used in software engineering and projects. The research covers various models from traditional software process models to modern web based models and how traditional models are giving way to the new process models due to the more dynamic nature of projects and products. Since the changes required are quite frequent and quick,

18 Model-Driven Business Process Engineering

Zandu and Lano

new models which are iterative and incremental such as Agile, JAD, RAD, extreme programming are being used regularly. A process of customisation of regular project management techniques to manage inefficiencies of processes in large scale and complex software projects is discussed by Reddy, N.G. [14]. This paper also provides guidelines on techniques to use customisations so as to develop better generic models for process improvement solutions. Such a model will provide more robust efficiency and productivity analysing capabilities. Shlaer et al., [15] define the Project matrix, a simple and straightforward model for technical project management. This model is found to be efficient and very effective in coordinating the work of project resources, monitoring and controlling software development project, easing the complexity of the development process and developing high quality software. This approach requires no special training or resources. This can be made to function on a single-project scale, and does not require a particular institutional structure (such as a Technical Writing or Quality Assurance Department). Callegari and Bastos [16] develop an integrated model for RUP and PMBOK. The technical software development process of a product lifecycle is managed by applying RUP and PMBOK for the management of the project lifecycle. In this way organisations can attempt to automate a number of activities/ tasks in the software development process. This is to ensure better quality products and effectively managed projects. Champa et al., [17] propose a new redesigned framework and approach for managing software development type IT projects. The authors integrate software engineering practices with standard project management methodologies and frameworks to create a new framework for managing software development projects. In order to get the optimum utilisation of the triple constraints of cost, time and scope, an integrated framework has been proposed to make these triple constraints a function of the high level requirements/business purpose of the project [18]. Some

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 19

challenges are identifying the polarities to manage, rather than problems to solve. Polarity management involves moving from focusing on one pole as the problem and the other as the solution (either/or thinking), to valuing both poles (both/and thinking). Good polarity management gets the best of both poles while avoiding the limits of either. The authors extend the benefits of polarity management to triple constraints as used by PMBOK to develop an integrated framework. Sarantis et al., [19] analyse critically the project management approaches in government IT projects. The authors identify various challenges facing the e-government projects and the use of existing PM methodologies. The paper discusses the gaps in implementation of e-government projects and proposes to make appraisal more systematic and applicable for managing e-government projects successfully. The use of two new visual representations T-cube and Metromap have been developed for managing software projects [20]. These techniques use graphical and metaphor presentations to show various project management tasks. As the name suggests these techniques use Rubik Cube and Metro map metaphors. The authors test them on real project data and show that these tools are effective and provide positive results for project management. Rita and Andries [21] suggest the application of the software agents framework to help in managing various processes of software projects. Two comprehensive frameworks are developed to assist the core and facilitating processes and functions of software project management. The framework assigns each agent to manage a small and manageable task, hence reducing complexity. The study by these authors suggests that it can significantly help in meeting market expectations and to deliver projects as per the stakeholders’ expectations adhering to schedule and budget. Shuobo Xu and Dishi Xu [22] discuss whether the existing project management methodologies like PRINCE2 have been useful in the management of software projects and information systems. They recommend that project managers have to use some other tools for effort and budget estimation, and performance measurement techniques. They conclude that organisations have to develop full

20 Model-Driven Business Process Engineering

Zandu and Lano

scale quality management plans to ensure delivery of a good quality software product efficiently and effectively. Managing Projects in R&D Organizations Differences between managing projects in R&D organisations and other projects are examined in the papers [23, 24]. Since R&D projects are knowledge intensive, they give rise to different sets of requirements and expectations from stakeholders. For better management and improved performance of research projects and programmes, Gilbert [23] discusses an approach that emphasises building relationships between project management and engineering processes. This has been used at the systems management office at NASA Langley Research Centre. This approach suggests implementation of good project management practices and processes with consultation of teams from the early stages, and improving processes with tailor-made training modules as and when required using a just-in-time approach. This methodology also takes care of improvements in processes and policies and emphasises conducting reviews and assessments independently for value addition. The difference between R&D enterprises and other organisations is analysed by Tang Dingyong et al., [24]. Since R&D enterprises are knowledge intensive, more emphasis has to be on knowledge management. Therefore a culture of sharing knowledge by use of documentations, templates, and shared information systems has to be created. This research confirmed that a knowledge management system is needed to strengthen the R&D enterprise information system. Empirical and Statistical Aanalysis A number of empirical and statistical studies [25-33] have been conducted to investigate the success of various project management methodologies and frameworks. Data has been collected and analysed using various techniques in order to understand the effectiveness of diverse project management methodologies. Diana and Joyce [25] carried out a survey to find the experiences of people in project management. The survey findings were highlighted in terms of various

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 21

methods, tools and techniques used and their effectiveness. Performance, project success factors and common criteria for managing successful projects were also studied. Chen and Cian [26] studied the factors influencing the execution of project management and measured the performance of project management. They found that the 6 factors which have greatest impact on execution of project management are Management commitment, financial constraints, organisational structure, reward system, education and training of project teams. Dekkers and Forselius [27] explained the importance of scope management for successfully managing ICT projects. Standish group’s CHAOS report states that only 1/3 of ICT projects are successful. Therefore project managers need to manage scope and changes more efficiently and effectively. This paper describes various approaches and techniques used by the trained scope managers in USA, Europe and Australia which have increased the success rate of ICT projects. Berander and Wohlin [28] conducted an empirical study to identify the important factors in the success of software process management. Their study found that synchronisation is a more important factor than others for successful process management in software projects. Other factors in order of ranking were baselining, user involvement, management commitment, change management, and documentation. Marini et al., [29] studied the effect of change on the methods, practices, and performance of ICT projects. Their paper discusses the impact and challenges due to the dynamic nature of work and environment in the current scenario. The research focussed on finding the reasons for failure, and reviewed the tools, techniques, practices and standards used. They also tried to analyse if failures are due to the changing, dynamic or unstable nature of ICT projects and environments. Comparison has been made between modern and traditional project management by Iman [30]. The author also discusses the key issues in modern project management and the challenges faced in the current environment. It also explores

22 Model-Driven Business Process Engineering

Zandu and Lano

the use or preference of one or other project management methodology by the project manager, resulting in difficulty in managing projects which use a different methodology or framework. Jugdev et al., [31] explored factors in project management by considering project management assets as independent variables and project management performance as dependent variables. To analyse the advantage offered by project management assets, analysis of an online survey by 198 PMI members was done. Seven factors were characterised for project management assets, three factors for organisational support and two factors for project management performance. The findings of the survey showed that project management assets give a competitive advantage to the organisations. Amir Bakhsheshi et al., [32] discuss the impact of the personality and behaviour of the project manager on the project types and the success of the projects. A questionnaire was developed to evaluate the relationship of the project manager’s behaviour and personality with the project type and success rate. The four types of projects considered were Urgent, Complex, Novel, and Normal and they are judged with three constraints cost, time and quality of projects. Ghasemabadi and Shamsabadi [33] studied the application of the PMBOK 2008 standard processes to manage an Enterprise Project Management (EPM) system in one of the organisations. The authors reviewed how the EPM project was implemented and its status based on the data collected by them. They proposed a number of concepts to reduce the time and budget and to enhance the system for better efficiency. Use of Alternative Methodologies Some researchers [34-39] have used alternative methodologies and statistical techniques in the project management area. The investigations have used approach-avoidance theory, Fuzzy logic, NPV etc. for project management. G. Pan et al. [34] describe the use of approach-avoidance theory to develop integrated process model for managing escalation and de-escalation process in IT projects. The authors use a process model to identify conditions, critical incidents,

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 23

sequence of actions, and consequences over the life cycle of the project. The study was done at various levels of project, organisation and environments to get an insight into the approach-avoidance decision of escalation or de-escalation and the stakeholders’ response to the same. A conceptual model representing actual project performance has been described by M. S. Deutsch [35]. The author carried out a feasibility study by means of questionnaire and interview data. The paper highlights the management skills and factors required for managing the project performance and difficulties. The factors and management skills are required in both the technical as well as management areas of cost, schedule etc. Fuzzy logic has been used for critical path analysis and other PM activities by Li and Wei [36]. The approach also determines the significance of activity and path along with critical path. This is very useful in risk management and the method is able to manage the uncertainties. O. Zwikael and J. Smyrk [37] describe how project success and performance can be measured in terms of output benefits realised. The authors explain a technique to establish a cause and effect relation between output utilisation and target outcomes. The paper presents a concept of managing project scope through a utilisation map of the outputs. Wetekamp [38] discussed the utilisation of Net Present Value (NPV) as a tool to better control project management. The author argues that for successful monitoring and controlling of projects, NPV should be used. Young and Frank [39] studied the relationship of project management with other allied disciplines in the field of management. The research is based on the study of 18 top management and business journals, publications and they divide these into 8 categories. The categories are (1) Strategy/Portfolio Management; (2) Operations Research/ Decision Sciences; (3) Organizational Behaviour/ Human Resources Management; (4) Information Technology/Information Systems; (5) Technology Applications/Innovation; (6) Performance Management/Earned Value Management; (7) Engineering and Construction; and (8) Quality Management/Six Sigma.

24 Model-Driven Business Process Engineering

Zandu and Lano

Effects of Leadership and Management Qualities of Project Manager Effects of leadership and management qualities of project manager along with communication channels for managing projects have been explored by some researchers [40-42]. The importance of IQ, EQ, and MQ have also been studied. Teaching of proper project management tools and software is also stressed. Shuanggin and Cheng [40] discussed various issues related to IT projects such as uncertain, unique, fast changing, short term, etc. They emphasised that the project manager plays a key role in successful delivery and implementation of IT projects. Project managers must explore various communication channels with all stakeholders so that they can obtain and circulate proper support and information from all sides. This will ensure in building long term relations and synergy with clients and project teams and all other stakeholders. R. Muller et al., [41] studied the effects of leadership quality on the success of different types of projects. The authors studied the impacts of the IQ, EQ, and MQ of the project manager/ leader on the success of the projects with different level of complexities. The paper uses factor analysis and moderated hierarchical regression analysis to analyse various responses and the data gathered. Analysis showed that there is a relation between EQ, MQ and project success but this is moderated differently by the complexity of the projects. The EQ and project success relationship is moderated by the complexity of faith, whereas the MQ and project success relation is moderated by both complexity fact and faith. Project success is directly affected by the interaction and its complexity. Authors also did variance and non-parametric tests to see the means and medians of EQ, IQ, MQ, complexity of faith, fact, and interaction. Tatnall [42] discussed the issues of teaching project management as part of system analysis. Most of the training/ teaching programmes put emphasis only on drawing Gantt charts or PERT charts for planning without using proper PM tools and skills. Hence the project plan cannot give a full picture of the project and its issues. Authors suggest that proper tools, skills and techniques must be given to the aspirants along with proper assignments and tasks. They should use good project and/or portfolio management software for completing the assignments and tasks.

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 25

Project Management in the Global Distributed Environment Managing projects in the global distributed has its own challenges [43-66]. Researchers have explored the use of different methodologies, techniques, tools for managing distributed projects, ranging from standard processes to incentive based approaches. With the exponential growth of communication technologies and information systems, the globalisation of the commercial world has also increased significantly. Armstrong and Cole [43] highlighted that in order to increase efficiency, productivity, quality and cost effectiveness, organisations are increasingly using outsourcing and distributing their work globally. F. Salger et al., [44] described the importance of the software requirement specification (SRS) document to the success of global software projects. The authors discussed various difficulties in creating a standard SRS as companies have their own methods of creating such documents. The authors studied how Cap Gemini overcame this issue by using specification patterns so as to create synergy among the global teams. The significance of knowledge sharing among global teams and stakeholders and how it can be addressed by mature processes and tools is highlighted by F. Salger et al., [45]. They conclude that there will be lesser readjustment required if the processes, methods and tools are used enterprise wide. The authors proposed that enterprise wide software should be used for project assurance, quality and knowledge sharing. Narayanan et al., [46] described the team structure for successful completion of offshore projects. The authors studied two types of structures for offshore teams and highlighted the problems faced by managers for changing the team structure and organisation model. They also proposed that changes have to be done to the existing structure for successful global operations. A framework for managing risks in global software projects is proposed by J.S. Persson et al., [47]. The framework had been created for distributed projects based on various parameters and requirements of the global environment. H. H. Khan et al., [48] studied the impact of communication media like email, messaging, phone etc. on conflict resolution in global teams. The authors tried to

26 Model-Driven Business Process Engineering

Zandu and Lano

evaluate which could be the best sequence or combination of media tools for communication for resolving the conflicts. Lane and Agerfalk [49] tried to analyse global development projects using a framework in order to overcome various issues in the distributed projects. The authors tried to study the processes used by various organisations to manage the distributed projects efficiently and effectively, and to maximise the benefits of onshore-offshore delivery. T. Niinimaki [50] studied different communication media and their application for global agile software development projects. The authors found that instant messaging is a good substitute tool for face to face communication and email is a good tool for wider and enterprise wide information sharing. Predicting the outcome of global software development projects with the application of analytical modelling has been studied by R. M. Czekster et al., [51]. In this work analytical models are parameterised to accommodate the single-site or multi-sites, team sizes, skills levels, expertise, availability, and support level etc. Managing a multi-site software development project is complex and requires a very good collaboration among teams [52]. The same can be improved using networked virtual environment which allows for better communication, familiarity, sharing, mentoring, faith and faster resolution of conflicts. J. Hashmi et al., [53] had studied the growth of teams in distributed software development projects. The authors study the growth of teams in terms of expertise, communication skills, economic impact and working conditions. Hinds & Bailey [54], explain that “Distributed Work” is basically a number of different work provisions. Since the teams are distributed globally, and are separated by time zones, the managers have to rely heavily on the availability and efficiency of communications tools and information systems. Use of incentive based theories to the distributed work environments is explained by Bret Swan et al., [55]. The paper endeavours to address two subjects; firstly, to understand the effect of incentives on the worker’s choice for using distributed

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 27

work environment, and secondly the collaboration of multiple incentives or disincentives across organisation, groups or individuals. This paper also looks into reasons as to why people always prefer to take up distributed work environment. The theory of incentive is applied to two organisations to understand the behaviours and patterns. Bailey and Kurland [56] suggested that the use of distributed work environments including home working is to mainly reduce the costs, improve efficiency and productivity, motivate employees, and to impact the group outputs positively. Even though there is clear impact of home working on the employees for the work-life balance, with more flexibility, but there are conflicting observations made of negative impacts, such as distractions at home which result in increased stress [57-60]. Alvesson [61] defined knowledge intensive firms as those that “offer to the market the use of fairly sophisticated knowledge or knowledge-based products”. Knowledge intensive firms can be divided into professional service, and research & development firms such as engineering and law firms or pharmaceutical companies. Knowledge intensive firms differ from other types of organisations through the organisation’s massive reliance on the intellectual skills of its employees to carry out its core functions. Although many of the problems and barriers to distributed work are not unique to knowledge-intensive firms, the sophisticated nature of the knowledge these firms typically deal in has the potential to magnify these problems. This report focuses on the interaction of individuals and teams within knowledge-intensive firms and the ways that they interact and perform under distributed work arrangements. Hornett [62] defined a virtual team as “groups of people employed in a shared task while geographically separated and reliant on electronic forms of communication”. The term remote resourcing is defined as “carrying out work in an office remote from the point where a project is principally delivered” (Turkington [63]). These terms essentially describe interactions between people separated by physical distance who perform most of their work through

28 Model-Driven Business Process Engineering

Zandu and Lano

communication technology. Within the body of this report the term distributed work is used to represent this concept. Distributed work covers many alternative methods of work which include satellite offices, flexible work arrangements, telecommuting and global collaborative teams (Bélanger and Collins [64]). Distributed work faces all the issues and problems that normal collocated group’s face, with the added complexity of workers being based at locations remote from each other, be it in the next room or in another country (Cramton [65]). The inclusion of IT as a required element of many work interactions reflects the importance of ICT as a replacement media to mimic the communicative and collaborative qualities inherent in collocated work groups. Mohammad et al., [66], explain that small and medium enterprises (SMEs) are also facing huge competition due to the globalisation of economies and the easier availability of cheaper and good quality products, services across the world. In order to stay ahead of the competition, SMEs should focus on e-collaborations through a project management approach. This will ensure them structured processes for managing the full life cycle of projects and giving them better monitoring and control of project execution. Project Management Maturity Models Various maturity models have been developed in the area of project management [67-76]. Maturity models help in assessing the capability and maturity of various processes, tools, techniques and management methodologies in an organisation. Grant and Pennypacker [67] studied the maturity levels of project management in different industries. They surveyed 126 organisations based on 42 components of maturity. They found that maturity level is 2 out of 5 w.r.t. 36 components out of 42 analysed. The investigation also studied various industries and formed it into four groups i.e. professional, scientific, technical services; information; financial and insurance; and manufacturing. The results showed that the maturity levels are similar across industries barring few exceptions.

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 29

The use of maturity models in improving project management practice is discussed by Naomi and Robin [68]. The paper analyses the current maturity models for project management. The analysis showed that maturity models are mostly used reactively rather than proactively. The study also emphasised the fact that more empirical evidence and research is required to establish the relationship of project performance with project management maturity models. Project Management Process Maturity (PM)2 model is presented by Young and William [69] to evaluate and compare the project management levels of organisations. (PM)2 model provides a well-structured model for evaluating project management maturity level of organisations. The model takes into account PM processes, factors and characteristics and shows the organisation’s progress from functional to project driven organisation. Annerav Sukhoo et al., [70] proposed a maturity model which has three maturity levels and a continuous improvement group of Key Process Areas (KPAs). This paper has taken ISO 9001:2000 as a base for quality management. Each KPA is mapped onto a plan-do-check-act (PDCA) cycle. A conical structure is developed for displaying the gradual development of KPAs in a better manner. KPAs are developed until they attain a dependable maturity level for project management. These KPAs may have to improve continuously in order to respond to changes. PMI, USA provided a very useful maturity model for organisations OPM3 [72] to reflect their maturity with the best practices achieved within the project, portfolio, and programme domains. OPM3 tries to link organisational strategy to successful, consistent, and predictable project completion. OPM3 divides the process improvement into four sequential stages i.e. Standardise, Measure, Control and continuously Improve. IEEE developed a standard for software project management plans (SPMP), IEEE std. 1058-1998 [73]. This standard specifies format and contents of SPMP but does not specify techniques to be used or examples. The standard applies to all types and all sizes of software projects. This standard provides information and documents for managing a software project, and it also defines the technical and managerial processes necessary to deliver the project requirements.

30 Model-Driven Business Process Engineering

Zandu and Lano

Capability Maturity Model Integration (CMMI) [74-76] provides a framework for process improvements across enterprises. This framework gives applications of principles, practices, and objectives to achieve enterprise-wide process improvement. The models have been used in many organisations since 1995 when the models were first created. Organisations have been able to manage budget and times efficiently with enhanced productivity and quality of projects. SUMMARY Project management is a very complex field and encompasses technical skills along with man management skills to manage stakeholder expectations. Projects are influenced by both internal and external factors and require various communication channels and techniques to reduce the gap and to deliver projects effectively and efficiently. The studies have been conducted to understand the existing standard models [4-8] and to adapt them so as to manage projects in a better way. Modifications have been suggested so as to make existing methodologies work in different areas of application. System modelling, dynamic modelling, estimation models and object oriented modelling concepts have been investigated for improving project management [912]. Software and ICT projects have their own challenges due to rapid technological advances, providing better services, facilities etc. Therefore standard project management methodologies may not be sufficient for managing projects in this area. These methodologies may have to be enhanced and that is the reason that Agile, JAD, RAD, extreme programming and other new methods have been developed [13-22]. Stakeholders have different sets of obligations, constraints, necessities, and expectations as projects in R&D organisations are knowledge-intensive, requiring more sharing of ideas. These differences have been highlighted in the research papers [23-24].

Analysis of Previous Research Work on Models

Model-Driven Business Process Engineering 31

Researchers had been able to study various project management methodologies, tools, and techniques etc. empirically and statistically [25-33]. They have collected data from various projects to study different areas of project management and analysed it to understand the effectiveness of various models, techniques or tools. Use of alternative statistical techniques and models such as Fuzzy Logic, NPV, approach-avoidance theory, have also been explored in the project management area [34-39]. Leadership abilities, communication and management abilities along with IQ, EQ and MQ of the project manager have a huge impact on the projects they manage [40-42]. Teaching of project management is not only about teaching of GANTT and PERT charts but also must include various software and other tools for successfully managing projects. The distributed environment of projects in present multinational organisations gives rise to more complexities in all areas of project management [43-66]. Therefore standard project management methodologies have to be enhanced to meet diverse requirements from various stakeholders. The concept of maturity level is able to give some measure of the reliability of organisations in a particular area [67-76]. There are a number of maturity and capability levels for project management such as (PM)2, OPM3, CMMI, IEEE, etc. against which an organisation can be appraised. ACKNOWLEDGEMENTS Declared none. CONFLICT OF INTEREST The authors confirm that this chapter contents have no conflict of interest. REFERENCES [1] [2] [3]

A Guide to the Project Management Body of Knowledge, 4th edition, PMI, USA, 2008. Managing Successful Projects with PRINCE2, OGC, UK, 2009. P3M3-Portfolio, Programme and Project Management Maturity Model, OGC, UK, 2008.

32 Model-Driven Business Process Engineering

[4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]

[19] [20]

Zandu and Lano

Ur Rehman, A., “Software Project Management Methodologies/ Frameworks Dynamics – A Comparative Approach”, International Conference on Information and Emerging Technologies, ICIET 2007, pp 1-5. Schweyer, B., “Formal Specifications For A Project Management Approach”, IEEE International Conference on Systems, Man and Cybernetics”, 1995, vol.2, pp 1170-1175. Cederling, U.; Ekinge, R.; Lennartsson, B.; Taxen, L.; Wedlund, T.; Vaxjo Univ., Sweden, “A Project Management Model Based On Shared Understanding”, Proceedings of the 33rd Annual Hawaii International Conference on System Sciences, 2000. Bailetti, A.J.; Callahan, J.R.; DiPietro, P., “A Coordination Structure Approach To The Management Of Projects”, IEEE Transactions on Engineering Management, 1994, vol. 41, pp 394-403. Milosevic,D.Z, “Standardizing Unstandardized Project Management”, IEEE Technical Applications Conference, Northcon/96, 1996, pp 12 – 17. G. Rodrigues, Dr. Alexandre, “ Managing and Modelling Project Risk Dynamics A System Dynamics-based Framework”, 4th European PMI Conference, London, 2001, pp 1-7. Silva, C. A.; Ferrão, Paulo, “A Systems Modeling Approach to Project Management:The Green Islands Project example”, Second International Symposium on Engineering Systems, MIT, Cambridge, Massachusetts, 2009, pp 1-12. Lin, Jyhjong; Yeh, Chunshou, “An Object-Oriented Formal Model For Software Project Management”, Sixth Asia Pacific Software Engineering Conference, (APSEC '99), 1999, pp 552-559. Ashman, R., “Project Estimation: A Simple Use-Case-Based Model”, IT Professional”, vol. 6, Issue: 4, 2000, pp 40 – 44. Walt Scacchi, “Process Models in Software Engineering”, Encyclopaedia of Software Engineering, 2nd Edition, John Wiley and Sons, 2001. Reddy, N.G.; “Designing Software Project Management Models Based on Supply Chain Quality Assurance Practices”, March 31 2009-April 2 2009, WRI World Congress on Computer Science and Information Engineering, 2009, Los Angeles, CA, pp 659 – 663. Shlaer, Sally; Grand, Diana; Mellor, Stephen J., “The Project Matrix: A Model for Software Engineering Project Management”, Proceedings of. the Third Software Engineering Standards Application Workshop (SESAW III), October 1984, pp1-10. Callegari, D.A., Bastos, R.M., “Project Management and Software Development Processes: Integrating RUP and PMBOK”, International Conference on Systems Engineering and Modeling, 2007. ICSEM '07, pp1-8. Hewagamage, Champa; Hewagamage, K. P., “Redesigned Framework and Approach for IT Project Management, International Journal of Software Engineering and Its Applications, Vol. 5 No. 3, July, 2011, pp 89-106. Van Wyngaard, C.J.; Pretorius, H.C.; Pretorius, L., “Strategic Management Of The Triple Constraint Trade-Off Dynamics - A Polarity Management Approach”, IEEE International Conference on Industrial Engineering and Engineering Management (IEEM), 2011, 2011, pp 824 – 828. Sarantis, D.; Askounis, D.; Smithson, S., “Critical appraisal on project management approaches in e-Government”, 7th International Conference on ICT and Knowledge Engineering, 2009, pp 44-49. Aguirregoitia, Amaia; Javier Dolado Cosín, José;, Presedo, Concepción, “Software Project Visualization Using Task Oriented Metaphors”, J. Software Engineering & Applications, 2010, vol 3, pp 1015-1026.

Analysis of Previous Research Work on Models

[21] [22] [23] [24]

[25] [26] [27] [28] [29]

[30] [31] [32]

[33]

[34] [35]

Model-Driven Business Process Engineering 33

C Nienaber, Rita; Barnard, Andries, “A Generic Agent Framework to Support the Various Software Project Management Processes”, Interdisciplinary Journal of Information, Knowledge, and Management, vol. 2, 2007, pp 149-162. Xu, Shuobo; Xu, Dishi, “Project Management Methodologies: Are They Sufficient To Develop Quality Software” 2nd IEEE International Conference on Emergency Management and Management Sciences (ICEMMS), 2011, pp 175 – 178. Gilbert, M.G., “A Systems Management Approach To Improving Performance And Reducing Risks In Research Projects And Programs”, IEEE Aerospace Conference Proceedings, 2002, Vol. 7, pp 3467-3471. Dingyong, Tang; Yizhen, Tao; Long, Jiang; Zheng, Cheng, “Application Research of Knowledge Management in R&D Enterprise Project Management”, International Conference on Information Management, Innovation Management and Industrial Engineering, 2009, Volume: 4, pp 447-452. White, Diana; Fortune, Joyce, “Current Practice in Project Management –an Empirical Study”, International Journal of Project Management – 20, 2002, pp 1-11. Chen, L.Y., Cian Hui Kao, “The Effects Of Strategic Implementation Of Project Management And Performance”, The 2nd IEEE International Conference on Information Management and Engineering (ICIME), 2010, pp 194-198. Dekkers, C.; Forselius, P., “Increase ICT Project Success with Concrete Scope Management”, 33rd EUROMICRO Conference on Software Engineering and Advanced Applications, 2007, pp 385 – 392. Berander, P.; Wohlin, C., "Identification of Key Factors in Software Process Management A Case Study", Proceedings International Symposium on Empirical Software Engineering, Rome, Italy, 2003, pp 316-325. Othman, Marini; Mohd Zain, Abdullah; Razak Hamdan, Abdul, “A Review On Project Management And Issues Surrounding Dynamic Development Environment Of ICT Project: Formation Of Research Area”, International Journal of Digital Content Technology and its Applications, vol. 4, no. 1, 2010, pp 96-105. Attarzadeh, Iman, “Modern Project Management: Essential Skills and Techniques”, Communications of the IBIMA, Volume 2, 2008, pp 1-9. Jugdev, K.; Mathur, G.; Fung, Tak;, “Project Management Assets And Project Management Performance: Preliminary Findings”, Technology Management in the Energy Smart World (PICMET), 2011, pp 1 - 7. Hossein Fazel Bakhsheshi, Amir; Rashidi Nejad, Safoora, “Impact of Project Managers’ Personalities on Project Success in Four Types of Project”, 2011 2nd International Conference on Construction and Project Management, IPEDR-2011, vol.15, 2011, pp 181186. Ghasemabadi, M.A.; Shamsabadi, P.D., “Application Of Five Processes Of Project Management Based On PMBOK-2008 Standard To Run EPM-2010 Project Management System: A Case Study Of Arya Hamrah Samaneh Co.”, 2nd IEEE International Conference on Emergency Management and Management Sciences (ICEMMS), 2011, pp 792 – 795. Pan, G.; Pan, S.L.; Newman, M., “Managing Information Technology Project Escalation and De-Escalation: An Approach-Avoidance Perspective”, IEEE Transactions on Engineering Management, vol. 56, Issue: 1, 2009, pp 76 - 94. Deutsch, M.S., “An Exploratory Analysis Relating The Software Project Management Process To Project Success”, IEEE Transactions on Engineering Management, vol. 38, Issue: 4, pp 365-375.

34 Model-Driven Business Process Engineering

[36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50]

Zandu and Lano

Feng, Li; Junyin, Wei “A Fuzzy Approach for the Project Management”, International Conference on Wireless Communications, Networking and Mobile Computing, WiCom 2007, 2007, pp 5180-5183. Zwikael, O.; Smyrk, J., “An Engineering Approach For Project Scoping”, IEEE 18Th International Conference on Industrial Engineering and Engineering Management (IE&EM), 2011, pp 2135-2137. Wetekamp, W., “Net Present Value (NPV) As A Tool Supporting Effective Project Management”, IEEE 6th International Conference on Intelligent Data Acquisition and Advanced Computing Systems (IDAACS), 2011, pp 898 – 900. Hoon Kwak, Young; T. Anbari, Frank, “Analyzing Project Management Research: Perspectives From Top Management Journals”, International Journal of Project Management 27, 2009, pp 435–446. Liu, Shuangqin; Liu, Cheng, “Management Innovation of IT Project Managers”, International Conference on Information Management, Innovation Management and Industrial Engineering (ICIII), 2010, vol. 3, pp 62-65. Muller, R.; Geraldi, J.; Turner, J.R., “Relationships Between Leadership and Success in Different Types of Project Complexities”, IEEE Transactions on Engineering Management, 2012, vol. 59 Issue:1, pp 77 – 90. Tatnall, A.; Shackleton, P, “IT Project Management: Developing On-Going Skills In The Management Of Software Development Projects”, International Conference Software Engineering: Education and Practice, 1996, pp 400-405. Armstrong, D., & Cole, P., “MANAGING DISTANCES AND DIFFERENCES IN GEOGRAPHICALLY DISTRIBUTED WORK GROUPS” in P. Hinds & S. Kiesler (ed.) Distributed work. Cambridge, MIT Press, 2002, pp. 167-186. Salger, F.; Englert, J.; Engels, G., “Towards Specification Patterns for Global Software Development Projects - Experiences from the Industry”, 7th International Conference on the Quality of Information and Communications Technology (QUATIC), 2010, pp 73 - 78. Salger, F.; Sauer, S.; Engels, G.; Baumann, A., “Knowledge Transfer in Global Software Development - Leveraging Ontologies, Tools and Assessments”, 5th IEEE International Conference Global Software Engineering (ICGSE), 2010, pp 336 - 341. Narayanan, Sidharth; Mazumder, Sumonta; R., Raju, “Success of Offshore Relationships: Engineering team structures”, International Conference on Global Software Engineering, ICGSE’06, 2006, pp 73 - 82. Persson, J.S.; Mathiassen, L.; Boeg, J.; Madsen, T.S.; Steinson, F., “Managing Risks in Distributed Software Projects: An Integrative Framework”, IEEE Transactions on Engineering Management, vol. 56, Issue: 3, 2009,pp 508 – 532. Khan, H.H.; Malik, N.; Usman, M.; Ikram, N., “Impact of changing communication media on conflict resolution in distributed software development projects”, 5th Malaysian Conference in Software Engineering (MySEC), 2011, pp 189 - 194. Lane, M.T.; Agerfalk, P.J., “Experiences in Global Software Development - A FrameworkBased Analysis of Distributed Product Development Projects”, 4th IEEE International Conference on Global Software Engineering, ICGSE, 2009, pp 244 – 248. Niinimaki, T., “Face-to-Face, Email and Instant Messaging in Distributed Agile Software Development Project”, 6th IEEE International Conference on Global Software Engineering Workshop (ICGSEW), 2011, pp 78 - 84.

Analysis of Previous Research Work on Models

[51] [52] [53]

[54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67]

Model-Driven Business Process Engineering 35

Czekster, R.M.; Fernandes, P.; Sales, A.; Webber, T., “Analytical Modeling of Software Development Teams in Globally Distributed Projects”, 5th IEEE International Conference on Global Software Engineering (ICGSE), 2010, pp 287 – 296. Bartholomew, R., “Globally distributed software development using an immersive virtual environment”, IEEE International Conference on Electro/Information Technology, EIT, 2008, pp 355 - 360. Hashmi, J.; Ehsan, N.; Mirza, E.; Ishaque, A.; Akhtar, A., “Comparative analysis of teams' growth in offshore and onshore software development projects”, IEEE International Conference on Management of Innovation and Technology (ICMIT), 2010, pp 1163 – 1167. Hinds, P.J. and Bailey, D.E., “Out of Sight, Out of Sync: Understanding Conflict in Distributed Teams”, Organization Science, 2003, vol. 14 (6), pp 615-632. Bret Swan, France Belanger, Mary Beth Watson-Manheim, “Theoretical Foundations for Distributed Work: Multilevel, Incentive Theories to Address Current Dilemmas”, IEEE 37th Hawaii International Conference on System Sciences, 2004, vol. 1/04, pp 1-10.. D. E. Bailey and N. B. Kurland, "A review of telework research: Findings, new directions, and lessons for the study of modern work," Journal of Organizational Behavior, 2002, vol.23, pp. 383. A. Pinsonneault and M. Boisvert, "The Impacts of Telecommuting on Organizations and Individuals: A Review of the Literature," in Telecommuting and Virtual Offices: Issues and Opportunities, N. J. Johnson, Ed. London: Idea Group Publishing, 2001, pp 163-185. K. E. Pearlson and C. S. Saunders, "There's No Place Like Home: Managing Telecommuting Paradoxes," Academy of Management Executive, 2001, vol. 15, pp 117128. F. Belanger, M. B. Watson-Manheim, and D. H. Jordan, "Aligning IS Research and Practice: A Research Agenda for Virtual Work," Information Resources Management Journal, 2002, vol. 15, pp. 48-70. M. Igbaria, "The Driving Forces in the Virtual Society," Communications of the ACM, 1999, vol. 42, pp 64-70. Alveson, M, “Knowledge Work and Knowledge-Intensive Firms”. Oxford University Press, New York, 2004. Hornett, A., “The Impact of External Factors on Virtual Teams: Comparative Cases”, in Pauleen, J. (ed.), “Virtual Teams: Projects, Protocols and Processes”, 2004 Idea Group Publishing, UK. Turkington, D. (2005), “Remote Resourcing”, The Beca Infrastructure Board, Auckland 2004. Bélanger, F. and Collins, R.W., “Distributed Work Arrangements: A Research Framework”. The Information Society, 1998, vol 14, pp 137-152. Cramton, C.D., “Attribution in Distributed Work Groups”, in Hinds, P.J. & Kiesler, S. (ed.) “Distributed Work”, The MIT Press. London, England, 2002, pp 191-212. Mohammad Jafari, M.; Ahmed, S.; Dawal, S.Z.M.; Zayandehroodi, H., “The importance of E-collaboration in SMEs by project management approach a review”, 2nd International Congress on Engineering Education (ICEED), 2010, pp 100 – 105. Grant, K.P.; Pennypacker, J.S., “Project management maturity: an assessment of project management capabilities among and between selected industries”, IEEE Transactions on Engineering Management, 2006, vol. 53, pp 59-68.

36 Model-Driven Business Process Engineering

[68] [69] [70]

[71] [72] [73] [74] [75] [76]

Zandu and Lano

Brookes, Naomi; Clark, Robin, “Using Maturity Models to Improve Project Management Practice”, POMS 20th annual Conference, USA, 2009. Hoon Kwak, Young; Ibbs, C. William, “Project Management Process Maturity (PM)2 Model”, Journal of Management In Engineering, 2002, pp 150- 155. Sukhoo, Aneerav; Barnard, Andries; M.Eloff, Mariki; A. Van der Poll, John, “An Evolutionary Software Project Management Maturity Model for Mauritius”, Interdisciplinary Journal of Information, Knowledge, and Management, 2007, vol. 2, pp 99118. EPA Guidance for Quality Assurance Project Plans for Modelling, Office of Environmental Information, EPA QA/G-5M, USA Environment Protection Agency, Dec. 2002. Organisational Project Management Maturity Model (OPM3), 2nd edition, Project Management Institute, USA, 2008. IEEE standard for Software Project Management Plans, IEEE std 1058-1998, IEEE, USA. CMMI for Development, Version v1.3, Software Engineering Institute Process Management Program, 2010, Carnegie Mellon University, USA, 2010. CMMI for Acquisition v1.3, Software Engineering Institute Process Management Program, 2010, Carnegie Mellon University, USA, 2010. CMMI for Services v1.3, Software Engineering Institute Process Management Program, 2010, Carnegie Mellon University, USA, 2010.

Send Orders for Reprints to [email protected] Model-Driven Business Process Engineering, 2014, 37-66

37

CHAPTER 3 Change Management within Project Management: An Integrated Structured Business Process Approach Charalampos Apostolopoulos1*, George Halikias1, Apostolopos Leros2 and Georgios Tsaramirsis3 1

School of Engineering & Mathematical Sciences, City University London, Northampton Square, London, UK; 2School of Technological Applications, Department of Automation Technological Educational Institute of Chalkis, Greece and 3Department of Information Technology, King Abdulaziz University, Jeddah, Saudi Arabia Abstract: The science of modem project management is not new and what seems to have changed over the past decade are the ways of applying theory into practice. This has had as a consequence the need to standardise and structure different project management methods in a detailed, documented and formal manner. On the other hand, change management mostly observed and utilised as an integrated process within project management, is a rational process for exploring decision and behaviour alternatives in an attempt to realign the course of “derailed” deliverables due to change and ensure project success. However, models contained in such frameworks often lack formal semantics and clarity; fail to address and estimate organisational change management as well as risk reasoning as they also do for the rest of the project management processes. This paper argues the existence of a strong coherence between project management and change management; both being transitional activities but simultaneously integrated ones. The model which is presented and analysed regards Project Management Team collaboration success factors and related attributes.

Keywords: Change management, project management, model driven architecture, business process engineering. INTRODUCTION Modern business processes usually demand the utilisation of a variety of business frameworks and methodologies in order to offer a concrete business solution. Many times, the use of such frameworks is imposed by clients such as governments *Address correspondence to Charalampos Apostolopoulos: School of Engineering and Mathematical Sciences, City University London, Northampton Square, London, EC1V 0HB, UK; Tel: +44 (0)7729654093; Fax: +44 (0)20 7040 8930; E-mail: [email protected] Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

38 Model-Driven Business Process Engineering

Apostolopoulos et al.

or large organisations. However, models contained in such frameworks often lack formal semantics and clarity. This gives rise to the need to standardise and structure different ways of project management, in a detailed and documented format. There can be many reasons a project can fail: lack of user input and clarifications, change in requirements and specifications, unrealistic budgeting, lack of risk estimation policies, poor requirements definition [1-3]. In this light, project managers consider structured project management methodologies as the solution to the aforementioned problems. The science of modern project management, started to emerge in 1990s [4-6]. What seems to have changed over the past decade are the ways of putting theory into practice. High project failure rates [7-11] have given the incentive to institutions, agencies or even individuals to develop and establish standards for project management methodologies, such as: PMBOK®, PRINCE2®, Scrum, Agile, ISO 21500 and others. These are not simply good quality guidelines, but also legal requirements for complex projects. The main strength of these frameworks lies in their comprehensive formality, attention to detail, and robustness in describing specific processes. Project management can have strategic value, when there is link between the level of effectiveness and the efficiency with which a project is accomplished and when the project’s outcomes (product or services) can provide overall business value. The connection between project management and strategy was stressed by indicating the involvement of the project manager at the start of the project [12]. Nevertheless, strategic organisational change can be facilitated and managed through the use of project management disciplines [13]. The US and UK governments request in most of the cases, public projects to be managed by PMBOK®, and PRINCE2®, respectively. Hence, in order for business value to be generated, most organisations turn into contemporary structured project management methodologies so as to gain competitive advantages and

Change Management within Project Management

Model-Driven Business Process Engineering 39

increase the possibilities of project success. Following next, the literature review section relates change management and project management indicating their strong overall integration. LITERATURE REVIEW The processes of change management and project management (together with risk management in certain cases), are usually regarded as separate entities and ones which should be generally implemented during the initial stages of a project. Besides the generic need for change, implementing change is often difficult to achieve due to several cultural or even behavioral reasons, often resulting in failure of the overall process. However, what seems to be a mission critical necessity today for an organisation, is to adapt to specific customer requirements and concepts such as: strategic business planning, customer satisfaction, market adaptation, flexibility, and subsequently efficient and effective business change management [2]. The aforementioned structured project management methodologies, currently fail to address and estimate risk in organisational change management in a detailed manner as they do for other aspects of the project management process. As enterprise environments are subject to constant change and cultural diversity, frameworks require processes such as change management to maintain an up-todate set of specifications for business requirements whether that applies to collateral analysis or model depictions. Change management itself, is also a strategic and structured approach to transitioning individuals, teams, and organisations from a current state to a desired future state. It is an organisational process aiming to empower employees to accept and embrace changes in their current business environment. Change and adaptation focusing on project requirements concerns mainly the organisation’s general approach in doing business or the relationship between managers and employees or more general company-clients business relationships. Nonetheless, the implementation of project management also requires changes, e.g. in the processes, tools, and methods used to fulfill organisational goals [14].

40 Model-Driven Business Process Engineering

Apostolopoulos et al.

Actually, contemporary project management methodologies can be seen as an integrated tool for managing change irrespective of organisation type. Such changes may involve for example new organisational strategies [15, 16] or even new business development [4]. Changes that relate business models using MDA (Model Driven Architecture) approach may be applicable; but changes over changes might mean that the whole design is lacking clarity leading to possible failure. The main goal of organisational changes is improvement and sustainability; change over change is a stage that most managers are reluctant to accept. In effect, changes as far as project management is concerned, are related to conforming to projects requirements; for example, in time, within budget and to acceptable quality of deliverables, where client or end user requirements are actually fulfilled. Project managers can be regarded as change managers and moreover, managing change is by itself a project. “Project managers, to be effective must be competent change managers. Often projects introduce new or changed products or processes or to put on an event are planned without appropriately considering the change that the project result will cause in its environment” [17]. Especially for project managers, looking at projects realistically, advise business leadership, ensure that change is managed appropriately and finally ensure the project deliverables have been justified in the beginning of the project [17]. The key concepts of model-driven development using MDA are PlatformIndependent Models (PIMs), Platform-Specific Models (PSMs), and Model Transformations. Fig. 1 shows an example of how these fit together to provide software development based on reusable specifications. In order for project managers to become competent change managers, it is necessary to establish a solid foundation for change [18]. Today’s role of the project manager focuses more on the project and the team. Effective projects are those which achieve a business change within a managed organisational context [19].

Change Management within Project Management

Model-Driven Business Process Engineering 41

Project managers need to reposition project management in order to support organisational strategic change [13]. It is not enough to merely describe “the change” and expect it to happen [20]. Furthermore, there is a definite link between project management and change management since both support moving an organisation from a current state to a desired future state, i.e. they are both transitional processes [21]. Overall, project management focuses on tasks or activities [22], whereas, change management focuses on people impacted by change. The key idea is that project management and change management may seem as separate entities; nevertheless, practically they are integrated [20]. Project leaders are typically not in favour of change, since change can prove to be hard for everyone [23]. Moving from a current state to another future state, and remaining unchanged at the same time is impossible. People resist change for several reasons such as: 

Tradition;



Personal losses;



Affection;



Fear for the unknown.

Many professionals managed projects without following any specific project management methodology framework [23]. Nonetheless, as organisations become larger and more complex, the need for a structured project management methodology arises. At the same time, complexity might mean more management layers that have to be addressed properly. Consequently, this may lead to additional communication linkages. According to PMBOK® [22] the total number of potential communication channels (CC) is given by Equation (1): CC = n(n-1)/2

(1)

42 Model-Driven Business Process Engineering

Apostolopoulos et al.

where n represents the number of stakeholders. There exist multiple, complex, multi-level dimensions to an organisation that simply cannot be ignored, taking into account organisation behaviour theory [24]. To this frame, it is observed that the bigger the size of organisations, the greater the complexity of operations within the same organisation. Since change is inevitable in projects (there is no perfect project) ‘competent project managers make a commitment to pay the price for change’. Change in structured project management frameworks is an embedded process within the project management methodology. In this context, every project is subject to changes; one of the aims of structured project management methodologies is to adapt to changes and in effect minimise risk and finally ensure project success. As far as the two widely established and globally applied project management frameworks are concerned and more specifically PMBOK®, there is extensive referencing to change in monitoring and controlling process, whereas PRINCE2® and change are linked in the respective change and control process; change theme. Literature review, revealed the strong coherence of project management and change management, both being transitional activities but overall integrated. Next, Model Driven Architecture (MDA) aspects in relation to change management will be discussed. MODEL DRIVEN ASPECTS In an attempt to characterise change management in terms of improved business engagement it is imperative to consider an area where substantial improvement has been recorded when it comes to software modelling and architecture specifications. OMG introduced the term Model Driven Architecture (MDA) in 2000 [25] and officially in 2001. The main goals of MDA are productivity, portability, interoperability and maintenance and documentation [26]. Reusability has also been claimed as another established advantage MDA can offer and especially in the area of Domain-Specific Modelling (DSM) [25, 27].

Change Management within Project Management

Model-Driven Business Process Engineering 43

A Domain can be characterised as Customer, Company, Contact, Location, Airport, Gas station [28]. Domain Engineering seen also as Product Line Engineering is the entire process of reusing domain knowledge in the production of new software systems [29]. An essential idea in systematic software reuse is the application domain, a software area that contains systems sharing commonalities. Most organisations, work in only a few domains. They repeatedly build similar systems within a given domain with variations to meet different customer needs. Rather than building solutions from scratch, significant savings can be achieved by reusing portions of previous systems in the domain to build new ones. In effect, a Professional Domain Engineering could mean, the process of systematic reuse of domain knowledge such as ' business documentation' e.g. Solution Proposals to RFPs, Project Plan, Communication Plan, Risk Management Plan, Change Management Plan, etc. in projects of any nature and specialised industry e.g. pharmaceutical, aerospace, petroleum, retail, telco, etc., in order to attain financial and productivity gains by avoiding to repeat tasks of building the solution from scratch. Other topical modelling issues MDA has addressed include model informality and inconsistency, loss of knowledge due to corporate resource attrition levels, model specific training. Over the past decade, MDA has been applied in numerous software development projects in public and private corporations such as the State of Ohio, Coopservice, Daimler, Austrian Health Authority [30] yielding outcomes that highlight its applicability in software development corporate teams, which strive to improve code reusability and thus resource productivity and the time from product conception-to-market. Results indicate that many modelling issues have been addressed with MDA, providing semantically richer, more reliable and higher in consistency modelling tools. Essentially, MDA transformations established the definition of abstraction levels or metalevels as to the models that represent certain software development code. More specifically, the highest level of abstraction is defined as the Computational

44 Model-Driven Business Process Engineering

Apostolopoulos et al.

Independent Model (CIM) which then transforms to the Platform Independent Model (PIM) and finally to the Platform Specific Model (PSM), (see Fig. 1).

Figure 1: MDA Software Development Life Cycle [26].

In effect, the informal documentation of requirements provided in textual format using MDA techniques can be formally modelled at a high-level of abstraction where technologies such as C or Java need not be specified. Any MDA model possessing a corresponding metamodel can participate in the MDA transformation process. The transformations through the metalevels are governed by elements, attributes, classes which possess semantics defined within the Meta Object Facility (MOF) [31].

Change Management within Project Management

Model-Driven Business Process Engineering 45

One of the key modelling issues that MDA has addressed involves two-way model updates i.e. forward and backward model change management. In fact, one way transformations have been supported by most transformation tools available in the market. Thus, transformations were possible either from a higher abstraction level to a lower abstraction level e.g. PIM to PSM or vice versa generally known as backward transformations. The support of transformation tools of two-way transformations has been denoted as ‘bidirectionalisation’ [32, 33]. MDA improves reusability and traceability of models and thus improves change management in the software development context which in turn can result to more efficient project management in terms of activity scheduling and human resource assignment to scheduled activities. This paper attempts also to highlight the potential research areas that can extend MDA aspects on DSM to businessspecific model. It has already been suggested that corporate decision analysis and decision making leading to changes, can be linked to business needs and improved decision making techniques by adopting approaches in model driven environments for software development [34]. The next section will describe in detail the methodology used to model the significance of Project Management Team success factors under a variety of related attributes. METHODOLOGY There are a number of research methods to choose from so as to conduct a thorough investigation to identify issues concerning change management within project management methodologies. For this paper, and its associated empirical study, a qualitative approach was selected to establish theoretical interrelations on Change Management and Project Management. More specifically a survey was used as a primary source of data collection from which useful information, facts, figures and professional views can be recorded. A survey and related presentation were provided to the members of BCS (British Computer Society) Hellenic Section with a request to reply to questions relative to Change Management and Adaptation focusing on “Project Management Team” (Appendix B). The main goal of the presentation was not only for the audience to

46 Model-Driven Business Process Engineering

Apostolopoulos et al.

familiarise with concepts related to Change Management and Project Management, but also, to explain in details the various attributes of the proposed model. The Likert scale was selected due to the advantages of its readiness to complete, in terms of time consumption and question comprehension on behalf of the survey participants. In addition, this scaling method ensures a thorough analysis and presentation of findings since the scale is uniform for all questions. Since the research questionnaire’s primary goal is the respondents to rate (weight) related attributes, a five-level semantic differential scale was used. Then, in order to apply a relative weighing scale for each individual attribute, a semantic scale was in turn used for transformational reasons (percentages) as seen in Table 1. Consolidated results were calculated (Appendix C) by using the arithmetic mean and round up where necessary. Table 1: Likert Scale and Relative Weights Mapping Scale Likert Scale

Relative Weights Scale

1 (Very Low)

0.20

2 (Low)

0.40

3 (Medium)

0.60

4 (High)

0.80

5 (Very High)

1.0

Among other advantages, respondents are more appreciative when providing short and concise answers to set questions. The majority of the sample from the BCS Hellenic section professionals, were individuals with experience in managing projects (various organisational levels and several years of experience) from various industries but not limited to: organisations’ consultants, analysts and managers. Out of the twenty-two survey forms which were asked for completion, twelve were valid (no missing parts), three were incomplete and seven were not complete at all. Effectively, the recorded response rate for completed and returned questionnaires was 54.5%. The survey (model) depicted in Appendix B, consists of thirty-five questions separated into five main sections. Nevertheless, there are other sections (non-

Change Management within Project Management

Model-Driven Business Process Engineering 47

Likert scale) which ask for “general information”, or open –ended questions which ask the respondents for their own personal reflection or suggestions. PROJECT MANAGEMENT TEAM MODELLING Change seems to have become the rule within organisations in an attempt for rapid and effective business environment adaptation. Organisations have precise missions and objectives that take the challenge to accomplish taking the least possible risks. Similar to project management processes, objectives reflect all the planned activities of each organisation that have to be specified upon achievement. Part of the organisation is the Project Management team, also with specific mission and objectives as far as project management is concerned. Specifically for contemporary project management methodologies, project success is related to conformance to project’s requirements. Overall, it is highly probable that project changes have an impact on projects success or failure. Every project has significant differences, in terms of several factors, including factors that are the well-established, such cost, time, scope and quality. At the same time projects are managed by different teams of people which have a common goal; project success. The project management team has in turn different characteristics, like for example culture, experience and management level that have to be combined together to ensure that the deliverables of the projects conform to customer requirements and expectations. Before examining the proposed model and its related attributes, it is worth taking as examples two well established globally project management frameworks, PMBOK® and PRINCE2® and discuss their recommendations on the role of the Project Management Team. For PMBOK®, one of the roles of Project Management Team is to identify internal and external stakeholders so as to determine the requirements of the project and related expectations of all parties involved. However, it is the project managers work to influence stakeholders relative to the project requirements so as to ensure a successful outcome [22; p.23]. The project team is consists of various

48 Model-Driven Business Process Engineering

Apostolopoulos et al.

members, e.g. for example the sponsor, the project manager, other project team members and the Project Management Team. In brief, the sponsor’s role is to provide the financial resources, involving responsibilities in other important areas, e.g., authorising changes in scope, phaseend reviews and go/no-go decisions where risk are quite high [22; p.25]. According to PMBOK® the project team comprises of the project manager, the project management team and other team members that can perform various aspects of the work but do not necessarily get involved with the management of the project [22; p.26]. Finally, the project manager has as primary goal the achievement of project objectives. Overall, it is a high-profile and significant role which requires several skills, such as: flexibility, strong leadership, negotiation skills and solid knowledge of project management practices [22; p.26]. It is within the responsibility of the project manager to keep the communication among all stakeholders at the centre of interaction. In contrast, PRINCE2® describes four management levels, corporate or program management (highest level), directing a project, controlling a stage and managing product delivery [35; p.21] where different roles are assigned to various individuals. “The project board represents at managerial level the business user, and supplier interests, of the project” [35; p.208]. The project board consists of the executive, the senior user and the senior supplier who provide overall direction and management of the project. The main responsibility of the project manager and appointed team is to run the project on a day-to-day basis on behalf of the project board. In effect the project manager has the prime responsibility to “ensure that the project produces the required products, to the required standard of quality and within the specified constraints of time and cost” [35; p.212]. The project management team model as depicted in Appendix A, consists of one parent node (Project Management Team) and five child nodes (Performance, Motivation, Appraisal, Rewards and Training). Each child node consists in turn of several attributes which represent the respective survey’s questions.

Change Management within Project Management

Model-Driven Business Process Engineering 49

Even though a model may carry a high degree of complexity, one of its scope deliverables is to be used universally and irrespective of specific structured project management framework’s approach. Overall, the aim is to fit to project business scenarios as a repeatable process. FINDINGS AND ANALYSIS Concerning the general information that the respondents gave as seen in Fig. 2, replies concerning PMBOK® and PRINCE2® were split evenly (25%); one respondent indicated the use of Open Workbench, a tool for project scheduling and management. 8% 25% PMBOK 34%

PRINCE2 Scrum None Other 25% 8%

Figure 2: Project Management Framework Preference.

The majority of the respondents (34%) do not use any specific project management framework for managing projects. This can be justified by the fact that currently in Greece; the notion of project management is not so well established among professionals. However, ELOT 1429 is a national project management standard, that service providers are expected to have gained in order to participate in public sector projects. This does indicate a level of project management maturity in the public sector but perhaps circumstances are different in the private sector where a lack of project management process standardisation is observed.

50 Model-Driven Business Process Engineering

Apostolopoulos et al.

Most respondents had an average experience of project management between two and five years and in average their team was composed of less than five members. The respondents’ background is as follows: 

67% IT/Telecommunications.



17% Government.



8% Management and



8% Food Industry.

Next, the results concerning the model’s nodes attributes are briefly presented. Fig. 3 summarises the results concerning the Performance child node, the definition of which given is the following: “Based on the achievement of preset metrics such as KPI’s (Key Performance Indicators), Balanced Score Cards, KSFs, (Key Success Factors), 360, SLAs (Service Level Agreements). In relation to change processes it is related for example to the alignment of their subordinates' responsibilities with their own, but also the alignment of their own to those of the project manager”. Performance 1.00 0.90 0.80 0.70 0.60 0.50 0.40 0.30 0.20 0.10 0.00 i

ii

iii

Figure 3: Performance Attributes Analysis.

iv

v

vi

vii

viii

Change Management within Project Management

Model-Driven Business Process Engineering 51

Results indicated that the three most significant attributes are as follows: 

Clear targets (88%).



Attaining goals (83%).



Planning outcomes (80%).

It is worth noting that the least significant attribute was Benchmarking (62%). It can be concluded that members of BCS, Hellenic Section, place significant emphasis on the clear targets which are set in the initial stage of a project. Actually, it is much easier to measure project success, if known what it is being defined (deliverables) and what it will be like at the ending phase of a project (product). This is also related to the expectations that the Project Manager has from his/her team, defined accurately from the start of the project. When the targets are clearly set, and assuming that they are attainable and planned, stakeholders can know what is expected and how it can be achieved. They also have a clear understanding of their contribution, which can be enhanced during the life the cycle of the project. In fact “proper planning and organisation of the transition on a life-cycle basis will facilitate a successful change” [36]. The next child node of the survey was related to motivation (Fig. 4), which is defined as follows: “Motivating in a project environment involves creating an environment to meet project objectives while offering maximum self-satisfaction related to what people value most, which the individual considers necessary and important” [22; p.418]. These values may include: 

Job satisfaction;



Challenging work;



Sense of accomplishment;



Achievement and growth;

52 Model-Driven Business Process Engineering



Sufficient financial compensation



Other rewards



Recognition

Apostolopoulos et al.

Motivation 1.00 0.80 0.60 0.40 0.20 0.00 i

ii

iii

iv

v

vi

vii

Figure 4: Motivation Attributes Analysis.

The three attributes with the highest influence as far as motivation is concerned were as follows: 

Financial benefits (83%).



Fear of punishment (83%).



Recognition (77%).

The attribute recorded as being of least important was Innovation (68%). Respondents are highly motivated by financial incentives which for example, may take the form of monetary gains, commission, organisational shares, salary increase but at the same time they fear reprimand in case unexpected events occur. Usually, project stakeholders are inclined not to pursue responsibility on change process failure or misleading and ill-received decisions. In some cultures (e.g., Chinese) misjudgment is followed by punishment, for which individuals are publically criticised and set as an example for future avoidance.

Change Management within Project Management

Model-Driven Business Process Engineering 53

Even though innovation is the least significant attribute based on the respondent’s replies, its influence is beyond average (50%). In most projects innovation should mandatorily originate from the project leader which will influence in turn the stakeholders. This is because in this light (project management in respect to change management), innovation is related to formulation of creative and competitive solutions for the success of project changes. .

In complex and large-scale projects there are dedicated team members who have as main responsibility change requests initiation, monitoring and execution. Key important, is determining the right time to innovate so that the project team and consequently the organisation can adapt to projects’ requirements or even reinvent itself. Next, Appraisal attributes are considered, analysed in Fig.5. Appraisal 1.00 0.80 0.60 0.40 0.20 0.00 i

ii

iii

iv

v

vi

vii

Figure 5: Appraisal Attributes Analysis.

Appraisal Definition: Assessing the performance of employees against agreed targets [37; p.6]. Specifically for project change management, it refers to project changes. Appraisals are better conducted on a systematic and periodic basis. In such a way individual stakeholder’s job performance and productivity will be assessed in relation to certain pre-established criteria and organisational project change objective.

54 Model-Driven Business Process Engineering

Apostolopoulos et al.

The respondents indicated that the most significant attributes were as follows: 

Achievement of objectives (90%).



Performance (88%).



Rewards (78%).

The least significant attribute was Routine (50%). In most of the cases, appraisals can be seen as performance assessment or simply for benchmarking purposes as to what was asked and what has been actually accomplished. Taking into account the previous replies of BCS Hellenic section members, the three top influential attributes come into total agreement with previous answers related to performance attributes. Actually, “Achievement of objectives” has to do with conformance to predefined change targets. Once the changes have been introduced successfully and have an overall positive impact for the success of the project, then in turn the result of the appraisal assessment should be for the benefit of the appraisee. Following an appraisal positive and constructive outcome, what succeeds is related to rewards. Fig. 6 depicts the results concerning the Rewards child node. Rewards 1.00 0.90 0.80 0.70 0.60 0.50 0.40 0.30 0.20 0.10 0.00 i

ii

Figure 6: Rewards Attributes Analysis.

iii

iv

v

Change Management within Project Management

Model-Driven Business Process Engineering 55

As far as Rewards attributes are concerned, the ones which were most influential are: 

Benefits (87%).



Realistic and Clear (82%).



Recognition (78%).

Definition: Tangible and/or intangible benefits given or received in recompense for worthy behaviour, for example after the successful result of change/s have been acknowledged. In many cases rewards may lead to internal team member’s competition which up to a point may be considered healthy. People will place change effort on their priorities list, those who will succeed change goals can be rewarded with benefits. Self esteem (least significant, 72%) is a term used in psychology and has do with a person’s own overall evaluation of his/her worth. Although the ranking of selfesteem is last, the relative influence is considered high. In general, changes can impact psychologically stakeholders either in a positive or a negative way. In some cases people feel fear and anxiety for the unknown; question the effects of changes, and finally deny or conform to the new status quo. The last child node in Project Management Team is that of “Training”, results of which as seen below in Fig 7. Training 1.00 0.80 0.60 0.40 0.20 0.00 i

ii

Figure 7: Training Attributes Analysis.

iii

iv

v

vi

vii

viii

56 Model-Driven Business Process Engineering

Apostolopoulos et al.

Based on the definition that was given to the respondents for Training: “A process concerned with establishing what type of training is required and who should receive it. Training ranges from simple on-the-job instruction to educational and training courses offered by providers external to the organisation. Training, coupled with development, is apparent when organisations plan progression of key employees though the company, in which case an attempt is made to reconcile organizational needs with individual career development” [37; pp. 6-7]. Teaching individuals and groups how to fulfil their duties and responsibilities [36; p.235]. Based on the sample’s replies, the two top score attributes are seen below: 

Experience of the trainer (88%).



Learning and development (80%).

The attribute with the lowest score was that of networking (67%). In general, a quickest and effective way to enhance employee’s capabilities and knowledge is training. Another research survey [38] indicated that 74% out of ninety-three companies examined, faced coordination and implementation problems. For 76% implementation took longer than originally scheduled, 62% of the results showed that training and instructions to low-level employees was not enough and finally 60% of the companies “realised uncomfortable factors in the external environment which had an adverse impact on implementation”. With the aid of training, project team members have the opportunity to develop specialised skills, perform better, get educated which in turn; these skills will assist them to fulfill their duties and responsibilities more effectively. Training might be powerful and useful tool in the hands of project managers; nevertheless, it is not a panacea. Finally, implementing change in relation to project management frameworks is not a simple task, requiring several factors to be combined together. Overall, the attributes

Change Management within Project Management

Model-Driven Business Process Engineering 57

were weighed individually to a score of 50% and over, which indicates the great significance they have for each separate child node being highly consistent. CONCLUSIONS This paper proposes that change management can be regarded as an integrated process within project management. Moreover, it can be seen as a rational process for exploring decision and behavior alternatives; selecting the best possible choices among stakeholders in an attempt to accomplish activities on time, on budget, within scope and of agreed quality standards thus ensuring project success. Effectively, one of the best ways to integrate change management into successful project management is to involve people who work together on solving business problems and achieve results. However, in order for projects to be successful, and even though communication may be based on vocabulary discrepancies, all stakeholders have to formulate a solution to model the customer’s requirements and conform to what is being expected. On the other hand, there is no unique way to conform to project changes and estimate the relative risks, or to predefine the results of a project. This is because what may seem to be applicable on an individual basis or at a business level might be inappropriate or insufficient for specific project conditions. Consequently, changes and the process of adaptation are different among organizations, business cultures and people. Even though, there is no right way to manage project change; flexibility (adaptation to new requirements) is mandatory. In a broader organisational frame, managing business culture might be the solution. Actually, when people are used to specific patterns of cultural behaviour, dealing with change is a process that leads to resistance simply because change, changes the ways things are done, changes the status quo. Change management is on top, based on informal models with inconsistencies and generalisations that may lead to loss of meaning and semantic gaps. After a successful result is noted, the benefits will be realised not only for the project leaders (e.g., project manager) but also for the stakeholders as a team. An

58 Model-Driven Business Process Engineering

Apostolopoulos et al.

expected outcome should be planned and managed accordingly. Involvement and participation of all engaged parties is essential; planning the necessary resources is mandatory. Planning determines resources and project’s needs and in effect unequivocally enhances success. Contemporary project management frameworks define in structured ways the processes for the successful outcome of a project. Nonetheless, they are not a panacea; conforming and being able to predefine success to all projects. Project success is an integration of many different and correlating factors. Provided that project change and risk estimation are seen as opportunities rather than as potential threats then it is quite likely that project success will be more likely. ACKNOWLEDGEMENTS This work would have not been possible without the help of my PhD supervisors (Prof. Halikias, Prof. Stupples, Dr. Leros and Dr. Tsaramirsis) who apart from motivation, offered extensive technical support concerning Change Management and Project Management Analysis. Moreover, I would specifically like to thank Mr. Krikor Maroukian for his continuous help and suggestions, sharing his experience in aspects related to Project Management and Model Driven Architecture Process. Last but not least, I would like to thank the members of BCS, Hellenic section for their time and patience answering the survey’s questions. CONFLICT OF INTEREST The authors confirm that this chapter contents have no conflict of interest. REFERENCES [1] [2]

Apostolopoulos. C, Karamitsos. I, “The Success of IT projects using the Agile Methodology”, 1st International Workshop on Requirements Analysis, pp. 13-20, Pearsons Education, London, UK, 2009. Apostolopoulos. C, Simpson. B, “Requirements Analysis is just the Peak of the Iceberg”, 1st International Workshop on Requirements Analysis, pp. 1-12, Pearsons Education, London, UK, 2009.

Change Management within Project Management

[3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

Model-Driven Business Process Engineering 59

Faulconbridge. R. I, Ryan. M. J, “Managing complex technical projects: A systems engineering approach”, Boston, Artech House Publications, 2002. Cleland. D. I, “A personal perspective of MPM,” Project Management Journal, Vol.24, No.1, 1994. Chaffey. N, “Get your organisation fit for project delivery – build a projects culture”, Project, October, pp.10-12, 1997. Maylor. H, “Project Management, Financial Times Management”, London, pp.11-49, 1999. The Standish Group, “Chaos Report”, 1994, Available from: http://net.educause.edu/ir/library/pdf/NCP08083B.pdf. The Standish Group, “Chaos Report”, 2003, Available from: http://findarticles.com/p/articles/mi_m0EIN/is_2003_March_25/ai_99169967. The Standish Group, “Chaos Report”, 2007, Available from: http://www.standishgroup.com/search/search.php. Taylor. H, “Risk management and problem resolution strategies for IT projects: prescription and practice”, Project Management Journal, Vol. 37, No.5, pp.49-63, 2006. Gottesdiener. E, “Collaborate for Quality”, STQE, The software testing and quality engineering magazine, March/April, 2001, Available from: http://www.stqemagazine.com. Cabanis. J, “Show me the money: A panel of experts dissects popular notions or measuring project management maturity”, PM Network, Vol.12, No.9, pp.53 60, 1998. Cicmil. S, “Critical factors of effective project management”, The total quality management magazine, vol.9, No.6, pp.390-396, 1997. Martinuso. M, Hensmen. N, Artoo. K, Kujala. J, and Jaafari. A, “Project based management as an orgnanizational innovation: Drivers, changes and benefits of adopting project-based management”, Project Management Journal, Vo.37, No.3, pp.87-97, 2006. Turner. J.R, “The handbook of project-based management”, McGraw-Hill publications, England, 1999. Pelligrinelli. S, Bowman. C, “Implementing strategy through projects, Long Range Planning”, Vol.27, No.4, pp. 125-32, 1994. Pitagorsky. G, “Project Managers are Change Managers”, 2011 Available from: http://www.projecttimes.com/george-pitagorsky/project-managers-are-change managers.html. Homes. G, “The hybrid manager”, Industrial and Commercial Training Journal, Vol.33, No.1, pp.16-25, 2001. Gooch. J, “Managing for demonstrably effective IT projects”, Information Management & Computer Security, Vol.5, No.4, pp.133-137, 1997. Creasy. T, “Defining change management: Helping others understand change management in relation to project management and organizational change”, Change management Tutorial, www.change-management.com; retrieved Nov.11, 2007. Carnall. C, “Managing change in organizations”, New York, Prentice Hall, London, 2003. Project Management Institute (PMI), “A guide to the project management body of Knowledge” (PMBOK® guide), 4th edition, 2008. Englund. R, “The complete Project Manager - Change Management”, 2011, Available from: http://svprojectmanagement.com/the-complete-project-manager-changemanagement. Morgenstern. O, “Prolegomena to a Theory of Organization”, Research Memorandum RM734, Rand Corporation, Santa Monica, CA, 1951.

60 Model-Driven Business Process Engineering

[25] [26] [27] [28] [29] [30] [31]

[32] [33]

[34] [35] [36] [37]

Apostolopoulos et al.

Mellor. S. J, Scott. K, Uhl. A, and Weise. D, “MDA Distilled: Principles of Model-Driven Architecture”, Addison Wesley, 2004. Kleppe. A, Warmer. J, and Bast. W, “MDA Explained: The Model Driven Architecture: Practice and Promise”, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. Johannes. J, and Fernandez. M.A, “Adding Abstraction and Reuse to a Network Modelling Tool using the Reuseware Composition Framework”, in: Kuhne. T, Selic. J.B, Gervais. M.P,Terrier. F, (eds.) ECMFA LNCS, vol. 6138, Springer, Heidlberg, pp. 133-143, 2010. Eremin. R, “Reusable Domain Models Strike Back”, 2008, Available from: http://community.devexpress.com/blogs/eaf/archive/2008/03/04/reusable-domain-modelsstrikes-back.aspx Roebuck. K, “Model-driven Architecture (MDA): High-impact Strategies - What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors”, USA, pp.88-90, 2011. Guttman. M, J. Parodi, J, “Real-Life MDA: Solving Business Problems with Model Driven Architecture”, Morgan Raufmann, pp.13-152, 2007. OMG (2012), Meta Object Facility (MOF), Available from: http://www.omg.org/mof/ Sasano. I, Hu. Z, Hidaka. S, Inaba. K, Kato. H, and Nakano. K, “Toward Bidirectionalization of ATL with Groundtram”, In: Cabot. J, and Visser. E, (eds.), ICMT LNCS, vol. 6707, Springer, Heidlberg, pp. 138-151, 2011. Greenyer. J, Pook. S, and Rieke. J, “Preventing Information Loss in Incremental Model Synchronization by Reusing Elements”, In: France, R.B., (eds.), ECMFA LNCS, vol. 6698, Springer, Heidlberg, pp. 144-159, 2011. Apostolopoulos. C, and Maroukian. K, “Model Driven Architecture Transformation for Business Models: Decision Analysis based on a Collateral Analysis Model”, 13th International Conference on Informatics and Semiotics in Organisatins, ICISO, Leeuwarden, Netherlands, 2011. Office of Government Commerce. “Managing Successful Project with PRINCE2 Reference Manual”, published by TSO (The Stationery Office), 2005. Kerzner. H, “Project Management: A Systems Approach to Planning, Scheduling, and Controlling”, 5th edition, International Thomson Publishing Inc, 1995. Mc Kenna. E, and Beech. N, “Human resource Management: A concise analysis”, Pearson Education Limited, England, 2002. Alexander. L, “Successfully Implementing Strategic Decisions”, Elsevier, Long Range Planning 18, no.3, 1985.

Ch hange Managem ment within Proj oject Managemeent

Model el-Driven Busineess Process Enggineering 61

APPENDIX A XA

Fiigure A1: Projject Team Mod del.

APPENDIX A XB Change C Manaagement and d Adaptation n, Questionnaaire. This T survey deals d with your y opinion ns concerninng business change maanagement an nd adaptation within pro oject manageement frame works. I would more than appreciate if you u could speend some tim me and com mplete the qu uestionnairee. A (General In nformation): 1. Which Proj oject Manageement Metho odology do yyou use mosstly in your business? (aa-e): a.

OK®. PMBO

b.

PRINC CE2®.

c.

Scrum m.

d.

None.

e.

Other (if “other” please p state which w one).

62 Model-Driven Business Process Engineering

Apostolopoulos et al.

2. How many years of experience do you have as project manager? (a-d): a.

Under 2 (two years).

b.

2 (two) to 5 (five) years.

c.

5 (five) to 10 (ten) years.

d.

Over 10 years.

3. How many members are in your team including yourself (Project Management Team)? (a-d): a.

Less than 5 (five).

b.

5 (five) to 8 (eight).

c.

8 (eight) to 10 (ten).

d.

More than 10 (ten)

4. Which is the industry that you work for? (a-m): Construction a.

Economics / Finance.

b.

Education.

c.

Engineering.

d.

Food Industry.

e.

Government.

f.

Health Care.

g.

Insurance.

h.

Management.

i.

Services.

Change Management within Project Management

Model-Driven Business Process Engineering 63

j.

Telecommunications / IT.

k.

Whole sale and Retail Trade.

l.

Other (if “other” please state which one).

 Please complete the following questions based on the scale seen below : Very Low

Low

Medium

High

Very High

1

2

3

4

5

B. Performance: Please scale the following attributes, based on the effect they have on performance factor (1-5): (i)

Planning Outcomes.

(ii)

Attaining Goal.

(iii) Benchmarking. (iv) Acceptance Level. (v)

Audit and Verify.

(vi) Regular Review. (vii) Review on Agreed Standards. (viii) Clear Targets. C. Motivation: Please scale the following attributes, based on the effect they have on motivation factor (1-5):

64 Model-Driven Business Process Engineering

(i)

Promotion.

(ii)

Improve skills.

Apostolopoulos et al.

(iii) To innovate. (iv) Fear of punishment. (v)

Financial Benefits.

(vi) Recognition. (vii) Competitiveness. D. Appraisal: Please scale the following attributes, based on the effect they have on appraisal factor (1-5): (i)

Performance.

(ii)

Feedback.

(iii) Achievement of Objectives. (iv) Routine. (v)

Opportuity.

(vi) Rewards. (vii) Attainable Results. E. Rewards: Please scale the following attributes, based on the effect they have on rewards factor (1-5): (i)

Benefits.

Change Management within Project Management

(ii)

Model-Driven Business Process Engineering 65

Self-Esteem.

(iii) Realistic and Clear. (iv) Motivation. (v)

Recognition.

F. Training: Please scale the following attributes, based on the effect they have on training factor (1-5): (i)

Management Level (Targer Audience).

(ii)

Networking.

(iii) Experince (Trainee). (iv) Learning and Development. (v)

Experience (Trainer).

(vi) Motivational Benefits. (vii) Value Added. (viii) Clear Targets. G. Personal Reflexion:  Should you wish, please write anything you would like to be noted relative to the questions raised above:

Thank you for completing the questionnaire.

66 Model-Driven Business Process Engineering

Apostolopoulos et al.

APPENDIX C Questionnaire’s DETAILED RESULTS B. Performance: i ii iii iv v vi vii viii

Planning Outcomes Attaining Goals Benchmarking Acceptance Level Audit and Verify Regular Review Review on Agreed Standards Clear Targets

0,80 0,83 0,62 0,75 0,75 0,73 0,78 0,88

C. Motivation: i ii iii iv v vi vii

Promotion Improve skills To innovate Fear of punishment Financial Benefits Recognition Competitiveness

0,73 0,72 0,68 0,83 0,83 0,77 0,70

Performance Feedback Achievement of Objectives Routine Opportunity Rewards Attainable Results

0,88 0,68 0,90 0,50 0,72 0,78 0,77

D. Appraisal: i ii iii iv v vi vii

E. Rewards: i ii iii iv v

Benefits Self-Esteem Realistic and Clear Motivation Recognition

0,87 0,72 0,82 0,75 0,78

Send Orders for Reprints to [email protected] Model-Driven Business Process Engineering, 2014, 67-76

67

CHAPTER 4 Generation of UML2 Use Cases from MEASUR’s Ontology Charts: A MDA Approach Georgios Tsaramirsis* and Mohammad Yamin Department of Management Information Systems, Faculty of Economics and Admin, King Abdoulaziz University, Jeddah, Saudi Arabia Abstract: MEASUR’s ontology charts are the product of MEASUR’s semantic analysis; a requirements analysis method used to capture the ontological dependencies of an information system. These charts can be transformed to databases and to database schemas, class diagrams, component architecture diagrams and prototype systems. This paper shows how MEASUR’s ontology charts can be transformed to UML use case diagrams so that developers can get a quick view of the system’s interaction with the users. The paper utilizes the Model Driven Architecture approach and uses simplified versions of the ontology chart and uses case Meta models. For simplicity and clarity reasons the transformation is described in English rather than a transformation language.

Keywords: MEASUR’s ontology chart, MEASUR’s Semantic analysis, UML use case diagram, MDA. INTRODUCTION MEASUR’s Ontology Charts are the product of MEASUR’s semantic analysis [6, 7]. These diagrams represent ontologically depended temporal information and include a number of self-evaluation rules. MEASUR’s ontology charts can be transformed to databases and database schemas [1], class diagrams [2], component architecture diagrams [9-12] and prototype systems [8]. Ontology charts were proved to be capable of producing extendable system designs [3, 12] but they can quite often be complex. Other diagrams such as the UML use case diagrams offer a simple view of the system. Use case diagrams focus on the users and how they can interact with the system [13]. While use case diagrams contain

*Address correspondence to Georgios Tsaramirsis: Independent Business Consultant, 29 Whitmore Close, London, N11 1PB, UK; E-mail: [email protected] Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

68 Model-Driven Business Process Engineering

Tsaramirsis and Yamin

less information about the system than an ontology chart, they are easy to understand, can be used for communications with the users and can be useful artefacts for testing. This paper will utilize the Model Driven Architecture (MDA) [4] approach and show how use case diagrams can be auto generated from ontology charts. Even if there is significant loss of information during the transformation because use case diagrams capture less information than ontology charts, this transformation can auto-generate a useful part of the use case, saving time for the human designer. RELATED WORK In past research conducted in [12] a UML2 component architecture diagram was auto-generated from an ontology chart. Additionally to component architecture models, during this research they also auto generated a number of software engineering artefacts such as class diagrams [2], COM+ diagrams [10], architecture diagrams [11] and prototype systems [8]. These models were mainly used as proof of concept as the generation of component architectures was the main goal. In the future work section of the thesis it was mentioned that it is possible to partly auto-generate use case diagrams from ontology charts but no details were provided. This paper builds on the work of [12] and details how use case diagrams can be partly auto-generated from ontology charts. ONTOLOGY CHARTS MEASUR’s Ontology Charts are the output of MEASUR’s semantic analysis [7]. These diagrams represent ontologically dependent temporal information and include a number of self-evaluation rules. MEASUR’s ontology chart can be mapped to database diagrams, class diagrams, architecture diagrams and prototype systems. The key idea behind ontology charts is that everything is an affordance because it can afford something for example it can afford a property [5]. Affordances are ontologically dependent on other affordances, which means that if an affordance ceases to exist, all the ontologically dependent objects to this affordance will also cease to exist [6]. For example if a house ceases to exist, the rooms of the house will also cease to exist. Each affordance is ontologically dependent upon one or two antecedents but for simplicity reasons, when the

Generation of UML2 Use Cases from MEASUR’s

Model-Driven Business Process Engineering 69

antecedent of an agent is a country, the society or another concept outside the scope of the system, we put no antecedent. The affordances are temporal and they have start and finish time attributes [1]. The ontological dependency can be seen as a rule, stating that if an antecedent’s finish time has a value; all its dependents must have a finish value that is less than or equal to this value. So if an antecedent finishes, all the dependents will automatically finish. However, the finish of a dependent does not imply the finish of its antecedent. In the most recent version of ontology charts presented in [12], each affordance can be of one of the following types. 

Agent, a physical or legal person,



Entity, an object or concept of existence that cannot take any responsibility,



Relationship, a common interest between two affordances,



Communication act, The recording that an agent is talking to another agent about something,



Determiner, properties of affordances, such as name and so on.

There are a number of connectivity rules as to which type of affordance is permitted to be connected with what, however these rules are out of the scope of this paper, which focuses only upon the transformation of an ontology chart to use case diagrams. USE CASE DIAGRAMS UML’s Use Case diagrams are mainly used to represent functional requirements in a simplified way [13]. The main elements of the use case diagrams are actors, uses cases and their relations to each other. Actors represent humans or computer systems. Use cases are a list of text describing how the actor can interface with the system. There are two main associations between use cases: include and extend. The “include” association means that if the actor interacts with a use case that includes another use case, it also has to interact with the included use case. For

70 Model-Driven Business Process Engineering

Tsaramirsis and Yamin

example an actor customer is associated with “place an order” use case that includes the “pay” use case. The “include” association is represented with an arrow from the source use case to the use case to be included. The “extend” association means that if the actor interfaces with a use case another use may happen as well. For example the actor orders food, sometimes he also orders drink. The extend association is accompanied by a trigger which determines when this use case will be activated. The “extend” is represented like the “include” but the arrow is at the opposite direction and it also has the trigger on the association. Actors can inherit the use cases of other actors. This is represented by an arrow from the child to the parent actor. Use case diagrams are very popular among the software engineering community due to their simplicity and they are a good starting point for system analysis and design as they show the actors of a system and how they interface with the system. This paper attempts to auto-generate them from MEASURE’s ontology charts. MODEL DRIVEN ARCHITECTURE The key idea behind Model Driven Architecture (MDA), is to auto generate code from software design models [4]. In MDA terms every representation can be a model and code is considered as a model. Models can be auto generated from other models. The MDA uses transformations to transform source models to target models. These transformations can be manual if are mainly conducted by humans, semi-automatic if executed by software but with human input, or automatic if no human input is required. The idea of auto-generation of code from models is not new but MDA organises this in a more structured way. MDA divides models to four layers. The Computational Independent Model (CIM) layer, the Platform Independent Model (PIM) layer, the Platform Specific Model (PSM) layer and the code. The first consists of models that contain information about the business as well as the computerized system and interactions between them. Models of this layer contain information about the sociotechnical aspect of the system. MEASUR’s Ontology Charts are considered as CIMs. CIMs are then transformed to Platform Independent Models (PIMs) via a manual or semi-automatic transformation. PIMs are models that contain information about the computerized part of a system but remain at the requirements level. They do not include any implementation details specific to any programming language, operating system

Generation of UML2 Use Cases from MEASUR’s

Model-Driven Business Process Engineering 71

or hardware. Use case diagrams are considered as PIMs as they do not include any implementation details. The PIMs are then transformed to Platform Specific Models (PSMs), usually via an automatic transformation. PSMs contain all the implementation details required for auto-generating the code. These details include programming language specific, operating system or hardware specific information. The PSM can be transformed to code via automatic transformations. The following Fig. 1 shows an overview of the MDA framework.

CIM

Computational Independent Model Both Manual and computerised structures and processes.

Platform Independent Model PIM

Models of the computerised structures and processes but without specific details for any programming language, operating system or hardware.

PSM

Platform Specific Model Models rich with implementation details that can be mapped to code.

Code

Code Code written in any computer language.

Figure 1: Overview of MDA.

As can be seen from Fig. 1, transformations can be from source to target and vice versa but this remains at a theoretical level as sometimes data are lost during the transformation. Especially this is true during the CIM to PIM transformation as the PIM contains computerized data only. It is also possible to transform between models in the same layer. For example it is possible to transform a PSM to another PSM (e.g JAVA PSM to C# PSM). The next section utilizes MDA to transform a MEASUR’s Ontology Chart to Use Case diagram. THE TRANSFORMATION Before a model can participate in a MDA transformation its corresponding MOF Meta model [14] is required in order to “formalize” the semantics of the model. A

72 Model-Driven Business Process Engineering

Tsaramirsis and Yamin

Meta model is a model that explains the semantics of a model. MOF is the Meta modelling standard of MDA. It is like a class diagram that describes all the elements of a model. This section presents both the source and the target Meta models as well as the transformation rules. For simplicity and clarity the rules were written in English rather than a transformation language. Source Meta Model In this paper we only include the properties of the ontology chart that will be used by the specific transformation to generate a use case diagram. The full ontology chart Meta model can be found [11]. In the Meta model in Fig. 2, every node of the ontology chart is an affordance. An affordance can have a maximum of two antecedent nodes and many dependents that are also affordances. Each affordance has two attributes, a label of type string and a type that is an enumeration and that can take the values; agent, entity, relationship, communication act and determiner. 0..2 Antecedent

0..*Dependent

Affordable Label: String Type: Enurm {Agent |Entity | Relationship | Communication Act | Determiner } Figure 2: The source Meta model.

The above is a simplified Meta model that does not include any information about how the affordances are allowed to be connected with each other or any temporal data capabilities. This is because the focus of this paper is on the transformation of the ontology chart to use case diagram and not to how to accurately represent and evaluate ontology charts. The Target Meta Model In this transformation we used a simplified version of use case diagrams. The actor has a label of type string and can have many use cases. Each use case has a label of type string and can extend or include many use cases. Fig. 3 shows the target meta model.

*

Use case Label: String

0

Label: String

1

0

Extends

Actor

Model-Driven Business Process Engineering 73

*

Generation of UML2 Use Cases from MEASUR’s

* Includes

Figure 3: The target Meta model.

Use case diagrams will be used as the target Meta model. The next section describes the transformation. The Transformation Proper The main idea is that agents and roles will be mapped to actors. All communication acts will be a use case in the form of: Communication_act:label + “for” + antecedent2:Label and are associated with the first antecedent that has been converted to the actor. So a person that applies for a loan, will be transformed to an actor with the label person, linked to a use case with the label apply for loan. The entity loan was transformed to text and was placed at the end of the label of the use case. Relationships with agents as their first antecedent will be treated similarly but without the word “for” to connect the label of the relationship and the label of the second antecedent. If the second antecedent of a relationship is another relationship or a communication act then an include arrow from the antecedent to the dependent will also be added to link relationships and communications acts that participate at the use case level. The example of Fig. 4 shows how an ontology chart has been converted to a use case diagram. In the example of Fig. 4 a person applies for a loan and an employee authorises that loan. To summarise, ontology charts can be transformed to use case diagrams by the following rules: 

Agents will be transformed to actors.



Communication acts are transformed to use cases with the label of the use case being their label followed by the word “for” and the label of the second antecedent.

74 Model-Driven Business Process Engineering

Tsaramirsis and Yamin



Relationships with at least one agent as an antecedent are transformed to use cases with their label as the label of the use case followed by the words “associated with” and the label of the second antecedent. If the second antecedent is a communication act or relationship then an include arrow can be generated from the antecedent to the relationship and the label of the second antecedent will follow the label of the relationship.



Relationships that do not fall under this category are ignored by the transformation.



Entities that participate as antecedents of a relationship or communication act that also have an agent as antecedent will be transformed to text and be included as part of the last part of the label of the use case.



Entities that do not fall under the above category will be lost during the transformation



Determiners are ignored during the transformation.

Authorise Applies for a loan Employee

Loan Authorise !Applies Applies for a loan

Person

Figure 4: Ontology Chart to Use case example.

Generation of UML2 Use Cases from MEASUR’s

Model-Driven Business Process Engineering 75

The above rules propose a general method for transforming ontology charts to use case diagrams but a lot of information is lost during this transformation. This is due to the nature of the use case that only captures the interaction with the system whereas the ontology chart captures the structure and the ontological dependencies of the system. LIMITATIONS Some of the weaknesses of this transformation of ontology charts to use case include: that it cannot identify extend associations and it can only deal with limited cases of include associations. It can only treat agents with communication acts or relationships associated with them. It cannot deal with agents that have another agent as their antecedent. It offers a limited treatment of entities as it only includes them in the transformation if they participate in a communication act or relationship with an agent. Any other association among the semantic units apart from the cases described in the proposed transformation is ignored. Lastly, the auto-generated text of the labels needs corrections. Hence with more research these weaknesses could be addressed and an auto-generated use case could show a simplified view of the system. Other UML2 diagrams such as sequence diagrams could be auto-generated but more research is needed in this direction. CONCLUSIONS The main benefit of transforming ontology charts to use cases is that use cases can show the interaction between the users and the system. This paper proposed and illustrated a method and transformation rules for transforming ontology charts to use cases. The key idea behind this transformation is that agents are transformed to actors, relationships and communication acts to use cases, entities to text and part of the label of the relationship or communication acts use cases and the determiners are ignored. Due to the incompatibilities of the two models a fair number of information is lost during the transformation. Further research could possibly limit the amount of lost information and it is the wish of the authors that other researchers in the area could build on this proposal and improve the transformation.

76 Model-Driven Business Process Engineering

Tsaramirsis and Yamin

ACKNOWLEDGEMENTS This work would have not been possible without the work of Ronald Stamper and Yasser Ades on MEASUR methods and semantic analysis. An important role was also played by the work of all the people who developed and tested semantic analysis and ontology charts. CONFLICT OF INTEREST The authors confirm that this chapter contents have no conflict of interest. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

Ades Yasser. Semantic normal form: Compliance. University of Twente, 1999. Yasser Ades, Farouk Ben Umar, Iman Poernomo, and George Tsaramirsis. Mapping ontology charts to uml class diagrams: an snf preserving transformation. In ICOS2007. University of Reading, 2007. Yasser Ades, Manos Nistazakis Iman Poernomo Mohammad Yamin George Tsaramirsis, Navid Karimi. Implementing snf-compliant software: Mda and native technology. In Proceedings of ICISO 2009, pages 71,78. ICISO, 2009. Anneke G. Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven Architecture: Practice and Promise. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003 Ronald Stamper. Knowledge as action: a logic of social norms and individual affordances, gowerpress. 1985. Ronald Stamper. Measur methods of theory and analysis of information systems. In Proceedings of IWRA 2008, pages 135-160, London, 2008. PEARSON. Kecheng Liu. Semiotics in information systems engineering. Cambridge University Press, New York, NY, USA, 2000. George Tsaramirsis and Iman Poernomo. Prototype generation from ontology charts. Information Technology: New Generations, ITNG, 2008. Iman Poernomo, George Tsaramirsis, and Naibai Zheng. Coarse-grain architectures from business requirements: an organsational semiotics approach. In ICISO2009. Aussino Academic Publishing, 2009. Mohammad Yamin, Naibai Zhang Manos Nistazakis, George Tsaramirsis. Transformation of semantic analysis to com+ business requirements using mda approach. Journal of Service Science and Management, 2010. Iman Poernomo, George Tsaramirsis, and Mohammed Yamin. Ontology based uml2 component architecture generation. In the proceedings of ICISO2010, 2010. George Tsaramirsis, Bridging the Divide: Transforming Business Requirements into Component-Based Architectures PhD Thesis, King’s College London, 2011 OMG, UML superstructure, version 2.1.1. OMG document formal/2007-02-03, 2007. OMG, Meta Object Facility (MOF) Core Specification, OMG document formal/06-01-01, 2006.

Send Orders for Reprints to [email protected] Model-Driven Business Process Engineering, 2014, 77-108

77

CHAPTER 5 An Analysis of Enterprise Architecture Frameworks Faisal Almisned* Department of Informatics, King's College London, Strand, London, UK Abstract: An Enterprise Architecture (EA) framework provides an enterprise with the capability to develop an assortment of architectural representations. It usually offers consistent terminologies, suggested models, expected outcomes and a method driving the development of EA. An EA framework enables enterprises to recognize and evaluate inconsistencies or limitations; to facilitate distinguishing and addressing them. A number of frameworks are offered for use at present; their purposes, scope and inner organization are different. Various obstacles will face any enterprise attempting to employ an EA framework to facilitate its objectives. The most crucial decision is to choose a framework that matches the needs and qualities of the enterprise. This study offers an analysis of three dominant frameworks that could afterwards be utilized for guidance in the choice of employed EA Framework that address the required features.

Keywords: Enterprise architecture frameworks, enterprise architecture, analysis, comparison. INTRODUCTION The high level of attention paid to architecture for industrial products, throughout the industrial era, enabled the creation and development of these products. The same high level of attention must now be paid to architecture for enterprises, throughout this information era. This is a necessity because enterprises are changing rapidly and escalating in complexity. Existing complex organizations face obstacles reacting to different kinds of change. One of the main causes is the absent awareness about the complicated structure of certain entities inside the enterprise. This knowledge is usually preserved in the minds of individuals or departments accountable for the direct processing of this knowledge. Loche has

*Address correspondence to Faisal Almisned: Department of Informatics, King's College London, Strand, London, WC2R 2LS, UK; Tel: 0207 848 2005; Fax: 0207 848 2851; E-mail: [email protected] Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

78 Model-Driven Business Process Engineering

Faisal Almisned

stated that “Enterprise Architecture (EA) is the process used by a business to make explicit representations of enterprise operations and resources, rather than relying on implicit notions or understanding in individual managers’ heads” [7]. A few factors draw attention towards the key role EA plays in modern enterprises. These factors include increasing legal regulations, customized client requirements and shorter time to markets. An example of the regulations is the Sarbanes Oxley Act that obliges enterprises to plan and document their financial architecture [8]. Enterprise architecture can be utilized to be a means to achieve strategic objectives of an enterprise. One of these objectives is to adapt and respond to a frequently changing environment. Another objective is the representational association between business concerns and activities on one side and information systems on the other side. The availability of a holistic view on the enterprise is also an objective that can be gained from EA. The significance of utilizing EA is observable due to the clear understanding of resources and agents engaging with the enterprise. In addition, the clear representation of an enterprise enables the enterprise to acknowledge its needs and development priorities. The key concern for an enterprise is not to foresee the future but to enable the achievement of that future, which is facilitated through the use of EA. Furthermore, the clear understanding of all formerly implicit information is a huge advantage to know the accurate abilities and processes’ complexity. One more benefit from EA is aligning business goals and processes with technological infrastructure. Enterprise Architecture Management (EAM) builds an architectural representation of the existing state of the enterprise, accompanied with the planned state of approved projects and the future state of intended objectives. This feature facilitates a controlled evolution of the enterprise. Enterprise architecture eases the communication about the key elements and functioning of an enterprise. This paper will first introduce a short explanation of Enterprise Architecture, accompanied with its key terms and elements. Then, Enterprise Architecture frameworks will be defined. Afterwards, this paper will offer an inclusive

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 79

description of three frameworks, which engage in this analysis. Then, a comprehensive comparison of these three frameworks will be presented. ENTERPRISE ARCHITECTURE Many governmental [15, 16], standardisation [13], technological, academic [1719] and business authorities have defined enterprise architecture. Every single authority has defined EA and proposed an approach to manage EA. There is no one definition that everyone agrees on. However, they are widely united about the structure of main constituents and the overall purpose of enterprise architecture. Here is a list of the most important definitions. According to Meta group, EA is “the holistic expression of an organisation’s key business, information, application and technology strategies and their impact on business functions and processes. The approach looks at business processes, the structure of the organisation, and what type of technology is used to conduct these business processes” [10]. While USA Federal CIO Council has defined enterprise architecture as “ a strategic information asset base, which defines the business mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs” [11]. The Open Group has stated that “Enterprise architecture consists of defining and understanding the different elements that make up the enterprise and how those elements are interrelated” [13]. Zachman has defined EA as “the set of representations required to describe a system or enterprise regarding its construction, maintenance and evolution” [1]. “Enterprise architecture is a relatively simple and straightforward model, framework, or template that can be used by everyone within your enterprise to assess how things are going, to facilitate their work, and to design new projects”, according to Egan [12]. “Enterprise architecture is a complete expression of the enterprise; a master plan which acts as a collaboration force between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as

80 Model-Driven Business Process Engineering

Faisal Almisned

information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks”, as explained in Schekkerman’s book [5]. Main Terms in Enterprise Architecture Management (EAM) ARCHITECTURE is a term that describes the structure of elements or components defining a system. In addition, it describes the associations among these elements. It also includes the rules guiding the design of the structure and its development. An ELEMENT is a constituent under the subject of technology, stakeholders, processes and business. Instances include business goals, enterprise units, applications and infrastructure. Furthermore, high-level hardware components can be an instance of an element. ENTERPRISE is any set of organizations with one foundation or/and with shared objectives. Under this definition, a unit within an organization can be an enterprise; also a group of organizations with shared goals can be an enterprise. BASELINE ‘current’ enterprise architecture depicts the current state of the enterprise using several means. It is also called ‘As-Is’ enterprise architecture. The state encloses the technological infrastructure and the existing business activities. TARGET ‘future’ enterprise architecture depicts the upcoming state of the enterprise. It is also called ‘To-Be’ enterprise architecture. The state is derived from enterprise objectives and plans for business and technology. It shows the effects on the enterprise infrastructure and business practises. TRANSFORMATION PLAN describes the utilized practice to transform the current EA to the target EA. An example is different scheduled activities, which can be simultaneous or inter-reliant. In addition, it illustrates gradual stages of the progress. It is also called sequencing plan. The transformation plan takes a document form. EA RESULT includes all means utilized to illustrate the enterprise structure and its external environment; involving all models, charts and different representational descriptions. They are also called EA products.

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 81

There are few kinds of architectures covering different aspects of an enterprise. The classification of the main distinct architectures will be provided in Fig. 1. Shared aspects exist amongst different architecture kinds. They all utilize models expressing structures of different elements. They all aim to ease the communication and analysis about elements represented in their structure. New architecture perspectives are rising to concentrate on specific aspects of an enterprise, such as security.

Figure 1: Architectures classification.

A successful EAM should generate architecture comprising the following features. A shared image of the target state of the enterprise should be sustained amongst business and IT to maintain the alignment between them. The strategic business objectives must be reflected in the target architecture. A good representation of the enterprise is achieved when there is no need to remove any element from the architecture, while additions can be made during future development stages. Changes can be added if the structure is maintained simple to a certain degree. In the architecture, connecting external bodies should facilitate delivery of clients’ requirements quickly. Maintaining a technological understanding of the enterprise’s needs and capabilities should help to ensure a

82 Model-Driven Business Process Engineering

Faisal Almisned

good response to frequent changes. It is useful to merge and link different business processes in the enterprise. A thorough representation of the enterprise’s state will clarify where different processes should be modified. A good enterprise architect must ensure the availability and consistency of information. Resources should not have any level of overlapping, such as in different technologies, applications and knowledge. Instead, the reuse of these resources should be enhanced. The realization of the previously mentioned features requires an EA framework ensuring the following qualities. An EA framework should not only be inwardly centred. It has to cover all sides of the extended enterprise, in order to consider stakeholders, standardisation, governmental and business bodies that have influence on the enterprise. In short, an enterprise architecture should be holistic in scope. Another important quality of enterprise architecture is to be established collaboratively. This means that representatives from all stakeholders, with different perspectives, should participate in building the EA. The represented alignment between business and IT should be understandable and visible to all stakeholders. In addition, EA should be a way to show the business value from applying the proposed solutions. Analytical methods should be offered by EA frameworks to maintain the evolution of EA over time. Suggested solutions must be accompanied with means to evaluate, test and reflect them to the facts on ground. However, an argument can be made that this feature might increase the complexity of EAM and exceed its domain. EA frameworks should not make any assumptions about the use of a specific Implementation approach [2, 5, 20]. EA will be described in different architectural representation levels. The degree of elements’ details described in different architectural representation levels should reflect the general aims intended by the architectural description. The key aims concentrate on accomplishing the alignment, cooperation, validation and risk analysis. The details should not attempt to cover everything that exists. However, the level of detail should enable the design of holistic enterprise architecture, which accomplishes required purposes of this architecture. The previous points should be the measure of a good EA framework that can be adapted to different business domains [2, 5]. Different architectural representation levels usually follow the classification of key four layers; these layers are defined in the following section.

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 83

BUSINESS LAYER describes business activities, duties, associations and structure. The degree of elements’ detail in this level is limited to the point where their technological requirements can be determined. In addition, the described details must enable the evaluation of business performance. INFORMATION LAYER description should enable the identification of the needed security features and information interchange. It defines major information qualities to the business and to information flows. This extent of detail must enable the identification of similar qualities and relations, to bring them into line with the whole architectural representation. INFORMATION-SYSTEMS LAYER describes the needed solution’s design, characteristics and functions. The degree of detail in this level should be in harmony with the previous two layers. TECHNOLOGY INFRASTRUCTURE LAYER does not define how offered technological services are implemented. It just defines the provided services. Enterprise Architecture Frameworks The development of EA needs to be managed structurally rather than using habitual management methods. Indicating the significance of EAM, a number of frameworks have been offered for initiating an EAM in an enterprise. They were offered by research institutes [17], experts [1], governmental authorities [15, 16] and standardization groups [13]. The constituents of these frameworks differ in terms of suggested models, languages and structure. According to TOGAF [13], an EA framework is “a tool which can be used for developing a broad range of different architectures ‘architecture descriptions’. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks”. There are few outcomes expected from employing an enterprise architecture framework. It will ease decision making and analysis of development states. In

84 Model-Driven Business Process Engineering

Faisal Almisned

addition, it will be a key information asset to facilitate reforming the enterprise. Another advantage is an instantly obtainable documentation of the enterprise. An additional benefit is the ability to foresee the predictable condition of the enterprise due to the reduced complexity of knowledge. This is achievable because business functions are incorporated with all related information throughout the enterprise. Development solutions are provided faster with lower costs, due to growing reuse of enterprise’s resources. Decisions to reuse certain resources can be made easily with the existence of holistic EA. An additional advantage is the preservation of a widespread anticipated visualization of the enterprise, among technological and business parties. EAM charts technological development activities within an enterprise and visualize the activities’ roles in accomplishing enterprise’s objectives. This enables enterprises to identify inconsistencies and limitations. Systems and Software consortium has stated that “an Enterprise Architecture relates organizational mission, goals, and objectives to work processes and to the technical or IT infrastructure required to execute them” [9]. There are many difficulties associated with the introduction of EAM in an enterprise. First, neglecting existing initiatives in the enterprise is a common weakness of the structured evolution of EAM frameworks. Second, EAM frameworks do not usually provide a base to start building the framework from. Architects usually start with eliciting the requirements to initiate the architecture. Therefore, eliciting the requirements from individuals and bodies, without guidance, will produce data exceeding the needs of the framework. For example, asking a stakeholder about his needs can be more of wishes rather than concrete requirements affecting the enterprise’s productivity. Third, most existing frameworks can only be employed as a whole. This is bad because a framework can be so broad to cover matters exceeding an enterprise’s needs, or it can be too abstract. The lack of gradual introduction of the framework is another common aspect; if this is possible the framework will be more adapted to an enterprise’s maturity. Fourth, choices taken throughout the managed evolution of EAM needs to be documented. This is essential in order to ease the expansion of EA; an instance of these decisions is why particular agents should participate on certain processes.

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 85

A study by the Institute for Enterprise Architecture Developments has stated that EAM is a top concern to CEO’s and CIO’s [6]. Fast and big developments in technologies add to the confusion top management faces when they choose a solution matching their requirements and resources. These offered solutions have many points of overlapping and overstatements, the same can be said about different standards enforced on organization. This will add to the complexity of decision making process. EAM will help enterprises to realize consistent and realistic knowledge about its environment. For instance, top management in an advertisement company will be able to identify their rewarding markets and check if the enterprises’ current resources are sufficient to meet existing clients’ requirements. In addition, improved services’ requirements can be identified, such as new systems or technologies. A principle in designing enterprise architecture is to design with the awareness that there are many unknowns, such as new technologies and environmental matters. This sophistication of planning enables the enterprise to accommodate new changes. Another key principle is the continuous consideration of the enterprise’ larger context, such as outer environmental factors. EAM would not attempt to foresee the future but to provide the capability to adapt to any potential changes. Because it is impossible to take into account all potential upcoming changes. Schekkerman has urged EAM to be derived from enterprises’ strategic vision, stating that “this vision bridges the extant status of the firm ‘where it is?’ and its projected future status ‘where it wants to be?’ ” [5]. OVERVIEW OF FRAMEWORKS

DOMINANT

ENTERPRISE

ARCHITECTURE

The following are descriptions of three Enterprise Architecture frameworks, which are involved in this analysis. The structure of the three frameworks will be explained, in addition to the identification of their key features, goals and nature. Zachman Framework for Enterprise Architecture John A. Zachman first issued his enterprise architecture framework in 1987 [1]. He is regarded as the main innovator in the field [2]. Zachman has stated that the increased complexity of enterprises and the frequent change demands are

86 Model-Driven Business Process Engineering

Faisal Almisned

imposing the need for a structured expressive representation (the enterprise architecture) [3]. Zachman’s framework aims to look at information systems within an enterprise and the enterprise as whole from distinguished viewpoints. It aims to offer a view showing the relationships between all participating entities. It is a classification technique of an enterprise’s architecture. Zachman framework is classified in terms of understandable decomposition of information by participants and by basic questions. The Zachman framework has been utilized in several well-known enterprises, such as General Motors, Bank of America, and Volkswagen [21]. Zachman initially realised that various parties will be involved to control the development of an enterprise. In the early stages, Zachman’s thoughts were directed towards the development of Information systems only. Concerns of stakeholders will vary from high level business ideas and requirements towards low-level technological needs. Zachman has clarified one main principle, the team building EA should know that the produced EA will be affected by their perspective and from their objectives in building the EA (i.e., what they are looking to attain from EA). Zachman Structure The framework proposes six perspectives pointing how an enterprise representation should be viewed. Zachman has named them as the following: Planner, Owner, Designer, builder, Subcontractor, and User. The Zachman framework offers a scheme that utilizes the integration of two categorizations. The first is the basic questions composing the ground rules of communication; what, how, where, who, when and why. The combination of the outcomes of these inquires will form the inclusive description of complicated thoughts. The second categorization is based on the transformation from abstract presentation into more detailed ones. The second categorization will be in line with the proposed six perspectives. The integration between the two categorizations will form a six by six matrix, where the columns represent the first categorization and the rows represent the second categorization, (see Fig. 2). The intersection between the two categorizations is represented on each single cell. Every cell is distinctive; where an abstraction is represented and where the cell context prescribes the implication of the models’ description. Two abstractions are represented on each cell, an abstraction of a “thing” and an abstraction of a “relationship” [1]. The flow from

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 87

the first to the last row imitates the course of transforming a general thought into reality. Each row stands for the following consequently; identification, definition, representation, specification, configuration and instantiation. It can be seen that the top three rows represent business matters, while the bottom three represents technological matters. Zachman sees this as the main composition for Enterprise Architecture, where a frameworks can include the complete group of expressive descriptions related to an enterprise. Zachman framework is an ontology properly symbolizes knowledge within an enterprise as a set of components. In addition, it symbolizes the relationships among these components. Zachman framework considers the unambiguous expressiveness of an enterprise, as an essential condition to run and revolutionize that enterprise. Zachman states that his framework is only the ontology depicting the enterprise, isolated from the methodology guiding the transformation. The existence of this ontology will enable applied processes to be predictable and to generate replicated outcomes. The framework concentrates on guaranteeing that the views are properly established to offer a comprehensive representation, by describing the purpose of different views. The framework states that it does not matter in which order different views are created. Various perspectives, of the various stakeholders participating on the development of EA, will be reflected on one dimension of the framework (see Fig. 2). Zachman stated that a group of architectural representation is sufficient to develop simple products, such as a new building. However, there is a need for a more sophisticated representation to match the level of complexity of an enterprise [3]. Therefore, Zachman suggested the use of five architectural representations aside from the functioning systems. Each one of them will be placed on a single row. The first is concerned with the scope depiction, to cover the most general consideration aspects of the scope, magnitude and shape. The second architectural representation is focused on representing the requirements to achieve business goals. These requirements are extracted from high level stakeholders, in order to understand the perspective of people setting out the goals. This row is called the business model 'owner's view'. The third architectural representation contains the translation of the previous business model; it is called the system model 'designer's view'. The fourth row associates the system model with realty, by introducing constraints of any

88 Model-Driven Business Process Engineering

Faisal Almisned

nature, such as applicable technologies. It is called the technology model 'builder's view'. The last three architectural representations are vital because every single one shows stakeholders usually isolated from each other. The isolation will be minimized through the deep expressiveness. The fifth row is directed towards the real implementation acts. However, it does not represent the inclusive functioning product; it represents certain parts of the overall structure. It is called ‘detailed representation’ or 'subcontractor's view'. Every single architectural representation includes a distinct group of constrains, which will be accumulative from one model to the other. Therefore, constraints from different models have to be consistent. Zachman has encouraged designers, supervising the whole process, to detect any such weaknesses between different models and even rebuild some models to maintain the consistency. The previously described five models can be seen in the succession of rows in Fig. 2. The sixth row in the framework is supposed to present another perspective, which is an architectural description of the real functioning system from a user’s perspective. However, experience shows that it is more than depiction but physical objects [4, 7]. Various functional aspects need to be considered to formally describe an enterprise. These aspects include what units the enterprise deals with from every different perspective. Another aspect is how the enterprise will work on each level of technological details. A third aspect is where different systems of the enterprise are placed. A fourth aspect is who participate on certain objects at any level of the enterprise, including individuals and business units. Why certain activities are made and why they are important? This is another aspect. An additional aspect is when certain actions and decisions need to be made. Zachman has realised that different functional aspects require distinct nature of descriptions. Therefore, the second dimension of his matrix is designated to the earlier aspects; each one of them is presented in the sequence of columns. For each question, Zachman has suggested a primitive descriptive model. As seen in the final row of Fig. 2. These models are initiated based on which viewpoint a person is looking at the enterprise. These descriptive models are respected and considered in each cell of that column, varying according to different perspectives on different columns. Three examples are provided next to exemplify the contents of two columns and a row.

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 89

The next example attempts to clarify the use of these descriptive models. The suggested descriptive model for the 'What' column is 'Entity Relationship Entity' (see Fig. 2). The scope representation will contain a documentation of all entities significant to the business. The following cell in the owner's view will offer a diagram showing participating entities and their relationships. The relationships will indicate constraints and business rules, for instance, number of devices that can be bought by a single customer. The next cell in the designer's view will contain another view on entities in order to relate what is planned to reality, for instance, entities as records associated with data relationships. Then, the choice of which system to be used is made on the builder's view; here it will be determined what kind of database will be used. The type of representation is determined too, such as considering relationships as keys. For this example, SQL is presented in the subcontractor's view.

Figure 2: Zachman Framework [4].

90 Model-Driven Business Process Engineering

Faisal Almisned

Another example for the content of the ‘Who’ column is provided here. The first cell can contain a list of all participants in any activity related to the enterprise. The second might represent the participants in charts, and how their productivity is associated. The third cell could depict a human interface architecture that shows the roles and deliverables of participating parties. The fourth cell can contain a graph detailing the users of the technology and their jobs. The fifth cell can describe the identity of system’s users and their authorities on identified transactions. Another example is provided next for a sequence of cells in the same row ‘scope’. The ‘scope’ row usually attempts to explicitly clarify the business drivers and needs originated from outside the enterprise, in addition to describing the business functions. The first cell in the row can contain a list of all units concerning the enterprise, such as products, markets and services. The second cell could provide a list of all functions done by the enterprise, such as manufacturing, marketing and designing. The third cell would include a documentation of all business locations, such as branches and warehouses. The fourth cell could list all events and meetings aligned with certain functions, such as schedules of projects. The fifth cell would contain a list of institutes affecting the enterprise, such as partners and suppliers. The sixth cell would normally enclose a documentation of high level business goals. Various stakeholders have different viewpoints on every distinct architectural representation. Therefore, the intersection between different descriptions and different viewpoints introduces Zachman six by six framework. Every single cell in the matrix is unique and self-contained. At the same time, all cells are related with some type of connection. The grouping of all cells in a single row will provide an inclusive view on the enterprise from a particular perspective. In addition, as clarified in the earlier example, a cell needs to be aligned with the cells directly on top of and underneath it. Zachman framework offers a technique of classification that associates business matters to technological matters. The framework insists that it does not offer a single architecture for the whole enterprise, but rather a group of architectural representations that synthesise, affect and add to each other. Zachman framework offers the utilization of suitable distinctive notations for every cell independently. However, Zachman attempts to

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 91

persuade others to use distinguished common language to represent the contents of all cells 'conceptual graphs' [4]; Zachman suggested the use of that language in a further development of his framework. There is not a single or an ideal way to start building the framework. However, there is a set of recommendations suggested to gain proper representation. The columns’ order is not mandatory, but depends highly on the cause of initiating full architectural representations. On the other hand, the order of rows is mandatory to go through a logical succession of perspectives, from a high level business view up to a low level technological perspective. It is recommended to start logically from the top left cell in the framework. The contents of cells might already exist in form of documentation, schedules, process guides or graphs. With or without utilizing the existing documentation, certain gaps will be found as one goes through the framework. Alignment has to be made and constraints need to be consistent. Identified knowledge requires being explicit to larger number of participants. The classification scheme provided by the framework aims as well to facilitate the retrieval of related information. Enterprise Architecture Management Pattern Catalog (EAMPC) An enterprise launching EAM will find that a variety of aspects is missing regarding the way the approach is specified. The majority of the concerns deriving EAM are reoccurring in most enterprises [17]. The core solutions for these concerns would offer a good base to guide the management of these concerns. Nevertheless, the core solutions should be presented in a way which enables the utilization of these solutions in different ways to handle the same concerns in different enterprises. In addition, the core solutions must be derived from best practises. EAM Pattern Catalog provides a framework for EAM, covering concerns that affect service management, business objects, architectural standardization and application landscape [17]. EAMPC is a set of methodologies that have time after time shown outcomes better than any other methods trying to address the same concerns. These methodologies are supplemented with information models identifying consistent terminologies, along with viewpoints for visualization.

92 Model-Driven Business Process Engineering

Faisal Almisned

Pattern is the main notion of EAM Patterns Catalog. A single pattern defines a common reoccurring concern and how this concern is influenced by different contexts and difficulties. Moreover, a pattern describes the essence of the solution to the defined concern based on best practises. Yet, solutions will be offered in a general manner to be reused distinctively numerous times. A pattern identifies the connections between different contexts, where concerns are founded. Their designated solutions are provided based on context at hand. EAMPC Structure EAM patterns catalog has proposed three types of patterns, (see Fig. 3). First, a methodology pattern identifies the followed procedure to deal with certain concerns. Anticipated contexts will be stated as guidance for applying procedure steps, combined with the concerns where these sequences of steps can be applied. The form of different procedures ranges from visual representation to any level of formalization. The explanation of all steps in the methodology distinguishes this approach from other frameworks as they overlook some details of a number of steps. Second, a viewpoint pattern offers a description of how documented data should be viewed, along with ideal example views to ease the specification of viewpoints. Therefore, this pattern will offer a language utilized by methodology pattern. Third, information model patterns provide the potential structures that would be represented in viewpoint patterns, i.e. a model of the language provided in viewpoint patterns. Different means can be used to describe an information model pattern, such as UML structures, MOF or natural language.

Figure 3: Pattern’s relation.

Unlimited number of patterns can be proposed by different parties and individuals. However, a certain number of these patterns will be considered, by literature and expertise, valuable and related to the subject of EAM. EAM patterns Catalog only considers the ones approved, by literature and expertise. In addition,

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 93

patterns have to maintain consistent terms and information structure in order to facilitate any form of integration and comparison. These patterns will be the core building blocks assisting the introduction of EAM in any enterprise. These building blocks will be adapted to fit existing concerns at any enterprise present needs. Therefore, EAM patterns Catalog “focuses on addressing specific concerns and does not build an all embracing model that is meant be used for all thinkable concerns” [17]. This approach manages concern-driven and fully-acknowledged information model. Furthermore, this approach disregards the customary holistic, generic and huge approaches. This point will lessen the need for immense efforts and costs to introduce EAM. The nature of this approach will enable continues enhancement and addition to the Catalog, in order to publicise documented best practises. Thus, any enterprise, introducing EAM, can access, select and adapt common concerns and their associated patterns. Furthermore, an enterprise can navigate through documented problems and solutions. This navigation is based on categories of EAM concerns offered by EAMPC. EAM patterns Catalog gathers and classifies problems and their solutions according to the following categories; Technology Homogeneity, Business Processes, Application Landscape Planning, Support of Business Processes, Project Portfolio Management, Infrastructure Management and Interface, Business Object, and Service Management [17]. Each category contains concerns and the procedures to tackle them regarding that particular topic of EAM. If the enterprise is faced with any matter affecting the uniform nature of infrastructure supporting the application landscape, then this enterprise can navigate through the Technology Homogeneity set of methodologies. Second category includes methodologies associated with any business issue at any level of abstraction. If there is a concern linked with the development or composition of the application landscape, then the enterprise can search among the Application Landscape Planning set of methodologies. A group of methodologies focuses on how IT sustains an exact business process can be found on a category called Support of Business Processes. Furthermore, Project Portfolio Management can be searched if there is a new project influencing the application landscape. In addition, Infrastructure Management deals with concerns about the technical infrastructure influence on the relation between applications and business processes. All

94 Model-Driven Business Process Engineering

Faisal Almisned

methodologies concerned with service oriented architecture can be found in the last category, embracing communicated data and business objects. Different patterns can be initiated by various bodies. These patterns will be built on assumptions applicable within the scope of these patterns only. However, this will cause unacceptable discrepancy among various patterns, if an enterprise tries to concurrently enclose a set of patterns as an EAM approach. EAM patterns catalog takes certain measures to ensure that no conflicts or inconsistency will occur on the phase of integration. Different steps are taken to ease a smooth integration of the distinct three types of patterns. This feature gives EAMPC an advantage over random patterns, which are not aligned with each other. The next three paragraphs will provide some highlight on patterns’ integration aspects. Integrating methodology patterns have to manage the assortment and interaction among a group of methodologies aiming to realize a group of concerns. A process model has to be identified to clarify the steps to be taken to control the EAM practice. An act, demanded from the team launching EAM, is to document all assumptions made about the procedure of each pattern. This will enable the integrator to consider these assumptions. These assumptions vary from the style of the communicated information to the accessible resources. Integrating viewpoint patterns usually does not require a great effort. Because exemplary viewpoints will show how a single viewpoint should address certain concerns without any dependability on other viewpoints. This self-reliant nature of patterns will enable the generation of more abstract viewpoints layers. Integrating information model patterns can be faced with few difficulties especially if these patterns are originated from different sources. Familiarity with modelling techniques is a necessity for this integration. Second, originators must maintain consistent terms and information organization. Sensible naming must be supplemented with clear definitions of respective classes. Integrator must consider constraints of independent patterns to enable single ones to be implemented individually, for example, modifying multiplicities for a common class in different patterns. EAM patterns catalog can be utilized in three different ways. First, it can be used as a radical turnaround to the organization through the introduction of EAM. This will be derived by the enterprises concerns, thus navigating the list of concerns in the catalog will be the starting point. Each

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 95

concern in the list will refer to a methodology pattern that employs one or few viewpoint patterns to visualize some sides of EA, (see Fig. 4). The latter step will involve the reflection of some information model patterns. The last action is to integrate involved patterns into a customized framework of EAM.

Figure 4: A View on the Catalog.

The second way to utilize EAMPC is to be used as a mean to evaluate and improve an established EAM framework. This is done by examining and comparing best practises offered in the catalog supplemented with concerns from real enterprises. For instance, the well documented steps and visualization examples can be utilized by other approaches. The elicitation of an enterprise’s requirements can be inspired by thoroughly assessed and solved concerns. The originators of this approach claim that this approach might be used also as the base for research in EAM. They state that the catalog enables the accumulative development on patterns, rather than leaving each source to initiate their ideas from scratch [17]. The Open Group Architecture Framework (TOGAF) The Open Group is a “vendor and technology-neutral consortium with the objective to foster information flow via open standards for enterprises”[13]. The Open Group Architectural Framework (TOGAF) was originally derived from USA Department of Defence’s Technical Architectural Framework [13]. TOGAF was launched by The Open Group in 1995. TOGAF’s mission is to offer a

96 Model-Driven Business Process Engineering

Faisal Almisned

framework to design, validate and develop EA. TOGAF is well-known and widely-used; therefore, key participants in the field have integrated TOGAF in their tools. Moreover, there is a TOGAF 9 method plug-in for the open source eclipse process framework composer tool, which is an advantage [13]. TOGAF concentrates on business activities that are essential to the enterprise’s objectives. TOGAF does not attempt to enforce a group of EA development principles but to offer description of good ones. TOGAF offers Enterprise Continuum, which is a repository containing architectural representations means, such as different models. In addition, TOGAF offers Resource Base containing needed guidance for the utilization of the framework, for instance, pre-examined templates. TOGAF states that “Enterprise architecture is about understanding all of the different elements that go to make up the enterprise and how these elements interrelate” [13]. In addition to TOGAF’s definition of EA framework ‘as in section (1.2)’, TOGAF also identifies two fundamentals of any EA framework. First, the identification of products achieved from initiating the framework. Second, EA framework could preferably describe how the initiation of the framework has to be completed, which is not offered by all frameworks [13, 16]. TOGAF Structure TOGAF is formed from six core elements; architectural development method (ADM), content framework, enterprise continuum and tools, ADM guidelines and techniques, and two reference models. First, ADM attempts to provide an iterative approach managing the development of EA. This iterative approach involves the employment of an introductory phase followed by the appliance of eight interrelated iterative phases. Second, the content framework is a conceptual metamodel, which is utilized to depict elements of the enterprise. Third, enterprise continuum and tools offer an outlook on EA repository, this allows the reuse of offered descriptions and permits restructuring EA. Fourth, ADM guidelines and techniques support the utilization of ADM, involving aspects such as adaptability, construction and features of certain architecture domains. TOGAF reference models embrace the last two elements of TOGAF. Fifth, the first reference model could be utilized to construct any architecture; it is called the TOGAF foundation

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 97

architecture model. Sixth, the second reference model deals with the demand to compose an infrastructure based on reference designs; it is called the integrated information infrastructure reference model. TOGAF’s suggested structure is aligned with the rest of EAM approaches regarding the distinctive viewpoints on architecture layers, as defined in section (1.2); business, information, information systems and technology infrastructure. Architectural Development Method (ADM) is the key element of TOGAF. ADM mainly is what TOGAF is known for. ADM defines the nine phases proposed by TOGAF to develop EA, (see Fig. 5). Any group intending to introduce EAM should refer to these phases, by adapting these phases on different levels of the enterprise. ADM is an iterative generic approach to develop EAM. TOGAF offers guidelines to drive how the adaptation should be done, which is introduced in ADM guidelines and techniques. However, this section needs extensions to provide more in-depth guidance [16]. ADM does not impose orders on EA developers regarding the degree of details at different organization’s levels or what elements should be covered on each level. It respects that every specific enterprise can adapt the approach to their needs. However, this feature is not entirely specified and proved according to critics of TOGAF framework [Buckle].The next section will describe the nine ADM phases: PRELIMINARY FRAMEWORK AND PRINCIPLES, this phase is used to identify the used framework and the rules guiding the development of EA, in order to underline the basis of architecture inside the enterprise. All activities in this preliminary phase are concerned with the groundwork and initialization of EAM. Issues considered in this phase include EA team, potential tools and followed EA principles. ADM CYCLE consists of the next eight phases: ARCHITECTURE VISION, this phase describes abstractly without details the baseline EA and the target EA, covering technical and business viewpoints. The scope of EAM’s effort will be identified. Key outcome of this phase is the identification of related stakeholders and their interests. The business, information systems and technology architectures will be developed in the next three phases respectively.

98 Model-Driven Business Process Engineering

Faisal Almisned

BUSINESS ARCHITECTURE, this phase studies the variance between baseline EA and target EA, concentrating on business viewpoint. INFORMATION SYSTEM ARCHITECTURE, this phase attempts to recognize the needs related to information and applications in order to describe desired architecture satisfying these needs. TECHNOLOGY ARCHITECTURE, this phase is very important and it requires huge effort to be completed. Eight steps are performed to provide the basis for developing EA. These steps are baseline creation, views selection, forming models, services choosing, business objectives determination, criteria identification, architecture description and accomplishing gaps investigation. OPPORTUNITIES AND SOLUTIONS, in this phase, implementation options are assessed and chosen. This phase attempts to align the earlier three architectures. In addition, this phase concentrates on deriving various initiatives; these initiatives demonstrate clearly the transformation nature from As-Is architecture to To-Be architecture. This shows the need to describe the transitional ‘planned’ architecture, showing the EA state with all approved initiatives. MIGRATION PLANNING, this phase studies different proposed initiatives. This phase checks any overlapping or reliance among initiatives, to determine their priorities. The current, planned and target architectures outline the input to this phase. This phase plans the timetable to accomplish the intended architectures. A key contribution is to give each initiative a business value; this allows the prioritization of various initiatives in line with the proposed plan. IMPLEMENTATION GOVERNANCE, this phase administers initiatives’ implementation, concentrating on what is called architecture contract. Approved projects, which serve the realization of the intended architectures, will be implemented in this phase. A key outcome is the recognition of utilized resources and skills. ARCHITECTURE CHANGE MANAGEMENT, this final phase is concerned with the constant observation of changes in latest technology, performance targets

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 99

and business matters that might initiate further developments. It ends a cycle and arranges the launch of a new iteration. REQUIREMENTS MANAGEMENT PROCESS is essential to every phase of ADM as it names, records and communicates requirements with everyone of them.

Figure 5: TOGAF Architectural Development Method [13].

ADM is a broad method that deals with EA at all particularized different enterprise’s levels. Its approach maintains EA’s evolution by means of Enterprise Continuum, regarding it as its knowledge base. ADM phases describe properly steps to be taken, however it allows EA developers, regarding implementation decisions, to adapt their needs and decide what the needed products out of this

100 Model-Driven Business Process Engineering

Faisal Almisned

design are. TOGAF suggests that all decisions made regarding the design of EA to be documented in order to allow the traceability of these decisions. TOGAF offers exemplary instructions and guidance to support ADM phases [13], covering the following topics; architectural principles, data analysis, organizational contexts and capability-based planning. TOGAF has suggested three dimensions for segmentation in order to arrange the management essence of ADM [13]. The segmentation of EA can be done with reference to architecture depth, time and scope. The segmentation of EA will be in reference to the included kinds of architecture, in respect to the architecture depth. The segmentation of EA will be in reference to the covered states of architecture ‘current, planned and future’, in respect to time. The segmentation of EA will be in reference to business locations, functions, units and participants. TOGAF points at the value of adapting the management essence, however, TOGAF does not provide any means to carry out this configuration. Technical Reference Model (TRM) depicts system’s components and its services using units including application, application platform and communication infrastructure; it is indicated by the Enterprise Continuum. TOGAF has proposed the use of many different views on the enterprise. The views are Business Architecture View, Data Architecture View, Application Architecture View, Technology Architecture View, System Engineering View, Enterprise Security View, Enterprise Manageability View, Enterprise Quality of Service View and Enterprise Mobility View. Enterprise Continuum also offers the Standard Information Base, which is a database of information, regulations and standards, such as guidance for designing architecture views. A meta-model of the enterprise contents is also introduced to enable the description of the enterprise architecture, it is called TOGAF content framework. This metamodel is provided to illustrate which elements of an enterprise have to be considered. Many concepts that can be used to describe and document the enterprise, is contained in this meta-model; accompanied with a group of preidentified relations and properties. Concepts covering all architectural layers are included in the core metamodel, as illustrated in Fig. 6. Furthermore, six additional metamodel extensions are introduced by TOGAF. These extensions are introduced to support the description of a number of divisions; governance,

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 101

services, process modelling, data, infrastructure consolidation and motivation. These extensions are supported with guidance on when to use them and what to expect from using them. Criticism is made against TOGAF stating that prescriptions of its information model is too abstract and lacks the appropriate reflection of potential applied constraints and properties, even though some critics admits some of these points were addressed after the introduction of TOGAF modular structure in the new version [16].

Figure 6: TOGAF content framework ‘core metamodel’ [13].

The open group has issued a new version of TOGAF (version 9) in 2009 [13]. More features were launched to back the structure of EAM directed to adapt for certain demands of a particular enterprise. The gradual introduction of the framework and enhanced usability were key factors to launch a modular structure. Comprehensive and detailed guidance were introduced to govern the process of

102 Model-Driven Business Process Engineering

Faisal Almisned

EAM. In addition, a content framework, that enhances consistency, and architectural styles were introduced [13]. ANALYSIS AND COMPARISON OF EA FRAMEWORKS For the purpose of this analysis, Enterprise Architecture Framework is a tool utilized for initiating a wide variety of architectures, which enclose the required knowledge of an enterprise. This tool must offer means for retrieving, managing and presenting the knowledge in the enterprise. In addition, it should define the outcomes expected from the practise, accompanied with inclusive description of what need to be performed to achieve these outcomes. The following analysis is based on the previously identified boundaries of EA Framework. Generally, the analysis and comparison of different EA frameworks are faced with obstacles regarding different nature of intended usage and scope. Therefore, any analysis should identify the foundation of its comparison. This analysis will be based on distinguishing different frameworks in regard to their focus area, perspectives, goals, inputs, outcomes and abstractions. See Tables (1, 2 and 3). Table 1: The study of Zachman framework Features

Zachman Framework

Issuing Organization

Zachman Institute / Proprietary framework

Issuing Date

1987

Tools Support

None

Centre of attention

Zachman mainly focuses on the area of modelling, with monolithic organization of knowledge

Perspectives

-Very clear and comprehensive -Capable of representing various views of different stakeholders -Could be the base of views classification and consistent terminologies offered by different frameworks

Inputs

-It explicitly supports Business requirements. -It does not support Technology inputs. -It partially supports Business drivers, information system environment, current architecture and non-functional requirements.

Outcomes

-It explicitly supports Business, System, Information, Computation, and software processing models, in addition to platforms. -It does not support software configuration model, transitional design and design rational. -It partially supports Implementation model and non-functional requirements design.

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 103

Table 1: contd…

Abstractions

-Two distinctive types of abstractions are only established in this framework, these two abstractions are represented in the when and why columns. They clarify the time and justification of system’s features. -Zachman properly classifies the needed abstractions to offer a comprehensive look on the enterprise. What is needed to be presented is described. However, it is not supported with the required methodologies.

Key Publications

[1] [4]

Table 2: The study of TOGAF Features

The Open Group Architecture Framework (TOGAF)

Issuing Organization

The Open Group / Consortia-developed framework

Issuing Date

1995

Tools Support

TOGAF 9 Method Plug-in for the Eclipse Process Framework Composer tool [13]

Centre of attention

TOGAF mainly focuses on utilizing a driving method with explicit organization

Perspectives

- Perspectives are clear regarding Business Architecture View and Technical architecture views -Views are not distinctively directed towards the scope, subcontractor and user perspectives [5].

Goals

-It explicitly supports Architecture analysis, definition, understanding, process, evolution support, standardization, knowledge base, verifiability, models and design rational. -It partially supports design tradeoffs.

Inputs

-It explicitly supports Business requirements, Technology inputs, Business drivers, information system environment, current architecture and non-functional requirements.

Outcomes

-It explicitly supports Business, System, Information, Computation, Implementation, software configuration and software processing models, in addition to platforms, transitional design and non-functional requirements design. -It partially supports design rational.

Abstractions

-The ‘how’ or ‘functionality’ abstraction is addressed with the guidance concerning the decision-making provided by TOGAF. -The ‘who’ or ‘people’ abstraction is addressed partially with the guidance concerning the IT-resources provided by TOGAF. -Other abstractions are not explicitly and thoroughly addressed, while generally the architecture principles guidance supports the representation of abstractions.

Key Publications

[13, 14, 22]

104 Model-Driven Business Process Engineering

Faisal Almisned

Table 3: The study of EAMPC Features

Enterprise Architecture Management Patterns Catalog (EAMPC)

Issuing Organization

Technical University Munich / Academia-developed framework

Issuing Date

2007

Tools Support

As this framework was derived from the software cartography project in the university. System cartography tool is provided [17].

Centre of attention

EAMPC mainly focuses on utilizing patterns as the building blocks of EA, starting from concerns as the deriving points

Perspectives

-Perspectives are driven from the categories of different concerns. -The seven offered categories are classified according to EAM topics, however they can be matched with the six perspectives that are offered by Zachman.

Goals, Inputs, and Outcomes

EAMPC is based on the assertion that any required goal, input or outcome can be addressed by introducing a pattern that resolve any existing need.

Abstractions

-Since EAMPC is not a framework that is introduced as a whole; abstractions are not explicitly described. -Different methodologies and information models offer guidance on different abstractions required for enterprise’s architectures.

Key Publications

[17]

For the purpose of this analysis, Enterprise Architecture Framework is a tool utilized for initiating a wide variety of architectures, which enclose the required knowledge of an enterprise. This tool must offer means for retrieving, managing and presenting the knowledge in the enterprise. In addition, it should define the outcomes expected from the practise, accompanied with inclusive description of what need to be performed to achieve these outcomes. The following analysis is based on the previously identified boundaries of EA Framework. Generally, the analysis and comparison of different EA frameworks are faced with obstacles regarding different nature of intended usage and scope. Therefore, any analysis should identify the foundation of its comparison. This analysis will be based on distinguishing different frameworks in regard to their focus area, perspectives, goals, inputs, outcomes and abstractions. Comparison between different frameworks can be done with reference to how each framework relates and covers Systems Development Life Cycle. The widespread five phases of the cycle can be the basis of this comparison; these phases are planning, analysis, design, implementation and maintenance. On the

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 105

whole, EA frameworks specify aspects of the planning and analysis phases; providing and supporting all views. On the other hand, the manner in which the system will be developed is not specified. EA frameworks can be seen as the guidance that will be applied in the cycle. Therefore, frameworks can be easily harmonised with the planning phase. Whereas, the majority of EA frameworks fail to cover aspects of the maintenance phase. Zachman framework appears to encompass all phases of the cycle despite maintenance. TOGAF principles and guidance materialize aspects of the cycle’s phases despite the lack of clear handling of maintenance. Aspects of the planning phase are not explicitly specified in TOGAF. TOGAF guidance and rules sustain decision making, IT resources, architecture standards for planning and performance. The next is an instance of how a single framework’s view can cover partial aspects of a phase in the cycle. The planner view in Zachman framework will contribute in sketching a system that achieves core goals and in providing an inclusive view on the enterprise. These are some of the intended aims of the planning phase. The majority of EA frameworks propose suggestions about the representation of different abstractions. However, most of them do not offer needed means and methodologies to represent these abstractions [5]. All three frameworks provide description of the knowledge required by the framework. The distinction between these frameworks is more observable regarding the utilized technology and the actual features of the framework; where various frameworks offer in-depth architectures while some offer abstract architectures. For instance, to simplify the cause of the ‘who’ or ‘people’ abstraction, all organisational associations affecting the functionality of the enterprise must be represented in this abstraction. The features of business and technical architectures provided by TOGAF are an important advantage of the framework. Nevertheless, these architectures do not offer inclusive details on aspects of planning and continuity. The contributing process ‘ADM’ of TOGAF adds a key advantage over other frameworks. “The ADM of TOGAF thereby focuses on EA management-projects instead of a continuous EA management function. While this approach ensures that a sponsor for the EA management endeavour is available (see preliminary phase), it entails the disadvantage that each project has to start with information gathering as no up-to-date information and description of the EA is available” [23]. The

106 Model-Driven Business Process Engineering

Faisal Almisned

segmentation of EA can be done with reference to architecture depth, time and scope. TOGAF points at the value of adapting the management essence, however, TOGAF does not provide any means to carry out this configuration. The distinction among EA frameworks is observable regarding the framework’s extent of details. Some frameworks are abstract, such as Zachman; while others are very detailed, such as TOGAF. In contrast, EAMPC avoids this variation by eliminating the need to introduce the entire framework as a whole; as an alternative, patterns will be introduced incrementally reflecting the maturity of an enterprise. A number of frameworks can only be seen as suggested guidelines, while some frameworks offer processes and methods. General terminologies are a feature of abstract frameworks. Arguments can be made against abstract frameworks due to the doubted soundness of the framework’s employment. Zachman framework provides the most inclusive classifications and viewpoints covering different aspects of the enterprise. Whereas, a large number of frameworks cover and represent fewer aspects using fewer viewpoints. EAMPC addresses the deficiency of very complex frameworks as it offers the possibility to improve or create single EAM pattern without having to create a completely new approach. Furthermore, the existing EAM Pattern Catalog can easily be extended due to the openness of the pattern approach. CONCLUSIONS This paper offers an inclusive overview on three EA frameworks, providing details on their structure and working mythologies. The concentration on three frameworks only is an advantage of this analysis, enabling a better observation and assessment of these three frameworks. The inclusion of EAMPC in this comparison is another advantage, as it is one of the rising frameworks that deserve a considerable level of attention. The comparison is based on various features covering a wider range of aspects of every framework. A number of these features are required in order to enable the selection of a framework matching the needs of a particular enterprise. All the previous statements clarify the distinction of this paper over the other analysis papers. All in all, this study is a report of the attempts to analyse and compare three main EA frameworks. This analysis is difficult due to the different nature amongst

An Analysis of Enterprise Architecture Frameworks

Model-Driven Business Process Engineering 107

different frameworks. In this analysis, different frameworks are compared in terms of features, which are not facilitated to be reflected and mapped across all compared frameworks. A major contribution of this analysis is the ability to choose a framework that ideally satisfies the needs and maturity of an enterprise and its stakeholders. In addition, a proper choice will avoid wasted costs and efforts on applying a framework that does not match the existing initiatives. This research intends to expand this analysis towards comprising further quantifiable indicators in addition to other frameworks on the way to improved help in the decision of a framework that addresses particular enterprise requirements. ACKNOWLEDGEMENTS Declared none. CONFLICT OF INTEREST The author confirms that this chapter contents have no conflict of interest. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Zachman, J. (1987). A Framework for Information Systems Architecture, IBM Systems Journal, 26(3), IBM Publication G321-5298. Goethals, F. (2003). An Overview of Enterprise Architecture Framework Deliverables. May 2003. Available: www.econ.kuleuven.ac.be/leerstoel/sap/Fra mesPage.htm Zachman, J. (1999). A Framework for Information Systems Architecture. IBM Systems Journal, 38(2-3), 454-70. Sowa J., Zachman J. (1992), Extending and formalizing the framework for information systems architecture, IBM Systems Journal, Vol. 31, No. 3, pp. 590-616. Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Framework: Creating or Choosing an Enterprise Architecture Framework. Victoria, Canada: Trafford Publishing. Institute for enterprise architecture developments, EA survey 2003; http://www.enterprisearchitecture.info Stan Loche, 2003, The Zachman Enterprise Architecture, Metadata Systems Software Inc. Senate of the United States of America. Public Company Accounting Reform And Investor Protection Act Of 2002. In The Library of Congress - Congressional Record, Washington, 2002 TEAF (2005). TEAF. Systems & Software Consortium. Available: www.software.org/pub/architecture/teaf.asp Meta Group (2005). Retrieved from http://www.metagroup.com/products/insigh ts/eas_1_sc.htm

108 Model-Driven Business Process Engineering

[11] [12] [13] [14] [15] [16] [17]

[18] [19] [20] [21] [22] [23]

Faisal Almisned

FEAPMO (2003). Business reference model version 2.0. Retrieved from http://www.cio.gov/documents/secure/BR M_v2_Comment_Response.pdf. Egan, G. (Ed.) (1988). Change-Agent Skills A: Assessing and Designing Excellence. San Diego: University Associates. The Open Group. “TOGAF ‘enterprise edition’ version 9”, http://www.togaf.org, 2009. Buckl, S.; Dierl, T.; Matthes, F.; Schweda, C.M.: Complementing The Open Group Architecture Framework with Best Practice Solution Building Blocks. In: 44th Hawaii International Conference on System Sciences (HICSS 2011), Kauai, Hawaii, 2011. U. F. C. Council, “Federal enterprise architecture framework (feaf),” http://www.cio.gov/documents/fedarch1.pd f,1999. U. D. of Defense, “Department of defense architecture framework (dodaf),” http://www.defenselink.mil/cionii/docs/Do DAF_Volume_I.pdf, 2007. S. Buckl, A.M. Ernst, J. Lankes, and F. Matthes, “Enterprise architecture management pattern catalog (version 1.0, February 2008)”. Chair for Informatics 19 (sebis), Technische Universität München, Munich, Tech. Rep., 2008. [Online]. Available: http://wwwmatthes.in.tum.de/ wikis/eampattern-catalog/home S. Kurpjuweit and R. Winter, “Viewpoint-based meta model engineering,” in EMISA, ser. LNI, M. Reichert, S.Strecker, and K. Turowski, Eds., vol. P-119. GI, 2007, pp.143-161. M. Lankhorst, “Introduction to enterprise architecture,” in Enterprise Architecture at Work. Berlin, Heidelberg, NewYork: Springer, 2005. Tang, A.; Han, J.; Chen, P., “A comparative analysis of architecture frameworks,” Software Engineering Conference, 2004. 11th Asia-Pacific, vol., no., pp. 640- 647, 30 Nov.-3 Dec. 2004 Warren Singer, “The Zachman Enterprise Framework”, 2007, http:// www.technicalcommunicators.com Josey, A. e. a.: TOGAF Version 9 – A Pocket Guide. Van Haren Publishing. Wilco, Amersfoort, Netherlands. 2nd edition. 2009. S. Buckl, C. Schweda 'On the State-of-the-Art in Enterprise Architecture Management Literature', 2011, Available: http://wwwmatthes.in.tum.de/wikis/sebis/publications

Send Orders for Reprints to [email protected] Model-Driven Business Process Engineering, 2014, 109-142

109

CHAPTER 6 Model Driven Approach for Programme Management Ravinder Singh Zandu* and Kevin Lano Department of Informatics, King's College London, Strand, London, UK Abstract: Program management is described as the management of number of projects in order to achieve the desired objectives or results or goals of the organisation as managing the projects individually could not produce the desired outcome. Each project in the program is associated in a systematic way to the program by the central objectives or benefits. A program usually has a longer life span in years and during the program many project are started, accomplished and closed. The Program Management focuses on planning, mobilizing, and managing a program at a client site with high-quality execution and to achieve the strategic goals and objectives of the organisation.

Keywords: Programme/program management, onshore-offshore, management, value measurement, demand and resource management.

delivery

INTRODUCTION According to PMI [1-3] program management is defined as the centralised coordinated management of a program to achieve the program’s strategic objectives and benefits. Projects within a program are related through the common outcome or collective activity. If the relationship between projects is only to that of a shared client, seller, technology or resource, the effort should be managed as a portfolio of projects rather than as a program. Program manager functions at the strategic level, align multiple projects to optimize achievement of goals, provide a comprehensive approaches to resource allocation across the organization, support the execution of executive level portfolio management, initiate Projects, assign Project Managers, work both within and external to their organization in managing complex programs that may span organizations. In addition, the program manager should have advanced skills in finance, cross-cultural awareness, leadership, communication, influence, negotiation and conflict resolution. *Address correspondence to Ravinder Singh Zandu: Department of Informatics, King's College London, Strand, London WC2R 2LS, UK; Tel/Fax: 07725991038; E-mails: [email protected]; [email protected]; [email protected] Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

110 Model-Driven Business Process Engineering

Zandu and Lano

P3M3 [4] describes a programme as a temporary, flexible organization created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organization’s strategic objectives. Rai and Swaminathan [5] discussed a systematic framework for program management having three related aspects of value realisation, program construction, and program execution. They defined program as a system of systems which takes into account various features and components of the each project and relate them with overall structure. The model is developed iteratively to address all the activities and information flow across the framework. Team management had been stressed as the most important concept in program management by Oliva [6]. Author suggested that increase use of integration technologies like computer aided engineering, manufacturing, etc. requires better team coordination and trainings. The workforce had reduced due to use of technologies, organisational structure had been made more horizontal and team management is one of the significant requirements for managing large scale complex programs. McFarlane et al., [7] discussed the use of simulation programmes for training program managers so as to enable them with better management of complex programs. Since programs are always large, complex, and of longer duration hence there is quite a lot of uncertainty in taking decisions. The simulated environment of training had been proposed for program manager so that they would be able to use their skills and experience to arrive at a decision and test it in risk free simulation and see the projected outcome. Marcroft [8] defined the processes, and methods for reducing the risk ion software development programs. Author studied program management techniques used for hardware development and suggested changes along woth rationale to use them for software development. M. G. Gilbert [9] had suggested the use of system management for effective and efficient management of research projects and programs. Author proposed an

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 111

approach in which required and specific program and project management trainings are provided to the team/group. This helped in improving the policy and process improvements along with reviews and assessments. Defence research programs are generally large, costly and complex than other programs of any government. Cakmark and Gokpinar [10] discussed the application of decision making approach for managing Turkish Space program. The paper suggested that for effective management of such a large program web model with grading process for work break down structure as per the technology evaluation matrix should be used. D. G. Bell et al., [11] discussed unique process for program management and business intelligence for an organisation like NASA. The process used business documents as user interface and schema less XML database for making integration of information easier for automation. The implementation is based on NASA Program Management Tool and Netmark- its schema-less database. The benefits are reduced paper work and easier retraceability of business requirements to final management reports. Young and Frank [12] discussed the relationship of project management with other allied disciplines in the field of management. The research is based on the study of 18 top management and business journals, publications and then divides them into 8 categories. The authors categorised them as (1) Strategy/Portfolio Management; (2) Operations Research/ Decision Sciences; (3) Organizational Behaviour/ Human Resources Management; (4) Information Technology/Information Systems; (5) Technology Applications/Innovation; (6) Performance Management/Earned Value Management; (7) Engineering and Construction; and (8) Quality Management/Six Sigma. M. A. Ghasemabadi and P. D. Shamsabadi [13] applied PMBOK 2008 standard processes to manage Enterprise Project Management (EPM) system in an organisations. The authors studied the implementation of the system and suggested steps to improve efficiency reduce time. Callegari and Bastos [14] proposed an integrated model using RUP and PMBOK to automate the software development projects to enhance quality. Champa et al., [15] recommended a new

112 Model-Driven Business Process Engineering

Zandu and Lano

framework of integrated engineering framework and standard PM methods for managing software development type IT projects. Rita and Andries [16] applied software agent framework to manage software projects. The author developed two comprehensive frameworks to manage whole of the core & facilitating processes and functions of software project management. The project is managed by dividing the project into small and manageable activities and each is managed by an agent. This reduces complexity and study showed that project can meet client and market expectations. Shuobo Xu and Dishi Xu [17] discussed that project managers had to use other tools for effort and budget estimation along with the existing project management methodologies. They had also to use performance measurement tools for delivering quality software projects. FEATURES OF PROGRAM MANAGEMENT The Program Management focuses on planning, mobilizing, and managing a program at a client site. Leadership and Governance Prioritise

Plan

Value Management

Demand Management

Manage

Mobilise

Value Measurement

Program Control and Administration

Delivery Management Quality Management

Program Delivery

Stakeholder Management

Resource Management

Stakeholder Acceptance

Figure 1: Program Management Methodology Framework.

As shown in Fig. 1, program management includes the following critical areas for planning and mobilizing a successful program: 

Demand Management. This is for balancing the workload of the program by assessment of the priorities of proposed projects with the

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 113

capacity to perform the work and aligning of the projects with the overall strategy. 

Leadership and Governance. Defines the structure and objectives for the group guiding the overall goals of the program and determines how best to coach leadership.



Value Management. Defines the business case, value metrics, and value measurement approach for the program.



Program Delivery. Defines the management approaches, schedule, timeline, budget, scope, and metrics for the program. Identifies vendors, tools, and resources. Establishes the program management office.



Stakeholder Acceptance. Identifies and analyses stakeholder expectations. Determines how to ensure the program results acceptance by multiple levels of customers. Creates initiatives to cultivate program acceptance.

It includes the following critical areas for successfully managing an existing or newly created program: 

Value Measurement. Measures the value achieved by the program against the value expectations set in the business case. Provides ongoing management of the business case.



Program Control and Administration. Coordinates all program activities, reports, and other deliverables. Manages finances, contracts, record keeping, and knowledge management.



Delivery Management. Monitors and controls projects under the guidance of the program and manages the release schedule.



Quality Management. Manages and oversees the program’s adherence to quality processes and standards. Works with stakeholder management

114 Model-Driven Business Process Engineering

Zandu and Lano

to monitor and manage stakeholder expectations and satisfaction. Identifies and acts on opportunities for improvement. 

Stakeholder Management. Monitors and manages stakeholder expectations throughout the life of the program. Monitors the effectiveness of change initiatives and program acceptance, and makes adjustments as needed.



Resource Management. Manages all program resources, including personnel, vendor relationships, physical work environment, facilities, and equipment.

The methodology does not cover: 

Selling work to the client.



Strategic planning and business architecture.



Long term planning for transformational change or outsourcing.



Project-level management.

WHEN TO USE THIS METHODOLOGY This methodology is designed for the following circumstances: 

You are planning, mobilizing, or managing a single program.



You have determined what value you are providing the client though the program.



You and the client agree on the program objective.



A program agreement with the client is already in place. This may take the form of a solution value diagnosis, rough business case, contract, or a program roadmap that roughly maps out the timeline for delivering the proposed value. Additional work on these deliverables is expected and accommodated within this methodology.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 115

INTEGRATION WITH PROJECT MANAGEMENT This fits with the Project Management by providing: 

The high-level estimate for the project via the budget for the program.



Program Management Approaches that serve as the starting point for individual Project Management Plans.



Standard orientation and training materials for all projects to use.



Policies and standards, including methods guidelines.



Vendor contract and management support.



Team work environment and facilities support.

The program handles all upper management reporting, financial statements, contract negotiations, and fulfilment of the program business case. The project provides the program with all necessary reporting metrics and to fulfil the project’s business case. INTEGRATION WITH CMMI A standard methodology is one of many components that are assessed when an organization aspires to operate at a particular certification or quality level. 

Capability Maturity Model Integrated (CMMI).



eSourcing Capability Model (eSCM).



People Capability Maturity Model (P-CMM).

PROGRAMME MANAGEMENT STRUCTURE OVERVIEW This overview explains: 

The framework for the methodology.

116 Model-Driven Business Process Engineering



The main content types and how they relate to each other.



The supplemental content types available to help you.

Zandu and Lano

The vertical bars in shown in the Fig. 1 are the stages of work within a program. 

Prioritize. Balance the program’s workload by evaluating the priorities of proposed projects with the capacity to perform the work and how the projects align with the overall strategy.



Plan. Define the program’s scope, objectives, and structure. Establish the program’s timeline, schedule, and budget. Develop the business case and the stakeholder acceptance approaches.



Mobilize. Roll out the program plans by performing detailed design and implementation of program policies, standards, training, work environment, tools, and vendor arrangements.



Manage. Run the program according to the Program Management Approaches and Program Plan established during the Plan stage. Monitor program execution, and continuously improve the program.

The horizontal bars shown in the Fig. 1 are workstreams defined as a domain or area of work. Workstreams group the tasks usually performed by a team of people with related skill sets. For example, Leadership and Governance defines the structure and objectives for the group guiding the program’s overall goals and determines how best to coach leadership. Each box in the diagram shows an activity. For example, Program Delivery means the Program Delivery activity (Fig. 2). Each box on the activity diagram opens a task (the lowest process level in the methodology). Blue boxes indicate tasks that involve members of this team but are the responsibility of another team. For example, Understand Goals and Expectations in Fig. 2 is the responsibility of the Stakeholder Acceptance activity, but it requires involvement from all program areas to complete effectively.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 117 Validate

Plan

Understand Goals and Expectations Assess Current Program Management Capability

Plan Program Management Approaches

Mobilise

Develop Program Plan

Define Policies and Standards

Establish Program Management Office

Create Organisation Materials

Obtain Program Resources

Design Physical Work Environment

Implement work Environment

Select Vendors and Tools

Contract with vendors

Figure 2: Program Delivery Activity.

The framework shows as a simple matrix and is not meant to show time dependencies between the different workstreams. For example, all three Plan and Mobilize activities (Value Management, Program Delivery, and Stakeholder Acceptance) do not happen simultaneously; each workstream has interrelated dependencies that require some activities to precede others. However, they all begin during the Plan stage. PRIMARY METHODOLOGY CONTENT TYPES There are three key types of content in the methodology: 

Processes define what you need to do.



Deliverables are what you need to produce.



Roles tell who needs to do it.

These three content types reference each other to form the foundation of the methodology (Fig. 3).

118 Model-Driven Business Process Engineering

Zandu and Lano

Roles

Perform

Create

Require Skills of

Processes

Require Skills of

Deliverables

Results in

Figure 3: Primary Methods Content.

Processes In this methodology, there are two levels of process documents: 

Activities are large units of work with a single major outcome. They are composed of tasks.



Tasks are smaller units of work performed by one individual or team to create a single primary outcome. Tasks are composed of steps.

Activities Activity documents are written primarily for the project’s manager or team lead. Fig. 4 shows the 11 activities in this methodology: Leadership and Governance Prioritise

Plan

Mobilise

Demand Management

Value Management

Manage

Value Measurement

Program Control and Administration

Delivery Management Program Delivery

Quality Management Stakeholder Management

Stakeholder Acceptance

Figure 4: Activities within the Method.

Resource Management

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 119

In complex activities, the tasks may be organized into sub-workstreams, based on the skills needed to perform the tasks. This methodology does not use subworkstreams. Each activity contains the following information: 

Planning Chart. This is a schematic of tasks for the activity, showing their sequence and relationship.



Deliverable Flow. This is a schematic of deliverables for the activity. Toggle from the process view to the deliverable view by clicking a link immediately below the schematic.



Objectives. This lists the principle objectives and outcomes of the activity.



Inputs and Deliverables. This shows the inputs and outputs of the activity, grouped by which deliverables are critical (primary) and which are useful but not essential (secondary).



Roles. This describes the skill sets required to execute (responsible roles), assist, or review the work (secondary roles).



Relationship to Other Workstreams. This describes the dependencies between this activity and activities in other workstreams.



Considerations. These are the key issues to consider for planning, managing, staffing, and successfully completing the activity.

Tasks Task documents are written for the team member executing the work. In each task, you will find the following information: 

Planning Chart. This is a schematic of steps for the task.



Objectives. This lists the activity’s principle objectives and outcomes.

120 Model-Driven Business Process Engineering

Zandu and Lano



Inputs and Deliverables. This shows the inputs and outputs of the task, grouped by which deliverables are critical (primary) and which are useful but not essential (secondary).



Roles. This describes the skill sets required to execute (responsible roles), assist, or review the work (secondary roles).



Process Steps. These describe each step in the planning chart.



Key Considerations. These are the key issues to consider for planning, managing, staffing, and successfully completing the activity.

Deliverables Deliverables contain the following information: 

Description. This provides a short description of the deliverable.



Roles. This describes the skill sets required to execute (responsible roles), assist, or review the work (secondary roles).



Template. This Microsoft Office template helps create the deliverable. Many templates are annotated to help you complete the deliverable.



Sample. This is an example of a completed deliverable.



Customers. This briefly explains of who is dependent on this deliverable and why.



Where used. This lists the processes that create, update, and use this deliverable as an input.

A composite is a grouping of related deliverables into a single object. For example, the Program Plan composite is composed of the following: 

Work Plan.



Schedule and Milestones.

Model Driven Approach for Programme Management



Resource Plan.



Budget.



Organization Chart.



Dependency Chart.



Release Plan.



Program Scope.



Project Statement of Work.

Model-Driven Business Process Engineering 121

Each Program Plan composite can contain zero, one, or many instances of each of its child deliverables. Collectively, however, all instances of these deliverables serve one purpose in executing and controlling the program. Roles Roles are the skill sets needed to complete a task. A person on a team may have one or more roles on the project. Similarly, more than one person on a team may share a role. There are two types of roles in the methodology: 

Responsible roles are primarily responsible for completing a task or deliverable.



Participating roles assist in completing a task or deliverable by reviewing the work or providing the expertise.

Each role description in the methodology provides the following information: 

Role responsibilities



Tasks the role is responsible for



Tasks the role participates in

12 22 Model-Driveen Business Pro ocess Engineerin ng



Deliveerables the role is respon nsible for



Deliveerables the role participaates in



Additiional resourcces for the ro ole

Zandu and Lano

SUPPLEME ENTAL METHODOLO OGY CONT TENT TYPE ES In n addition to the main ob bject types, th he methodollogy provides additional assistance fo or users in th he form of job b aids, check klists, and extternal resourrces (Fig. 5).

Fiigure 5: Suppllementary Meth hods Content.

Jo ob Aids Jo ob aids prov vide addition nal guidancee for compleeting a task or deliverabble. There arre three typees: 

Overvview. This deeliverable prrovides a desscription of kkey conceptts and backg ground inform mation.



Guideelines. This deliverable provides specific inform mation on isssues, consid derations, an nd approachees for compleeting a task.



Techn nique. This deliverablee provides specific innformation on a speciffic approach or method of o achieving a result.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 123

Checklists Checklists provide tools for quick quality checks at key points in the process. Each checklist includes an attachment, allowing you to easily download a copy of a checklist, customize it as necessary for your project, complete it, and store it with your project deliverables. External Resources External references are links to additional resources outside this methodology, including references to internal databases, web sites, book descriptions, and other methodologies. Deliverable IDs Each process and deliverable in this methodology has an identifying ID code. 

Processes have a four-digit numeric identifier.



Deliverables have a five-character alphanumeric identifier.

Process IDs Process IDs take the following form as shown in Fig. 6:

Figure 6: Process ID Structure.



The first digit defines the activity stage. For example, all activities in the Plan stage start with the number 2.



The second digit defines the activity’s workstream. For example, all activities in the Stakeholder Acceptance workstream have a second digit of 5.



The third and fourth digits define the process’ sequence. For example, the Value Management activity has an ID of 2200 ("00" indicates an

124 Model-Driven Business Process Engineering

Zandu and Lano

activity); Develop Business Case, a task in Value Management, has the ID 2211. Deliverable IDs Each composite and deliverable has an ID with the form PGXXX, where PG stands for Program, and the three following digits indicate the following: 

The first digit defines the stage where you create the deliverable. For example, plan deliverables all have the number 2 as the first digit.



The second digit defines the workstream of the deliverable, where applicable. For example, the Capacity Plan, created during Demand Management (1100), is PG116.



The third digit defines the approximate sequence of deliverables relative to other deliverables.

Composites always end in the number 0. Its children usually have the same first four characters in their IDs. LEADERSHIP AND GOVERNANCE (Fig. 7) Objectives 

Create a leadership mindset and enable leadership to lead the program and accomplish the strategic objectives of the program.



Establish and operate an effective governance team that navigates and provides direction for the program and projects.

Demand Management 

The governance team reviews any new work proposed by the demand management team and makes the go or no-go decision. Demand Management receives input and direction from the governance team on potential new work to explore based on discussions with the senior leadership sponsor and other key stakeholders.

Model Driven Approach for Programme Management Understand Goals and Expectations

Assess Current Leadership Capabilities

Define Governance Approach

Develop Leadership Initiatives

Model-Driven Business Process Engineering 125 Implement Governance Approach

Sustain Leadership Commitment

Implement Leadership Initiatives

Figure 7: Leadership & Governance.

Value Management and Measurement 

Value Management and Measurement works with the governance team to define value and obtain direction on how to manage and measure value. Upon establishing the value definition and metrics, the value management and measurement team ensures the program and project leadership buys into the value definition, and incorporates quality and measurement practices that link to the achievement of that value.

Program Delivery 

Leadership and Governance oversees program delivery. It provides direction to the program and ensures that the program is progressing as planned and achieving the objectives outlined in the business case.



Stakeholder Acceptance and Management.



Stakeholder Acceptance and Management works closely with Leadership and Governance to identify all key stakeholders for the program. The leadership and governance team is a key stakeholder group that the stakeholder acceptance and management team focuses on. Stakeholder Acceptance and Management ensures that the leadership and governance team members demonstrate strong sponsorship ownership, and commitment to the program and projects.

Quality Management 

The quality management team obtains direction from the governance team on the important quality factors. The quality management team

126 Model-Driven Business Process Engineering

Zandu and Lano

then works with program and project leaders to incorporate quality into the deliverables or outcome. DEMAND MANAGEMENT (Fig. 8) Objectives 

Create a comprehensive, prioritized list of project and initiative requests that meet business needs.



Determine the delivery organization’s capacity to deliver these initiatives and align it to the prioritized list of projects.



Determine program funding levels and align them to prioritized list of projects.



Produce a finalized, ranked project list that aligns with the program budget and capacity. Understand Goals and Expectations Develop Program and Project Inventory

Prioritise Project List

Plan Capacity and Utilisation Align Budget

Finalise Project List

Figure 8: Demand Management.

VALUE MANAGEMENT (Fig. 9) Objectives 

Work with client executives to develop and agree on a complete and exhaustive value measurement approach.



Develop a business case to substantiate that the program’s contribution to the client’s value creation justifies program costs and investment.



Structure scorecards and metrics to effectively monitor and drive realization of the forecast program value.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 127 Validate

Plan

Mobilise Determine Value Measurement Approach

Understand Goals and Expectations

Develop Value Metrics and Scorecard

Develop Business Case

Figure 9: Value Management.

PROGRAM DELIVERY (Fig. 10) Objectives 

Identify and create the management processes needed to run the program successfully.



Develop a program-level plan that delivers the agreed upon business value.



Satisfy the goals and expectations of the program’s stakeholders. Validate

Plan

Understand Goals and Expectations Assess Current Program Management Capability

Plan Program Management Approaches

Mobilise

Develop Program Plan

Define Policies and Standards

Establish Program Management Office

Create Organisation Materials

Obtain Program Resources

Design Physical Work Environment

Implement work Environment

Select Vendors and Tools

Contract with vendors

Figure 10: Program Delivery.

STAKEHOLDER ACCEPTANCE (Fig. 11) Objectives 

Understand and manage stakeholder expectations throughout the program.

128 Model-Driven Business Process Engineering

Zandu and Lano



Assess the overall organizational capacity to change and identify potential barriers to change.



Identify organizational strengths and weaknesses to understand factors that may support or inhibit change.



Identify the degree of impact the program will have on stakeholder groups.



Assess the overall sponsors’ and stakeholders’ readiness and willingness to change.



Develop a comprehensive Change Acceptance Strategy that ensures the intended change will be both understood and accepted by all affected parties.



Develop and implement change initiatives and incentive programs that keep stakeholders and sponsors engaged and committed throughout all stages of the program. Validate

Plan Understand Goals and Expectations

Analyse Change Impact

Assess Culture and Context

Assess Change Readiness

Mobilise Define Change Acceptance Strategy

Develop Change Initiatives

Implement Change Initiatives

Figure 11: Stakeholder Acceptance.

VALUE MEASUREMENT (Fig. 12) Objectives 

Manage and measure value realization throughout the program life cycle.



Provide project and program managers with value analysis data to facilitate corrective actions identification.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 129



Determine the impact of program changes on the business case and reforecast value creation.



Provide stakeholders with a value-driven guidance of the change program.



Verify and validate the results of program initiatives with program sponsors and stakeholders.

Assess Value Realisation Manage Business Case

Report Program Value

Figure 12: Value Measurement.

STAKEHOLDER MANAGEMENT (Fig. 13) Objectives 

Manage stakeholders throughout the life of the program.



Understand and manage stakeholder expectations of the various projects.



Assess ownership and commitment to the change journey at various points in the program life cycle.



Validate and verify that ownership and commitment levels are aligned with where the project is in the life cycle.



Manage the approved change initiatives and incentives at the program level.



Verify and validate results of change initiatives and incentives at the program level; make adjustments as needed.

130 Model-Driven Business Process Engineering



Zandu and Lano

Provide program guidance and guidelines to the associated projects with regards to stakeholder management. Manage Stakeholder Expectations and Satisfaction Manage Change Initiatives

Assess Ownership and Commitment

Figure 13: Stakeholder Management.

DELIVERY MANAGEMENT (Fig. 14) Objectives 

Implement the coordination and management functions needed to ensure a quality product within a given release.



Track the progress of the program and related projects against plan. Manage Releases Monitor Program Progress

Figure 14: Delivery Management.

QUALITY MANAGEMENT (Fig. 15) Objectives 

Ensure that stakeholder expectations, quality objectives, and program requirements are defined, understood, implemented, and actively managed.



Execute and maintain the processes defined in the Quality Management Approach.



Verify that the program results meet the standards.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 131



Verify that quality processes are followed and meet the applicable standards.



Gather and validate that the metrics meet the objectives. Take required corrective action if necessary.



Implement any needed program improvements. Manage Stakeholder Expectations and Satisfaction Verify Product, Process and Program Quality

Plan and Implement Improvements

Gather and Validate Metrics

Figure 15: Quality Management.

PROGRAM CONTROL AND ADMINISTRATION (Fig. 16) Objectives 

Provide visible and consistent program leadership, direction, and focus.



Ensure program and project activities align with overall program objectives. Direct Program Manage Program Financials Manage Contracts

Close Program

Operate Program Management Office Manage Records Manage Knowledge Assets

Figure 16: Program Control & Administration.



Manage the control and coordination of program-wide approaches, policies, and infrastructure functions to maximize program performance and delivery.

132 Model-Driven Business Process Engineering



Zandu and Lano

Manage the control and coordination of program-wide approaches and infrastructure functions to ensure compliance with financial, contractual, and legal requirements.

RESOURCE MANAGEMENT (Fig. 17) Objectives 

Efficiently and effectively provide all resources required by the program and its projects on a rolling basis.



Enable projects to meet their schedule, budget, and business case by the timely acquisition, maintenance, and release of quality resources.



Track acquisition and usage of all program resources.



Meet cost and other metrics criteria for resources, as established by the Resource Plan, Program Metrics Plan, Business Case, and Financial Plans.



Monitor the quality, timeliness, and effectiveness of vendors and other resources to ensure they fulfil their requirements. Manage Personnel Manage Personnel Manage Facilities and Equipment

Manage Vendors and Alliances

Figure 17: Resource Management.

CASE STUDY The purpose of the group ERP Consolidation project (GERP) is to implement one SAP based ERP application that will support standardised and simplified business processes for all of the group businesses in organisation-Z as shown in Fig. 18. The project planning and management was done as per the PMBOK process and knowledge management areas.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 133

This project is classified as a Business Initiative. Benefits will arise from the lower cost of ownership of a single consolidated ERP system for the Service Companies and the reduced cost of support through offshoring a significant part of the new support organization required to support the consolidated application. Additionally, business benefits will arise through the consolidation of back office functions enabled through use of simplified, standardised business processes and systems. Project C Stakeholder Expectations Business Objectives - To reduce cost of providing an up to date well supported integrated ERP & Data warehouse system to service companies -To standardise the service business processes with ERP applications -To simplify processes & consolidate functions to yield cost saving where possible - Provide up to date property management capabilities

Produce Stakeholder Expectations Benefits - Process Standardisation - Shared Service Migration - Reduced Control Cost - Functional Excellence - Responsiveness - IT Cost savings USD 3.0 mn/ annum - IT cost avoidance USD 17.4 mn - Business USD 8.1 mn/ annum

Scope Organisation Scope - Different service organisation of Company Z Geographical Scope - Different Countries: UK, USA, Netherlands, Australia, Malaysia, Singapore, Philippines, Guatemala Defines Functional Scope - Functional Management Accounting - Asset Management Accounting - Project Management Accounting - Expense Claims - Contracting & Personnel Management - Sales - Internal and external client billing/ invoicing - MIS

Technical Scope Assumptions No point to point interfacing (middleware must be used) No legacy middleware Use generic design for message interfaces Use ABAP then Java

Establishes

Generates

Figure 18: Project C.

The main business objectives of this project are: 

To reduce the cost of providing an up to date, well supported integrated ERP and data warehousing system to the Companies.



To standardize the business processes with ERP applications.



To simplify Services business processes and to consolidate functions where possible to yield cost savings in operating those functions.



Provide up-to-date Property Management capabilities where organisation’s Real Estate Services can consolidate property information and can standardise business processes associated the administration of organisation’s property.

134 Model-Driven Business Process Engineering

Zandu and Lano

The project objectives are in line with the CMD, CFO and other who endorse Group ERP Strategy based on SAP software. The project objectives are also in line with IT to reduce IT application support costs across the Group through rationalization of IT applications and offshoring of application support. The project objectives are also consistent with the recommendations to use consistent processes across the group and supported by one common system. Additionally, the project objectives are also consistent with the finance strategy to standardize and simplify financial processes, provide increased transparency of financial information and a consistent controls framework. IT Operational Cost / Benefit To estimate future IT operational cost, the Operational Cost information for the individual Service applications was collected and decomposed into three areas; ERP Cost, Data Warehouse Cost, and Other ERP Related Costs. Each of these cost components, was further broken down by: Hardware, Software License Fees, Application Support and Run & Maintain Enhancements Costs. From this base information, collected from the focal points, forecasts were made using knowledgeable resources, accepted estimating models and assumptions based upon best information. An estimated $3.1 million in benefits may be obtained in IT operational cost by consolidating the Services businesses on to one ERP application. The following are the guidelines followed to determine the portion of the project costs that should be considered capital and expense. 

Program & Management costs. o Strategic investments required to deliver the system. o 60% capital and 40% expense.



Implementation costs. o Development predominant activity.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 135

o 100% capital. 

Training and data conversion. o 100% expense.



Post go-live operational & support. o 100% expense.



Post go-live upgrades. o 100% capital.

Recovery Mechanism Ownership of the GERP project is based upon a cost recovery model where all participants share in the ownership of the intangible asset. The premises for the ownership and cost allocation are: 

Single entity captures costs associated with GERP.



Periodically (quarterly) cost are passed to the participating entities.



Capital cost is recorded as work in progress.



At go-live benefiting business entity reimburses and records intangible asset and amortize asset over 5 years.



Recommend payment based on named number of users and any unique customization charged to requesting entity.



Payment “trued-up” upon completion of project.

Strategic / Intangible Benefits Additional strategic and intangible benefits associated with the consolidation of the Services ERP and data warehouse applications have been identified (but these are difficult to quantify). Benefits include:

136 Model-Driven Business Process Engineering

Zandu and Lano



Faster and less costly implementation of new strategic initiatives.



Platform available for any future new Business Service or Functions inclusion of which should lower costs for all participants.



Easier sharing of best practices.



Facilitates off-shoring/outsourcing.



Facilitates improved controls and compliance.



Common processes and formats for customers.



More flexible workforce.



Enhanced decision making through more readily available and higher quality Management Information.



Easier benchmarking across Business Services and Functions.



Consolidated view of services position across customers/suppliers.

Program Management The project planning and management was done as per the PMBOK process and knowledge management areas. Various documentation and deliverables were created along with milestones. The project was managed using multi-centre scenario as shown below in Fig. 19: All the requirements were gathered at all the locations and design was validated at the onshore site and detailed design done at offshore DC along with various component tests and part of assembly tests. Solution was then implemented at the onshore sites in various countries and final testing at client locations. This model provided the benefits of the both the DC-centric and customer-centric models. Cost-savings achieved by using the offshore centre and the risk was reduced because the customer team works closely with onshore/near-shore centre. Program Timeline: The high-level timeline of the project is shown in the Fig. 20 below:

Model M Driven App proach for Prog gramme Manag gement

Model--Driven Businesss Process Engin neering 137

Fiigure 19: Multti Centre Scenaario.

Program P Tim meline The T group ERP E project will implement a rigoorous risk m managementt process, which w will identify i pottential riskss, qualify ttheir probabbility of occcurrence, qu uantify their potential cost and tim me impact, and definee risk mitigation and av voidance strategies. Year 1

Stage 0 - Business Case Review Stage 1 - Project Setup SERP Project Change Management Stage 2-4 - Standerdise & Design Business Processes Stage 4 - Development Testing Stage 5 - Deployment Training,Conversion,Cutover ISIS Stage 4 - Development Testing Stage 5 Deployment Training,Conversion,Cutover Historical Data Retention,Archive Stargate / Genisis / Comcas Stage 4 - Development Testing - Comcas SFS (JDE) Testing - Stargate / Oversisi (SAP) Testing - SSC - Manila /KL /GTML Stage 5 Deployment Training,Conversion,Cutover Historical Data Retention,Archive SRES (Real Estate Management) Stage 4 - Development Development Testing Stage 5 Deployment Training,Conversion,Cutover Data warehouse Stage 2 - Analysis & Requirements Defn Stage 3 - Design Standard Reporting Stage 4 - Development Stage 5 Deployment SSC - Training,Cutover ISIS - Training,Cutover SFS,Stargate,Oversis - Training,Cutover

Fiigure 20: Timeeline.

Year 2

Year 3

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12

Zandu and Lano

High

138 Model-Driven Business Process Engineering

2

4

Medium

1 7

6

9

3

8

10

Low

Potential Impact

5

Medium

Low

High

Likelihood

Figure 21: Risk Identification.

Above Fig. 21 shows the risks are identified as 1. Internal resources, 2. Organisational Change Resistance, 3. Historical Data Retention Requirements, 4. Group Consultation/Documentation, 5. Benefits Realization, 6. Group Business Process Requirements conflicts 7. Delay with group ERP implementation 8. Business Reorganisation 9. Project Cost overrun, 10. Higher infrastructure costs. Risk response planning was also created and monitored and controlled by the project management office. Value Proposition and Economics Consolidation of these four different ERP systems and data warehouse systems delivered approximately 25% reduction in IT related cost, as well as potential business cost savings enabled by the consolidation of these systems and standardisation of business processes. Summary of Savings Business

$ 8.1m p.a.

IT

$ 3.4m p.a.

IT Cost Avoidance

$ 17.4m

The benefits are described in more detail below.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 139

Business Cost Savings Implementing and centralising standard processes generated approximately USD 7.4 m p.a. of the USD 8.1m cost savings. Financial closing and central master data maintenance are examples of where cost savings can be realised. This resulted in reduction of business resources to support GERP and allowed moving more operational functionality to low-cost centers. Further cost reductions were realised for a reduced number of annual system audits (.2m p.a.) and .5m in simpler implementation of future Group initiatives like SOX documentation, International Accounting Standards adoption, Global Credit Card rollout, etc. The GERP Application is a key enabler to significant changes in the management of Services business processes and related financial information. One such potential change is the simplification and standardisation of the intra and intercompany billing process. Standard intra and inter-company process on a single ERP platform will facilitate additional efficiencies in the Shared service centers. Central HR benefited from improved intra and inter-company processes through reduced number of interfaces of payroll information from employees and reduced number of applications that require account analysis. Reduced invoice volumes, standardised customer invoices, improved data integrity and fewer resources doing internal business will result in additional efficiencies. Benefits were also achieved from consolidation of master file data maintenance and financial closing functions into a common back office. IT Cost Savings USD 3.4m annual savings in IT operating cost are estimated through reduction of ERP and data warehouse applications to one consolidated system. Reduced application support costs drive the largest savings in IT cost from approximately USD 5.3m to USD 2.5m. This USD 2.8m saving is due to the reduction in the number of FTE’s required to support the application and off shoring of application support as per ICT Vision. The overall system enhancements expenditure reduced somewhat through avoidance of duplicated spend. The savings in system enhancements is USD 0.5m per annum. Real Estate Services realised approximately USD 0.3m p.a. savings by replacing the ABC application with the Property Management functionality transferring to SAP and other functionality to other standard packages.

140 Model-Driven Business Process Engineering

Zandu and Lano

IT Cost Avoidance Benefits A total of approximately USD 17.4m has been identified in one-time cost avoidance benefits. This is comprised of a USD 4.5m required upgrade of XYZ in earlier to a supported SAP version. The current XYZ SAP version (x.x) is supported through a temporary arrangement with annual cost increases and will become increasingly difficult to support and adapt to business needs. Without one standard ERP, inconsistent financial processes and controls across the Services and Functions would have remained and above benefits would not have been realised. In addition there was a continued risk of failing to achieve lower cost finance function without GERP. CONCLUSIONS The group ERP consolidation program has number of projects phasing out other ERP systems like JD- Edwards Peoplesoft, etc., manage cut-over, training development, retraining of employees, infrastructure development for new system, development of new modules, development, operational and execution environment for the new system, testing of new modules. A case study of one of the programs used Multi Centre Scenario and shown that major benefits could be achieved. These benefits are highlighted as business cost savings; IT cost savings, and IT Cost avoidance benefits. The project planning and management was better and the project was delivered on time with improved and enhanced project monitor and control mechanism. All other project management knowledge and process areas of PMBOK and program management standard were used effectively and efficiently. All the documents, deliverables were created as per PMBOK and program management standard and milestones monitored and controlled to deliver project in various countries. A very large number of organisations now manage projects globally and use some kind of process for managing projects in different countries. The models and teaming approaches defined here will be highly beneficial to such organisations as this paper describes a better structured flow, processes and organisation structure to manage global/ distributed projects effectively and efficiently.

Model Driven Approach for Programme Management

Model-Driven Business Process Engineering 141

ACKNOWLEDGEMENTS Declared none. CONFLICT OF INTEREST The authors confirm that this chapter contents have no conflict of interest. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

[11] [12] [13]

[14]

A Guide to the Project Management Body of Knowledge, 4th edition, PMI, USA, 2008. The Standard for Program Management, 2nd edition, PMI, USA, 2008. Managing Successful Projects with PRINCE2, OGC, UK, 2009. P3M3-Portfolio, Programme and Project Management Maturity Model, OGC, UK, 2008. Rai, V.K.; Swaminathan, N., “Constructing Program Management Framework”, 4th Annual IEEE Systems Conference, 2010, pp 478 – 483. Oliva, L.M., “Program Management Is Always Team Management”, IEEE International Engineering Management Conference, 1990. Management Through the Year 2000 Gaining the Competitive Advantage, 1990, pp 53 - 57. McFarlane, L.N.; Peck, R.J.; Janneh, B.I.; Austria, R.D.; Lark, J.W., “Development Of Simulation Games To Improve The Practice Of Program Management”, Systems and Information Engineering Design Symposium, SIEDS '09, 2009, pp 13 - 18. Marcroft, K.M., “Software Program Management”, IEEE National Aerospace and Electronics Conference, NAECON,1991, vol.2, pp 684 – 689. Gilbert, M.G., “A Systems Management Approach To Improving Performance And Reducing Risks In Research Projects And Programs”, IEEE Aerospace Conference, 2002, vol. 7, pp 3467 – 3471. Cakmak, M.A.; Gokpinar, E.S., “Program Management Decision Making Approach for Effective Project Management: The Web Model in an Example of Turkish Space Program”, 3rd International Conference on Recent Advances in Space Technologies, RAST '07,2007, pp 59 - 63. Bell, D.G.; Maluf, D.A.; Gawdiak, Y.; Putz, P.; Swanson, K., “The NASA program management tool: a new vision in business intelligence”, IEEE Aerospace Conference, 2006, pp 1-7. Hoon Kwak, Young; T. Anbari, Frank, “Analyzing Project Management Research: Perspectives From Top Management Journals”, International Journal of Project Management-27, 2009, pp 435–446. Ghasemabadi, M.A.; Shamsabadi, P.D., “Application Of Five Processes Of Project Management Based On PMBOK-2008 Standard To Run EPM-2010 Project Management System: A Case Study Of Arya Hamrah Samaneh Co.”, 2nd IEEE International Conference on Emergency Management and Management Sciences, ICEMMS, 2011, pp 792 – 795. Callegari, D.A., Bastos, R.M., “Project Management and Software Development Processes: Integrating RUP and PMBOK”, International Conference on Systems Engineering and Modeling, 2007. ICSEM '07, pp1-8.

142 Model-Driven Business Process Engineering

[15] [16] [17]

Zandu and Lano

Hewagamage, Champa; Hewagamage, K. P., “Redesigned Framework and Approach for IT Project Management”, International Journal of Software Engineering and Its Applications, Vol. 5 No. 3, July, 2011, pp 89-106. C Nienaber, Rita; Barnard, Andries, “A Generic Agent Framework to Support the Various Software Project Management Processes”, Interdisciplinary Journal of Information, Knowledge, and Management, vol. 2, 2007, pp 149-162. Xu, Shuobo; Xu, Dishi, “Project Management Methodologies: Are They Sufficient To Develop Quality Software” 2nd IEEE International Conference on Emergency Management and Management Sciences, ICEMMS, 2011, pp 175 – 178.

Model-Driven Business Process Engineering, 2014, 143-145

143

Index A Activity diagrams

9

B Business process modelling

3, 4

C CDD Change management CIM Class diagrams CMMI COM+ Diagram Computation-Independent Model (CIM) Constraint-Driven Development (CDD)

5 39 5 7 30, 116 69 5 5

D Distributed work

26

E EAMPC Enterprise architecture (EA) Enterprise architecture management (EAM)

92 79 81

F Fuzzy logic

23

I Interaction diagrams

9

K Key Process Areas (KPAs) Kevin Lano, Ravinder Singh Zandu and Krikor Maroukian (Eds.) All rights reserved-© 2014 Bentham Science Publishers

29

144 Model-Driven Business Process Engineering

Lano index

M MDA MDD MEASUR Metromap Model transformations Model-driven Architecture Model-driven Development

4 3 68 19 4, 9 4 3

N Net Present Value (NPV)

23

O OCL OMG Ontology chart OPM3

7 6 68 29

P (PM)2 P3M3 PIM Platform-independent model Platform-specific model PMBOK Postconditions Preconditions PRINCE2 Program management Project management Project management maturity model Project matrix PSM

29 15, 111 4 4 4 3, 12 8 8 3, 12 110 12 28 18 4

Index

Model-Driven Business Process Engineering 145

R RUP

14

S SCRUM Spiral Model SPMP SSADM

14 14 29 14

T T-cube TOGAF Transformations

19 96 3

U UML Unified modelling language Use case diagrams

6 6 7

V Virtual team

27

Z Zachman Framework

86