1. 1 Evolving System Architecture to Meet Changing Business Goals An Agent and Goal-Oriented Approach Daniel Gross & Eric Yu Faculty of Information Studies University of Toronto May 2001

2. 2 The Problem How to support evolving system architectures to meet changing business goals. “the bigger picture” How to have goals among agents drive the design process.

3. 3 I know what the system does, however: –What business goals led to these architectural structures? –What happens to the structures when business goals change? Given a Telephone System architecture Drawn by a senior architect during the case study Proprietary, Centralized control architecture

4. 4 For example: adding internet browsing on the telephone sets through WAP* architecture *WAP – Wireless Application Protocol It’s a business tactic to differentiate the companies telephone set offering through enhancing the ability to design & access internet based service Open, Decentralized control architecture

5. 5 Where to place the Client in the telephone system? 1. Within Call Control ? (stick to centralized control arch.) 2. Within the Virtual Peripheral? (towards decentralized contr. arch.) 3. Within the “intelligent” phone set? (decentralized control arch.) ? More generally: Where to place other future applications in the telephone system ? How to make a decision without goals? Who cares about the alternatives and why?

6. 6 Goals originate from organizational stakeholders Organizational View

7. 7 Goals originate from organizational stakeholders Organizational View

8. 8 Modeling assumptions How to model architecture during design … when requirements notations drive architectural notations [Mylopoulos, STRAW] when acknowledging that –architecture of a system is a “living” dynamic evolving “organism” –the design process never ends but “spirals” up and down –architecture design & evolution is a social negotiation process

9. 9 Actor Notation Actor A denotes some design unit under development. Actors = (capabilities+ Goals) that eventually become components or connectors in the “finished” design For example: Denotes the “new application”, such as the WAP client, to be introduced into the current architecture We wish to show how goals are propagated among actors during design !

10. 10 Intentional Goal Dependency Actor A depends on Actor B to achieve Goal X during further design. Actors = (capabilities+ Goals) that eventually become components or connectors in the “finished” design “new application” expects the “new controller” to be designed such that it can grant ownership to a shared telephone set (not shown). Intentional dependency

11. 11 Intentional Softgoal Dependency Actor A depends on Actor B to achieve Qualities 1,2 while achieving Goal X. Actors = (capabilities+ Goals) that eventually become components or connectors in the “finished” design “new application” expects the “new controller” to be designed such that its performance is not degraded and that no processing errors occur during controlling.

12. 12 Actor Internal View Actors = (capabilities+ Goals) that eventually become components or connectors in the “finished” design Actor B needs to achieve design Goal X, Qualities 1, 2 by designing some capabilities.

13. 13 Capabilities and Goals Actor B adopts capability 1 to achieve design Goal X, and address Quality 2 Actors = (capabilities+ Goals) that eventually become components or connectors in the “finished” design Contribution Means-ends

14. 14 Alternatives during design Actor “new controller” has know-how & autonomy to adopt alternative ways of achieving design goals X. Actors = (capabilities+ Goals) that eventually become components or connectors in the “finished” design Actor “new application” & “new controller” negotiate achievement of desired qualities wrt. alternatives proposed by “new controller”

15. 15 Softgoal achieved Softgoal further propagated Distribution of design goals based on the stateless controlling alternative Actors establishing new Actors

16. 16 Some tradeoffs during design of the new controller actor Additional intentional dependencies Architecture is a social network !!

17. 17 Shared controller architecture Stateless shared controller architecture Stateful shared controller architecture Architecture is a social network !!

18. 18 Conclusions & Future work Treating architectural elements as Actors allows –Introducing, distributing, negotiating and tracing goals and their achievement by architectural elements during the design process and during evolution. –Provides the basis for goal driven design guidance Better integration of modeling views needed Methodological support –Also possible integration into Boehm et. al. work related to negotiations Stakeholder oriented viewpoints –Management view, designers view, etc. Actor/Agent extension for ITU-URN/GRL effort

19. 19 Supplements

20. 20 Reusing architectural fragments through “ISA” links Note: Creating ISA links is a step in the design process Device Controller is part of a device- sharing architecture The designer of the I/O Handler might now: Grant ownership to user services Deal with Performance and/or Minimizing processing errors to keep the user services actor happy. Device sharing architectural pattern I/O Handler is part of a telephone system architecture

21. 21 Intentional dependencies are inherited Telephone system architecture fragment Note: Inheriting intentional dependencies is a design step … … done interactively and selectively together with rationales which are recorded in the process view Note: Inheriting intentional dependencies is a design step … … done interactively and selectively together with rationales which are recorded in the process view

22. 22 Modeling Views relationships

23. 23 Partitioning of the system over time (with alternatives) Shared controller based architectures comes in two flavors

24. 24 Functional Design goals & tasks Quality requirements Design Process over time (design states)