table of contents - The AGILE ITEA Project website

��Ã��Ã��Ã��Ã 

��Ã��Ã 

Version : 1.0 

Date : 2005.11.29 

Pages : 19 

Authors 

Teodora Bozheva 

Status 

Final 

Confidentiality 

Public 

$JLOH 'HOLYHUDEOH �� 

$QDO\VLV RI WKH 

VRIWZDUH SUDFWLFHV 

DQG WKH EXVLQHVV 

PRGHOV LQ WKH GRPDLQ 

RI WKH HPEHGGHG 

VRIWZDUH 

Abstract 

This document makes an overview of the 

business models used in organizations 

developing embedded software and analyses 

the cases, in which the application of agile 

practices is beneficial to the organization and 

the business.

Analysis of the software practices 

and the business models in the 

domain of the embedded software 

Deliverable ID: D2.4 

TABLE OF CONTENTS 

© Copyright AGILE Consortium 

Page : 2 of 19 

Version: 1.0 

Date : 29.11.2005 

Status : Final 

Confid : Public 

1. Introduction ................................................................................................................................. 4 

2. Business models ........................................................................................................................ 4 

2.1 What is a business model .................................................................................................... 4 

2.2 Business models of organizations developing embedded software................................... 5 

2.3 The new busines models ..................................................................................................... 6 

3. Agile practices and business models ...................................................................................... 7 

3.1 Agile practices for embedded software development ......................................................... 8 

Home grounds ..............................................................................................................................9 

Business rationale to use agile staff...........................................................................................10 

3.2 Business modelling (BM) ................................................................................................... 15 

References ........................................................................................................................................ 19





CHANGE LOG 

Vers. Date Author Description 



Version: 1.0 

Date : 29.11.2005 



1 2-12-2005 T. Bozheva (ESI) First version of the document 

APPLICABLE DOCUMENT LIST 

Ref. Title, author, source, date, status Identification

1. INTRODUCTION 







Version: 1.0 

Date : 29.11.2005 



This document makes an overview of the business models used in organizations 

developing embedded software and analyses the cases, in which the application of 

agile practices is beneficial to the organization and the business. 

The deliverable is part of WP2 of the AGILE project. 

Section 2 of the deliverable discusses the concept business model and the 

challenges, which the implementation of a business model meets in the time of 

turbulent economy and business evolution. 

Section 3 gives insights in two approaches for increasing the efficiency of the 

business processes of an organization: by introducing appropriate agile practices and 

by modeling the business processes. 

The document is addressed to business managers and project leaders in an 

embedded software development company. 

2. BUSINESS MODELS 

2.1 WHAT IS A BUSINESS MODEL 

A business model (also called a business design) is the mechanism by which a 

business intends to generate revenue and profits. It is a summary of how a company 

plans to serve its customers. It involves both strategy and implementation. It is the 

totality of: 

o How it will select its customers 

o How it defines and differentiates its product offerings 

o How it creates utility for its customers 

o How it acquires and keeps customers 

o How it goes to the market (promotion strategy and distribution strategy) 

o How it defines the tasks to be performed 

o How it configures its resources 

o How it captures profit [2] 

Whereas business strategy is primarily about the overall positioning of a business 

within the business environment, the term "business model" also includes key 

structural and operational characteristics of a business. In other words, when used 

properly, "business model" is a broader description of a business than just its 

strategy. 

In the most basic sense, a business model is the method of doing business by which 

a company can sustain itself -- that is, generate revenue. The business model spellsout 

how a company makes money by specifying where it is positioned in the value 

chain. 

The oldest and most basic business model is the shop keeper model. This involves 

setting up a store in a location where potential customers are likely to be and 

displaying a product or service.







Version: 1.0 

Date : 29.11.2005 



Over the years, business models have become much more sophisticated. The bait 

and hook business model (also referred to as the "razor and blades business model" 

or the "tied products business model") was introduced in the early 20th century. This 

involves offering a basic product at a very low cost, often at a loss (the "bait"), then 

charging excessive amounts for refills or associated products or services (the 

"hook"). Examples include: razor (bait) and blades (hook); cell phones (bait) and air 

