Supporting Agile Development with Participative Enterprise Modeling

Abstract

Agile Modeling provides a set of best practices of “light-weight” modeling to support the modeling process on a macro level within the agile development teams. The objective of this paper is to analyze the potential of using Enterprise Modeling in agile development projects to address some of the existing challenges of agile projects.

Keywords

• Enterprise modeling agile modeling agile development

Introduction

The Information System (IS) development community has been trying out and adopting various agile development approaches such as, e.g., eXtreme Programming (XP) [ 1 ] and SCRUM [ 2 ]. One of the strengths of agile approaches is their flexibility and ability of dealing with change efficiently. Their philosophy is development of only those artifacts that are directly related to the software product. Agile approaches typically do not prescribe which methods, languages, and tools are to be used. Instead, the emphasis is on choosing the simplest, most effective and, therefore, the most cost effective ones. To support the modeling process on a macro level within the agile development teams Agile Modeling (AM) [ 3 ] was developed. AM provides best practices of “light-weight” modeling and suggests active stakeholder involvement.

However, gathering requirements in agile methods is targeted exclusively to software development needs. The relationship between knowledge of enterprise stakeholders and software artifacts is tacit and contributes only to the software development process, not to the enterprise knowledge development on a larger scale. This phenomenon does no permit to utilize all possible benefits of requirement gathering. Enterprise Modeling (EM) [ 4 ] on the other hand has proven to be a practicable instrument for creating an integrated and negotiated model describing different aspects of an enterprise. [ 5 ] show that EM can be used for two main types of objectives – (1) developing the business, e.g. developing business vision, strategies, redesigning the way the business operates, developing the supporting information systems, or (2) ensuring the quality of the business, e.g. sharing the knowledge about the business, its vision, the way it operates, or ensuring the acceptance of business decisions through committing the stake-holders to the decisions made.

In this paper we analyze the potential of using EM, taking the EKD (Enterprise Knowledge Development) approach as an example, in agile development projects. The research approach is conceptual and argumentative based on findings of a number of qualitative research studies [ 5, 6, 7, 8 ]. The rest of the paper is structured as follows. Sections 2 and 3 summarize EM and agile development respectively. Section 4 integrates the AM and EM while section 6 presents concluding remarks. 2

Background to EKD

EKD is an EM method for developing, acquiring, and communicating early, enterprise knowledge, such as strategies, goals, or requirements, by a structured, iterative, working and modeling approach [ 4 ]. The Enterprise Model consists of set of structured, goal/problem driven models to be used for structuring and representing organizational knowledge – the modeling product. In a full enterprise model, the relationships between Enterprise Model components (see table 1) play an essential role because they allow tracing decisions. The EKD modeling process guides the knowledge acquisition, analysis, and representation. Knowledge acquisition and modeling needs to be participatory to consolidate multiple stakeholder views.

Focus Issues Components

Goals Model (GM) Vision and strategy What does the organization want to achieve or to avoid and why? Goal, problem, external constraint, opportunity

Business Rules Model (BRM) Policies and rules What are the business rules, how do they support organization’s goals? Business rule

Concepts Model (CM) Business ontology What are the things and “phenomena” addressed in other submodels? Concept, Attribute

Business Process Model (BPM) Business operations What are the business processes? How do they handle information and material? Process, external proc., information set, material set

Actors Resources Model (ARM)

and Organizational structure Who are responsible for goals and process? How are the actors interrelated? Actor, role, organizational unit, individual

Technical Component & Requirements Model(TCRM) Information system needs What are the business requirements to the IS? How are they related to other models? IS goal, IS problem, IS requirement, IS component Agile approaches all share the same values, e.g. to be flexible and to be able to deal with changes during the course of a software project. They provide a set of principles, techniques and best practices for iterative and incremental IS development, but they do not explicitly tackle modeling in terms of how to model and what. To address this, AM proposes to integrate more traditional modeling approaches with the ideas of agile development. See [ 6 ] for additional evidence about the suitability of AM in practice.

Agile approaches primarily focus on the development of a software system. The underlying assumption of agile projects is that the customer knows what kind of system is needed, what are its features, and who will use it and how. In practice, however, IS development is a part of some business development or change project. Moreover, the developers and the stakeholders may have to face a number of hard organizational problems requiring structured exploration of various business and IS development alternatives. A common situation is to set up business goals of the new IS system before the development project is commissioned. If this is done without involving the developers of the new IS, it immediately puts them at a disadvantage because not all information is properly communicated to them. The agile approaches try to address this challenge by active stakeholder involvement and having a customer representative on the development site. However, these practices might not be enough because vital knowledge has to be re-acquired. Agile teams are also not used to requiring the business people to think systemically about their business and to connect their business needs to the new IS. Mush of this knowledge is scarce and tacit – it lies in the heads of a few stakeholders. There might also be different opinions, especially concerning the future plans of the organization, which, therefore, need to be consolidated, made explicit, and transferred to the agile team. While XP suggests “customer on site”, in reality, however, only a few stakeholder types can be kept on site. High level managers such as CEOs or CFOs need to be engaged differently. 4.

