Assessing the influence on Assessing the influence on processes when evolving the processes when evolving the software architecturesoftware architecture

By Larsson S, Wall A, Wallin PBy Larsson S, Wall A, Wallin P

Parul Patel

OverviewOverview

1. Introduction2. Method Description3. Case Study4. Related Work5. Conclusion6. Future Work

1. Introduction1. Introduction Changes in business drivers, organization, and

technology are common during the life-cycle of long-lived industrial system, Examples are:◦ Commercial components that get obsolete and

need to be replaced◦ Companies merge◦ Organization targeting new market ◦ Customer focus get changed

There is a clear need for building knowledge of interdependencies between evolution of architectures, development processes, and changes in development organizations

In this paper, different relationships between changes and the effects on product development processes and the effects on architecture are discussed

2. Method Description2. Method DescriptionDescribes relationships between

architecture, organization, or development processes when changes occur due to changes in business objectives

A method is proposed for assessing the requirements on changes in processes when an architectural change is initiated

Types of RelationshipsTypes of Relationshipso ∆B = changes in business

objectiveso ∆P = process changeso ∆O = organization changeso ∆A = changes in architectures

This method provides: Guidance concerning

specific changes in existing architecture, organization and processes

An indication on the cost and risk of the proposed changes

Business-Architecture-Business-Architecture-Process MethodProcess Method• Purpose: To

investigate and analyze the influences that a change in architecture will have on the development processes

• Consists of five steps• Major points:

Underlying business objects are made visible and clearly understood by the organization

Use of scenariosUse of reference models

Step 1Step 1 Initiate and Motivate the organization

◦A common motivation must exist for the organization

◦Based on business drivers and vision for the change, sponsors and other roles for the process investigation should be identified Sponsors need to communicate the vision and

identify the possible receivers And in final activity train these receivers

◦Outcome: An informed and prepared organization

Step 2Step 2Find requirements on affected

processes◦Based on 1st step, understanding of what

processes are affected should be created◦Activities to accomplish this:

Create a set of scenarios that describe the vision and purpose of the architectural change in more detail

An understanding of current practices should be obtained; which is captured by appraisal as it is the used practice, not the documented

Use one or more reference model; it helps the investigators to ensure that no process is missed

Step 2 (Continued…)Step 2 (Continued…) Have a workshop with affected

stakeholders Reason about whether a process is affected or

not capture the rationale for analysis document the reason for which the process is

being modified or added

◦Outcome: New requirements on the product development processes that will be used

Step 3Step 3Analyze different solutions

◦Describe different possible ways to change the affected processes

◦For each proposed change, list the consequences Ex: roles, authorities, responsibilities,

competence, documentation, communication◦Important to have a set of different

alternatives described for each process independently of other processes because the selected solution may differ depending on combined considerations for several processes

Step 4Step 4Define alternative strategies

◦Take the solutions from Step 3 and group them together to form strategies

◦ Investigate combinations of process changes because they influence each other

◦Each strategy allows a particular scenario or a group of scenarios to be implemented

◦Also include associated risks as well as steps and related effort needed to implement the process change

Step 5Step 5Decide on strategy

◦When various process changes are described and combined into strategies, the organization is ready to decide on the strategy to select

◦Basis of the decision should be: Business objectives Risk for each strategy

◦It’s important that A decision on a specific strategy is properly

communicated and discussed Documenting the decision and rationale for

the selection since environment may change and new solutions may appear

3. Case Study : 3. Case Study : DescriptionDescription Industrial control system at an ABB development

unit System has been evolved through 10 year period

and new function has been continuously added Has more than 3 million lines of C/C++ code Several different applications are built on the

same basic monolithic system Purpose:

◦ To increase the possibilities to independently develop basic functions and applications

◦ To ensure high quality software◦ To increase efficiency in the software development

Important business drivers:◦ Shortened time-to-market for new applications and

new releases of existing applications◦ Decreased cost for maintenance

Case Study: Case Study: Description Description (Cont…)(Cont…)Restructure to

divide the existing system into 3 parts◦ A kernel:

components that provide basic services