time (hook); computer printers (bait) and ink cartridge refills (hook); and cameras 

(bait) and prints (hook). An interesting variant of this model is a software developer 

that gives away its word processor reader for free but charges several hundred 

dollars for its word processor writer. 

In the 1950s new business models came from McDonald’s Restaurants and Toyota. 

In the 1960s the innovators were Wal-Mart and Hypermarkets. The 1970s saw new 

business models from Federal Express and Toys R Us; the 1980s from Blockbuster, 

Home Depot, Intel, and Dell Computer; the 1990s from Southwest Airlines, eBay, 

Amazon.com, and Starbucks. Poorly thought out business models were a problem 

with many dot-coms. 

Each of these business model innovations can give a company a sustainable 

competitive advantage. But times are changing and companies must continuously 

rethink their business design. Companies must change their business models as 

value migrates from industry to industry. Ultimately the success or failure of a 

company depends first on how well its business design matches their customers’ 

priorities. 

2.2 BUSINESS MODELS OF ORGANIZATIONS DEVELOPING 

EMBEDDED SOFTWARE 

Generally speaking, embedded software brings two types of revenues from 

manufacturers that incorporate a technology in their products. First, revenues from 

the license of the software itself, that is, licensing revenues and royalties earned for 

each product shipped. The more products shipped by a manufacturer, the higher its 

royalties. Second, revenues from professional services, that is, providing support and 

counsel during product planning and product development. These support activities 

contribute to enhancing the market value of the manufacturer’s products, which, in 

turn, can positively impact the potential royalty stream. 

Nowadays, organizations that develop embedded software cannot be wedded to any 

particular market segment, and would serve as brokers and middlemen with 

expertise not just about specific application domains but the connectivity elements 

and middleware needed to make a system work in a specific, but dynamically 

changing environment. Most important, the companies have to be fast on their feet, 

keeping track of changes in markets, standards and technologies and adjusting their 

mix of tools and building blocks and their expertise as needed. Therefore such 

companies need also means to rapidly adapt their business models to the changing 

business and market scene. 

Such companies would have to act as middleman to several constituencies -- the 

hardware vendor, the software suppliers and the developer. Therefore they would 

have to be platform independent, and would be required to supply technical advice







Version: 1.0 

Date : 29.11.2005 



that isn’t biased by a particular product agenda. This advice would involve everything 

from recommendations on technical features to make vs. buy decisions for certain 

software functionality. In addition, this middleman company would have to have 

comprehensive insight into the hundreds of software suppliers, understand what 

products are offered. [3] 

A number of companies in the market are trying to rebuild themselves into such 

middleman/broker entities. Some such as Wind River have acquired a number of 

companies to gather all of the building blocks for the many varieties of devices used 

in the embedded market and in markets outside embedded that find embedded tools 

useful. Accelerated Technology allowed itself to be acquired by Mentor Graphics in 

hopes that this would give it the financial muscle to build the pieces it needs. The 

same is true of Metrowerks, which has allied itself with Motorola. Other still 

independent software vendors such as Green Hills, OSE, Lynuxworks and QNX saw 

the shift coming years ago and have had the time to slowly add capabilities. 

Which is the right approach? Or will such a new kind of business model require a 

startup that is not wedded to the past and with the right mix of expertise from the 

embedded market and the half a dozen or so new segments that have emerged 

since the collision? Are the traditional embedded software producers and vendors 

doing their jobs? What approach to take to transform them into a prospering type of 

company in the e-era? 

2.3 THE NEW BUSINES MODELS 

Great shifts - genuine and radical transformation - have been shaping the economy 

and business environment in recent decades. Technology, especially information and 

communication one, has radically altered the requirements for building and managing 

a successful business. In this new business climate, although the basic commandand-control 

business model has survived, it has lost its effectiveness significantly. 

The old principles no longer work in the new age. Businesses have reached the old 

model’s limits with respect to complexity and speed. The real problem is "a ruinously 

dysfunctional mismatch between today’s business environment and the classic 

business model... The classic business model that has dictated the structure of every 