Using EM in Agile Development Projects

This section analyzes the potential of using EM, taking EKD as an example, in agile development projects. We discuss the objectives and the compatibility of Agile Model Driven Development (AMDD) [ 9 ] and EKD.

In both AM and EM the group work is used to achieve consensus, understanding and commitment concerning the scope and requirements of the development project. Furthermore, [ 8 ] shows close correspondence between artefacts of AM and EM.

AMDD stage

Iteration 0: Envisioning

Initial Requirements modeling (identify high level scope and an initial requirements stack)

EM support

An EM seminar with all key stakeholders to establish the business goals of the system, to explore the business requirements and to set the overall strategy of the project. The intangible benefit is the consensus about these issues. An EM seminar to identify IS architecture on a crude level. Initial Architecture Modeling

Iteration 1-n

Iteration Modeling: Thinking Through What You'll Do This Iteration Model storming (work through specific issues, just in time (JIT) modeling, stakeholders actively participate)

Agile projects using EM should focus on the business vision and business requirements. This can be done by integrating prototyping approaches with business analysis to explore alternatives of supporting business goals and processes by IS components and features. Using EM to capture the business knowledge pertinent to the IS development project is not the same as BRUF (big requirements up front), which contradicts with the principle of iterative and incremental development and is argued against by many practitioners. AMDD is a framework for iterative and incremental modeling. Table 2 takes the EKD modeling process as basis and shows how EM is able to contribute to AMDD.

Concerning the specifics of integrating the agile way of working with EM we would like to propose the following recommendations: elaborate multiple perspectives iteratively, involve different stakeholder types, link other models and designs with the Enterprise Model, and use simple tools to support Agile EM process. See [ 8 ] for a more extensive discussion on these issues. 5

Concluding Remarks

EM has a potential to be useful in agile development projects. The proposed integration of AM and EM has been partly applied at two IS development projects at Riga Technical University, namely “Professional Orientation Information Base in Computer Science and Information Technology” and “Development of the Prototype for the Support of Inter-Institutional Flow of Knowledge”. The EKD process helped consensus building between different stakeholders while the resulting models established project’s “backbone” of knowledge. Initial experiences suggest that not only explicit artifacts of EM and AM influence project’s agility, but also the growth of participants’ tacit knowledge is to be taken into consideration. Deeper analysis of the tacit knowledge dimension in integrated AM and EM activities is a goal for future research aimed at development of methods for IS engineering of agile enterprises.

References

1. Beck , K. ( 2004 ). Extreme programming explained: Embrace change . Addison-Wesley.

2. Schwaber , K. , & Beedle , M. ( 2002 ). Agile software development with SCRUM . Prentice Hall.

3. Ambler , S. ( 2002 ). Agile modeling: Effective practices for extreme programming and the unified process (1st ed .). John Whiley & Sons Inc.

4. Bubenko , J. A. Jr. , Persson , A. , & Stirna , J. ( 2001 ). User guide of the knowledge management approach using enterprise knowledge patterns, deliverable D3, IST project “Hypermedia and Pattern Based Knowledge Management for Smart Organisations” , Royal Institute of Technology, http://www.dsv.su.se/~js/ekd_user_guide.html.

5. Persson A. , & Stirna , J. ( 2001 ), Why Enterprise Modelling? - An Explorative Study Into Current Practice , in proc. of CAiSE'01 , Springer, ISBN 3 -540-42215-3

6. Jönsson , M. ( 2004 ). Agile modeling in Sweden - from practices to principles , MSc thesis , Stockholm University and Royal Institute of Technology, Stockholm, Sweden

7. Lagerquist , I. , Lindmark , M. , Stirna , J. , & Nyfjord , J. ( 2006 ). Adoption of agile development in practice: A qualitative inquiry . In Industrial proc. of EuroSPI'06 , Finland .

8. Stirna , J. , Kirikova M. , ( 2008 ) How to Support Agile Development Projects with Enterprise Modelling, Information Systems Engineering - from Data Analysis to Process Networks , Johannesson P. and Söderström E . (eds.), IGI Publishing, ISBN: 978-1-59904-567-2

9. Ambler , S. ( 2007 ). Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development , 11 . 27 . 2007 , http://www.agilemodeling.com/essays/amdd.htm