1. Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel

2. Overview 1. Introduction 2. Method Description 3. Case Study 4. Related Work 5. Conclusion 6. Future Work

3. 1. 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

4. 2. Method Description Describes 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

5. Types of Relationships o ∆B = changes in business objectives o ∆P = process changes o ∆O = organization changes o ∆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

6. Business-Architecture-Process 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 scenarios Use of reference models

7. Step 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

8. Step 2  Find requirements on affected processes ◦ Based on 1 st 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

9. 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

10. Step 3  Analyze 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

11. Step 4  Define 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

12. Step 5 Decide 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

13. 3. Case Study : Description 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

14. Case Study: Description (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

15. Case Study: Description (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

16. Applying the Proposed Method  Step 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

17. Applying the Proposed 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

18. Applying the Proposed 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

19. Applying the Proposed Method (Continued..)  Step 4: Define alternative strategies o 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

20. Applying the Proposed 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

21. Applying the Proposed 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

22. 4. Related Work Architecture 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

23. 5. Conclusion The method proposed here makes use of the scenarios and process reference models Combining 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

24. 6. Future Work Add 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