company from General Motors to Microsoft is so at odds with contemporary 

economic currents that it is a matter of time to disappear. Quite simply, the wrong 

model may transform a company into the vehicle of its own death. " [4] 

Traditional corporations are overstructured, overcontrolled, and overmanaged, but 

underled. Top managers should rather concentrate of that handful of real managerial 

leadership tasks that will bring success in the future. Thus, a new business model is 

emerging, a model where "most of key missions of the organization are distributed to 

the myriad individual pieces and unity comes from the vigor of people and the free 

flow of knowledge, not a burdensome central headquarters." 

The successful companies in the future will be ones wise enough to harness the full 

potential of the entire organization in the rapidly changing business environment. 

"The world is going to be too tough and competitors too ingenious as companies are 

shaken loose from traditional ways of conducting business. The winners will be the







Version: 1.0 

Date : 29.11.2005 



unbridled firms that are responsive to challenges and adroit in both creating and 

capturing opportunities. To match a business environment that is more networked 

within and among companies, the ability to manufacture value will have to be 

distributed across the company to much a greater extent than in the past."[4] 

New Focus 

Today’s most successful executives, while still greatly concerned with cost structure, 

maximizing operational effectiveness, and business process reengineering, have 

shifted their focus to issues of how to build capabilities for faster growth, how to 

attract and retain the best people, how to develop leaders at all levels in the 

company, how to manage knowledge effectively, how to become a true learning 

organization, and how to be more effective global corporations. 

The new business models have to have much stronger focus on the basics of what 

ultimately creates value today - people, knowledge, and coherence. It fosters the 

creation of value and ensures that each piece of the business contributes to systemwide 

value. It also goes beyond the workplace and the interface between government 

and business and looks into building a favorable social climate within and around the 

company. 

Many leading companies around the world have made attempts to evolve a new 

business model. While the paradigm is shifting, it has yet to reach the new stable 

state however. 

3. AGILE PRACTICES AND BUSINESS MODELS 

An agile enterprise reacts quickly and efficiently to changes, such as market 

opportunities or mergers and acquisitions. The ability to react quickly translates to 

top-line revenue, and the ability to adjust efficiently equals lower costs. [6] 

Making an enterprise agile is easier said than done. However, there are a couple of 

approaches to start with: 

o Consider increasing the agility of the organizational processes by means of 

introducing appropriate agile practices 

o Model the business processes to establish a common understanding of 

shared and compound processes, to facilitate traceability of elements 

involved in a process and to improve the efficiency of the process adoption. 

o Provide necessary infrastructure and technological facilities to ensure flexible 

working conditions, e.g. cable and wireless network connections, 

teleconference facilities, etc. 

The bottom line is that agility is not something that can be implied into a company, 

but using it as a guiding principle can yield measurable benefits. 

The next sections are focused on discussing the first two approaches, while the third 

one remains out of the scope of this deliverable.







Version: 1.0 

Date : 29.11.2005 



3.1 AGILE PRACTICES FOR EMBEDDED SOFTWARE DEVELOPMENT 

Within the AGILE project, we have defined 

Agility in embedded SW development is an ability to make changes in order to 

maximize the overall customer value whilst minimizing the loss of initial customer 

value; customer value being the cross function of money, time, effort, functionality or 

any quality characteristics like reliability or dependability. 

The work in WP2: Framework for Agile development of embedded software is 

devoted to developing a framework for the embedded systems domain. The 

framework conjoins Agile software development process, business process, support 

processes and process architecture. 

Speaking about agile processes, we should state that in the field of software 

development there are no practices or processes that fit all the projects. Today’s 

enterprise solutions are complex, time critical and developed against rapidly 

changing business needs. 

Agile methods recognize these factors and instead of trying to resist them, embrace 

changes via business value based prioritisation, short feedback cycles and qualityfocused 

development. When appropriately used they bring a number of business 

benefits as better project adaptability and reaction to changes, reduced production 

costs, improved systems quality and increased user satisfaction with the final 

solution. 

There are a growing number of methods for agile software development, and a 