◦ A set of common extensions: is selected when defining an application specific product

◦ Application specific extensions

Case Study: Case Study: Description Description (Cont…)(Cont…)The kernel and the common extensions are

to be managed by one development group, while applications is intended to be developed at several different locations

The Base Software is the combination of the kernel and the common extensions

The Base Software SDK (Software Development Kit) should be developed with the public interfaces provided by the Base Software (the API, application programming interface)

The final result from the application development is the load file for the control system, which is added at production time

Applying the Proposed Applying the Proposed MethodMethodStep 1: Initiate and Motivate the

Organization◦The vision and the goals for

refactoring were communicated to the stakeholders

◦This approach covered the architectural influence on the product development process

◦The communication was continued throughout the project to ensure that new information and status was given to the receivers

Applying the Proposed Applying the Proposed Method (Continued..)Method (Continued..) Step 2: Find requirements

on affected processes◦ First activity was to

develop a set of scenarios to be used together with two reference models, CMMI and ISO/IEC 15288:2002

◦ Second activity was to look at the current process to understand how the system is developed today

◦ Based on these activities, the requirements for the process have been defined and described

◦ In the investigation, 4 different scenarios have been defined, with different levels of independence for application development units

Applying the Proposed Applying the Proposed Method (Continued..)Method (Continued..)Step 3: Analyze different solutions

o Performed discussions with experts in the different processes, and findings were validated through a review; Following are affected areas described with various solutions discussed: Configuration Management Product Integration Strategy Requirements on application development

units Product Integration delivery and criteria Interface Handling Verification strategies

Applying the Proposed Applying the Proposed Method (Continued..)Method (Continued..) Step 4: Define

alternative strategieso In this case, the strategies

are divided from a business perspective and are based on how the application products are packaged, distributed, and verified

o Two areas, product integration delivery criteria and interface handling, were needed independent of the chosen strategy; and are unchanged in all strategies

o The pros and cons as well as the risks have been captured, documented and reviewed for each one of the strategies

Applying the Proposed Applying the Proposed Method (Continued..)Method (Continued..)Step 5: Decide on a strategy

◦This step was delayed as the product management needed further investigation for changing the product development to be more distributed

◦The final decision was to stay with the current model, strategy 1, and gradually move toward strategy 4

◦Also allowing different locations to work in different ways and develop their capabilities overtime

Applying the Proposed Applying the Proposed Method (Continued..)Method (Continued..) Case Discussion and Lessons Learned

◦ Compared to an ad-hoc method, the Business-Architecture-Process method facilitated the definition of the proposed changes and the compilation of strategies

◦ The difference in result is that necessary changes are implemented faster and that the organization is better informed and prepared for the new technology and new processes

◦ Four observations that will affect future use of the method: By using reference model as basis, there is a risk that the

proposed changes are generic and are not connected to change of architecture

Some changes might only be depending on the changed business objectives and may not result in architectural change

Its important to continuously have a dialog with sponsor To minimize the time and effort, it is important to plan

workshops and other interaction early, ensuring that effort spent is balanced in expected gains and reduced problems

4. Related Work4. Related WorkArchitecture Tradeoff Analysis Method

(ATAM): To assess the consequences of architectural decisions in the light of quality attributes requirements

Cost Benefit Analysis Method (CBAM): Aids in the process of making architectural decisions by providing a return of investment (ROI) ratio

Chainwise Paired Comparison method (CPC): Aids in selecting a specific architecture over another

Analytical Hierarchy Process (AHP): Provides a structured reasoning why a specific architecture is chosen

5. Conclusion5. ConclusionThe method proposed here makes use of

the scenarios and process reference modelsCombining solutions to process

requirements enable stakeholders to understand implications of different decisions

The case study has resulted in identification of additional details as useful input to the method

The case study supports the proposal that structured method supports efficient and effective investigations of process changes due to architectural changes

6. Future Work6. Future WorkAdd details in description in the

method, how each step should be performed and provide additional examples

Add details regarding scalability and resource needs for using the model in different types of organizations

Expand the method to describe remaining relationships