number of agile practices such as Scott Ambler’s Agile Modeling [7]. The best known 

ones include: eXtreme Programming (XP) [8], Scrum [11], Feature Driven 

Development (FDD) [13], Adaptive Software Development (ASD) [10], Lean 

Development (LD) [9]. Authors of all of these approaches (except LD) participated in 

writing the Agile Software Development Manifesto [14], which establishes the 

backbone of all the agile approaches. 

While individual practices vary, they fall into six general categories: 

• Visioning. A good visioning practice helps assure that agile projects remain 

focused on key business values (for example, ASD’s product visioning 

session). 

• Project initiation. A project’s overall scope, objectives, constraints, clients, 

risks, etc. should be briefly documented (for example, ASD’s one-page 

project data sheet). 

• Short, iterative, feature-driven, time-boxed development cycles. Exploration 

should be done in definitive, customer-relevant chunks (for example, FDD’s 

feature planning). 

• Constant feedback. Exploratory processes require constant feedback to stay 

on track (for example, Scrum’s short daily meetings and XP’s pair 

programming). 

• Customer involvement. Focusing on business value requires constant 

interaction between customers and developers (for example, DSDM’s 

facilitated workshops and ASD’s customer focus groups).







Version: 1.0 

Date : 29.11.2005 



• Technical excellence. Creating and maintaining a technically excellent 

product makes a major contribution to creating business value today and in 

the future (for example, XP’s refactoring). 

Some agile approaches focus more heavily on project management and 

collaboration practices (ASD and Scrum) while others such as XP focus on software 

development practices, although all the approaches touch the six key practice areas. 

Good introduction to the agile approaches can be found in [15] and [16]. 

Moreover, the work within AGILE WP2 focuses extensively on the development of a 

framework of agile practices for embedded software development. 

Home grounds 

B. Boehm and R. Turner [17] define five factors that organizations and projects can 

use to determine whether they are in either the agile or the traditional, disciplined 

home grounds, or somewhere in between. The term “disciplined” is only used to refer 

to the traditional plan-driven methods without implying that the agile methods are 

non-disciplined. 

Table 1 summarizes the home grounds: 

Characteristics Agile Disciplined 

Application 

Primary Goals Rapid value; responding to 

change 

Predictability, stability, high 

assurance 

Size Smaller teams and projects Larger teams and projects 

Environment Turbulent; high change; project- Stable; low-change; 

Management 

focused 

project/organization focused 

Customer Dedicated on-site customers; As-needed customer 

Relations focused on prioritized increments interactions; focused on 

contract provisions 

Planning and Internalized plans; qualitative Documented plans, 

Control 

control 

quantitative control 

Communications 

Technical 

Tacit interpersonal knowledge Explicit documented 

knowledge 

Requirements Prioritized informal stories and Formalized project, capability, 

test cases; undergoing 

interface, quality, forseeable 

unforseeable change 

evolution requirements 

Development Simple design; short increment; Extensive design; longer 

refactoring assumed inexpensive increments; refactoring 

assumed expensive 

Test Executable test cases define Documented test plans and 

requirements, testing 

procedures







Version: 1.0 

Date : 29.11.2005 



Characteristics 

Personnel 

Agile Disciplined 

Customers Dedicated, collocated CRACK* CRACK* performers, not 

performers 

always collocated 

Developers At least 30% full-time experts 50%** experts able to tailor 

able to tailor [and revise] a [and revise] a method to fit a 

method to fit a new situation; new situation; 

no personnel, who, with training, 10% throughout; 

is able to perform just procedural 30% personnel, who, with 

steps (e.g. coding a simple training, is able to perform 

method, simple refactoring); just procedural steps (e.g. 

no personel, who is not able or coding a simple method, 

not willing to collaborate or follow simple refactoring); 

shared methods. 

no personel, who is not able 

or not willing to collaborate or 

follow shared methods. 

Culture Comfort and empowerment via Comfort and empowerment 

many degrees of freedom via framework of policies and 

(thriving on chaos) 

procedures (thriving on order) 

* Collaborative, Representative, Authorized, Committed, Knowledgable 

** These numbers will particularly vary with the complexity of the application 

Table 1. Agile and Disciplined Method Home Grounds 

Since all the items in the table are self-explained, we are not going to discuss them in 

more details. 

Business rationale to use agile staff 

One can find different lists of reasons why the agile methods should be practiced in 

the field of embedded software development and what are the business benefits from 

applying them. Definitely the fundamental factors include: 

• Improved return on investment (RIO) 

• Early detection and cancellation of failing products 

• Reduced delivery schedules 

• Higher quality software 

• Improved control of a project 

• Reduced dependence on individuals and increased flexibility [18] 

Improved return on investment 

This is the fundamental reason to use agile methods, and it’s achieved in a number 

of different ways. In an agile project, the initial requirements are the baseline for ROI. 

If the project runs to completion with no changes, then the business will get the 

projected returns. However, by providing frequent opportunities for customer 

feedback, agile methods let customers steer the project incrementally, taking 

advantage of new insights or changed circumstances to build a better system and 

improve the ROI.







Version: 1.0 

Date : 29.11.2005 



By delivering working software early and often, agile projects also present 

opportunities for early deployment and provide earlier return on smaller initial 

investments. 

Early cancellation of failing projects 

It’s a common observation that projects go well enough during the bigger part of its 

duration and afterwards it is delayed for months or even cancelled. In such a 

situation the sponsors face a difficult choice: to stop it or to continue funding it hoping 

to get some ROI. 

One of the reasons for getting in such a situation is optimistic reporting of progress 

on abstract intellectual tasks such as analysis and design, because it is difficult, if not 

impossible to estimate them correctly until the real implementation begins. This 

means that the traditional methods suppose a hidden delay, which could be only 

determined when coding has started. 

Agile projects avoid this situation by performing analysis, design and implementation 

in short increments, and judging progress by the delivery of working software, which 

gives much more solid feedback on actual vs planned progress. Overly optimistic 

planning becomes obvious much earlier in agile projects, giving the sponsor the 

chance to review the costs and benefits of the project, and where appropriate cancel 

the project with minimal investment. 

Reduced delivery schedules 

The agile methods instruct focussing on high-priority features and using short 

development iterations. This reduces the delivery schedules, which opens better 

business and market opportunities. 

Developing adaptable products is an aim of most of the software organizations. By 

maintaining the product in a running and near shippable state, modifications to it can 

be quickly introduced. The ability of the team to embrass the changes required by the 

clients and rapidly incorporate them in the current product is a powerful mean to 

retain satisfied customers. 

Higher quality 

Of the four fundamental variables that can be used to control a software development 

project, cost, time, scope and quality, most agile methods explicitly use scope as 

their control variable. All agile methods emphasise the production of high quality 

software, and extreme programming in particular adds a number of practices to 

support this objective. 

The participants in the eXPERT project directly observed the higher quality produced 

using the XP+PSP [19] method. For instance the defects uncovering and removal 

has followed a stable trend without accelerations, which were typical for previous 

projects. Figure 1 clearly shows this fact.

140 

120 

100 

80 

60 

40 

20 

0 

25.10.2002 

08.11.2002 

Improved control 




22.11.2002 

06.11.2002 


New, Fixed and Closed Bugs Trend 

20.12.2002 

10.01.2003 

24.01.2003 

07.02.2003 

21.02.2003 

07.03.2003 

21.03.2003 

04.04.2003 

18.04.2003 

Fig. 1: Bugs tend applying the eXPERT mehod 



Version: 1.0 

Date : 29.11.2005 



New 

Fixed 

Closed 

Agile projects typically produce fewer paper artefacts. However, at the end of every 

iteration (which is up to two months long) they deliver a running product, which gives 

sponsors and customers improved visibility and control of a project. This is further 

enhanced by emphasis on integrated, multi-disciplinary teams, where information is 

routinely shared, and highly visible. 

Reduced dependence on individuals and increased flexibility 

Agile projects emphasise sharing of information, and performing analysis, design and 

coding on a team, rather than individual basis. This helps prevent situations where 

development is critically dependent on an individual, who might become unavailable 

on short notice. It also means that development doesn’t become bottlenecked. On an 

agile project it should be possible to get everyone on the team working in the same 

area of the system, and change this area from one week to another depending on 

business priorities. 

To wrap up, the agile methods do deliver direct benefits to business and for projects 

in turbulent environments, the flexibility and feedback provided by these practices 

may be particularly critical. 

Some Statistics 

During November 2002 to January 2003, Shine Technologies ran a web-based 

survey to gauge the market interest in Agile Methodologies. The survey consisted of 

10 questions, and received 131 valid submissions. Here are some of the results [20]:





Has adoption of Agile processes altered the quality of your applications? 



Version: 1.0 

Date : 29.11.2005 



Adoption of Agile processes has had a significant effect on the quality of applications 

delivered. Of knowledgeable respondents, 88% claimed better or significantly better 

quality. Across all respondents this number falls to 84%. Only 1% of knowledgeable 

respondents believed that quality was adversely affected in any way. 

Has adoption of Agile processes altered the cost of development? 

Across respondents with average knowledge or better, 48.6% believed that 

development costs were reduced. Including the responses that indicated that costs 

were unchanged, a whopping 95% believe Agile processes have either no effect or a 

cost reduction effect.







Version: 1.0 

Date : 29.11.2005 



Has adoption of Agile processes altered the level of business satisfaction with 

the software? 

In the most stunning finding of the survey, business satisfaction of better or 

significantly better was a phenomenal 83% for respondents with average knowledge 

or better. Only 1% believe it has had a negative effect. 

What feature of your Agile processes do you like the most? 

The most positive features of Agile processes were “Respond to change over plan” 

(47.3%) and “People over processes” (30.5%). This appreciation of a responsive, 

people-centric model is a striking change from previous methodologies that value 

plans and processes.







Version: 1.0 

Date : 29.11.2005 



What proportion of projects do you believe are appropriate for Agile 

processes? 

Only 16% of respondents believe that Agile processes are applicable to all projects. 

This is in line with the Agile belief that it should be applied only where it will deliver 

benefit. Interestingly 88.5% of respondents believe that Agile processes should be 

used at least half the time. This indicates that Agile processes should be used only 

for the right projects, and that there is room for other methodologies to sit along side 

Agile and be used on a project-by-project basis as appropriate. 

3.2 BUSINESS MODELLING (BM) 

Business modeling is a technology that many companies would say they are 

applying. The application of BM in industry is predominantly for Business Architecture 

definition and Business Process Management, and the comprehension of what it is 

and how to use it is linked to consultancy and modelling expertise. Industrial use 

spans from the definition of business plans to the definition of the ISO 9000 

compliant quality system. Many practices are considered as business modelling by 

the industry. 

The new era for BM is driven by the advent of more advanced approaches, 

methodologies, infrastructures and platforms and a need for families of solutions that 

allow predictable customisation. 

This means that first there is a need to make the industry understand the future 

meaning and impact of business modelling as a comprehensive definition of the 

business knowledge spaces and their knowledge dimensions and inter-relationships. 

BM must build on aspects such as business processes, organisation, products and







Version: 1.0 

Date : 29.11.2005 



services, information systems, decision making approach, etc. Business modelling 

comprises also the ability to show the information is many different ways; this is, to 

provide different views depending on the observer, the perspective and the objective 

pursued. Finally, business modelling is the framework and the mean to establish a 

knowledge based organisation that is able to keep, manage and share the 

appropriate information among the appropriate players. 

Moving to the context of the collaborative enterprise, new requirements are imposed 

over business modelling technology and, on the other hand, the potential of profiting 

from the technology increases exponentially. Business models provide in this sense 

the basis for a common understanding of the collaboration and the means for the 

specification of such collaboration. 

In the context of business modelling of collaborative enterprises, the model is the key 

concept and the model drives both the design-time specification and the run-time 

operation of the enterprise. 

In the ideal world, the model is the element from which all the business views and 

systems are generated. This is probably the dream towards which the technology on 

business modelling will progress. 

The application of a business modelling method should not only support single steps 

of factory planning. It has to guide and support the whole project. Therefore, it is 

necessary to reveal all aspects which are relevant to clarify weak points, to show 

potentials for optimisation and their contribution to the objectives of the enterprise. 

The following modelling phases can be distinguished: 

o system delimitation, 

o model design, 

o model evaluation and utilisation and 

o model modification. 

The purpose of the system delimitation is a well-aimed selection and limitation of the 

model which is to be prepared. It is indicated which enterprise-specific object classes 

and function areas have to be considered. The motto is ‘fewer equals more’. 

The model design is the phase of the composition of models. In operational planning 

projects enterprise-specific models are usually used to illustrate the actual state with 

so-called ‘actual state models’. The model design is carried out in three basic steps: 

o Identification of the relevant enterprise-specific class structures for products, 

resources and orders within the delimited system; 

o Development of the two main perspectives: information model (identification 

of the class-describing attributes as far as necessary) and function model 

(description of functions and processes performed on the objects); 

o Derivation of partial models to clarify relevant planning aspects. 

In the phase of model evaluation the developed models are identified. The potentials 

for improvement are estimated and possible suggestions for optimisation are 

evaluated. Improvement potentials, which can be realised by means of abolishing 

weak points, should be evaluated according to 

o the degree of an improved accomplishment of enterprise goals, and 

o the expenditure necessary to abolish weak points.







Version: 1.0 

Date : 29.11.2005 



The phase of model modification transfers the actual state into an ideal state. In 

general, the extended use of actual state models is far more effective and entails less 

expenditures. (Fig 2 shows the modelling sequences). 

The results of a model-based business process reengineering project appear to 

include an effective support of teamwork, a fairly simple opportunity to participate and 

an easiness to follow and understand the entire project. However, it also has an 

effect on costs, time demand and quality of the project work and the concepts to be 

compiled. 

project phases 

project specification 

goal determination 

modelling 

phases 

analysis of the actual state 

+ inquiry of the actual state 

+ identification of weak points 

estimation of improvement potentials 

development of concepts 

realization 

system delimitation 

determination of required 

model delimitation 

and detail 

model forming 

model of goals, i.e. 

in a goal tree 

actual state description 

+ main modelling views 

+ special views 

model evaluation 

analysis of actual 

state description 

comparison: actual 

state /goals 

comparison: actual 

state/ideal concepts 

model modification 

description of ideal 

state 

description of 

realized state 

Fig2: Relation between the Phases of Projects and Modelling Phases 

Example: Analysis of Potentials 

To fulfil the objectives of cost reduction as well as lead time and product quality 

improvements, the process of developing gears in an automotive enterprise is to be 

optimised. The aim is to utilise potentials which can be revealed through an 

application of CAD/CAM technologies as information- and communication 

instruments. It should optimise the overlapping communication between all 

departments involved in the simultaneous engineering process. In the first step, this 

should occur with regard to the processes of product development and the 

simultaneous production design of gears. The expected results included: 

o the reduction of costs and times to start a new series of products, 

o the reduction of costs and times to modify the running batch production, and 

o the reduction of the lead times for a newly developed gear by one year. 

Here, the CAD/CAM development should be realised according to the motto ‘Do what 

is necessary, not what is possible!’. 

For the optimisation of the pre-production processes and for a meaningful information 

management an analysis and understandable description of the overlapping process 

chains is necessary. For that purpose, IEM was used as a ‘tool’ to represent the







Version: 1.0 

Date : 29.11.2005 



actual state and possible ideal concepts transparently. Especially in order to gain the 

synergies of overlapping or simultaneous processes, a common basis of 

understanding of all involved departments is necessary in a way which considers all 

decision-relevant aspects and which relates them to each other. 

The analysed business processes concerned the departments of 

development/construction, shop floor planning, work preparation, quality assurance, 

production and assembly. To identify the demands for an effective and inexpensive 

production of a new gear as well as possibilities for an intensified early inclusion of 

the relevant skills the analysis began with the production and assembly. The 

following procedure was chosen to identify weak points and potentials for the use of 

know-how and intensified communication: 

In the first step of the model design, the essential application of specific IEM object 

classes and the processes for their development and planning were identified and 

modelled. The following classes were formed: 

o product class ‘gears’, subdivided into ‘automatic gears’ and ‘mechanical 

gears’, 

o product class ‘gear parts’, subdivided into ‘cases’, ‘shaft’, ‘toothed gears’ and 

‘mechanical small parts’, and 

o resource class ‘organisational units’ which execute the functions. 

The different functions in their logical process, the departments and staff involved in 

the function execution, the used data documents, the information systems and 

existing data flows, the average execution times and the data which the production 

know-how which is regarded as necessary were identified and modelled. 

Using the detailed models, misunderstandings, contradictions and diverging opinions 

about the actual process were identified, discussed and eliminated. The result was 

an adjusted and verified description of the process chains for the product 

development and the production design from the point of view of the production and 

assembly departments. Subsequently, corresponding inquiries of the other involved 

plant areas occurred. The processes could therefore be completed, detailed, clarified 

and verified. A gradual completion of the process documentation throughout all 

involved areas took place. This led to a common understanding of the total process. 

During the entire actual state analysis further models were developed in order to 

illustrate aspects which during the analysis turned out to be relevant. 

Examples for documents generated during the actual state analysis were 

descriptions of: 

o the logical work flow, 

o the chronological work flow in a GANTT-diagram, 

o a matrix for organisational units executing the functions, 

o a description of data documents and their applications, and 

o a data flow-diagram describing the communications between the functions. 

The analysis of the actual state resulted in: 

o the transparency and common understanding of the entire process chains, 

o the identification of weak points, 

o the evaluation of improvement potentials, and







Version: 1.0 

Date : 29.11.2005 



o the specification of the necessary data and the data quality necessary to 

synchronise the execution of functions. 

REFERENCES 

[1] http://digitalenterprise.org/models/models.html 

[2] http://en.wikipedia.org/wiki/Business_model 

[3] http://www.embedded.com/shared/printableArticle.jhtml?articleID=9900929 

[4] Bruce A.Pasternack and Albert. J. Viscio. "The Centerless Corporation" 

(1998) 

[5] First version of state of the art in enterprise modeling techniques and 

technologies to support enterprise interoperability, Deliverable D.A1.1.1, 

ATHENA project (FP6-IP-507849) 

[6] Johna Till Johnson, Enabling the agile enterprise, Network World, 11/08/04 

(http://www.networkworld.com/cgi-bin/mailto/x.cgi) 

[7] Scott W. Ambler: Agile Modelling, John Wiley&Sons, Inc. (2002) 

[8] Beck K: Extreme Programming Explained: Embrace Change, Addison- 

Wesley (2000) 

[9] Poppendieck M., Poppendieck T.: Lean Software Development: An Agile 

Toolkit for Software Development Managers, Addison-Wesley (2003) 

[10] Highsmith J.A: Adaptive Software Development: A Collaborative 

Approach to Managing Complex Systems, Dorset House Publishing (2000) 

[11] Schwaber K., Beedle M.: Agile Software development with Scrum, 

Prentice Hall (2002) 

[12] http://www.dsdm.org 

[13] Palmer S., Felsing J., A Practical Guide to Feature-Driven 

Development, Prentice Hall (2002) 

[14] www.agilemanifesto.org/ 

[15] P. Abrahamsson et al., Agile Software Development Methods Review 

and Analysis, VTT Publications 478, 2002 

[16] D. Cohen et al, Agile Software Development, A DACS State-of-the-art 

Report, 2003 

[17] B. Boehm, R. Turner, Rebalancing your Organization’s Agility and 

Discipline, IEEE Computer, June 2003 

[18] Why Use Agile Methods? Steve Hayes, ZDNet Australia, 7July 2003, 

http://uk.builder.com/manage/project/0,39026588,20275975,00.htm 

[19] eXPERT project (www.esi.es), Nemetschek’s case study 

[20] Agile Methodologies Survey Results, Shine Technologies, 2003, 

www.ShineTech.com

table of contents - The AGILE ITEA Project website

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?