This presentation, given on the Software Architecture course at the University of Brunel, discusses the interplay between architecture and design. How the designer and architect are really different roles and ones that often have competing goals.

1. The Architect ’ s Two Hats Ben Stopford Architect High Performance Computing RBS

2. Once upon a time

3. In a land far far away

4. There was a designer

6. And an architect

8. And they didn ’t really get on

9. OK – that ’s not entirely true – but they have competing objectives

10. This is the story of the architect ’s two hats

11. So what are the two hats all about?

14. So lets look at how design works in industry

15. We ’ ll look at architecture for performance a bit later, right now lets look at design

16. Software Design

18. So how to we avoid this?

19. We design our solution well so that it is easy to understand and change

20. And we all know how to do that right? I ’ m going to play with you a bit now….

21. We Design our System Up Front

22. … with UML

23. AND… We get to spot problems early on in the project lifecycle. Why is that advantageous?

24. Why? Because it costs less to get the design right early on, see: Low cost of change early in lifecycle

25. So we have a plan for how to build our application before we start coding. All we need to do is follow the plan!!

26. Well….. That ’s what we used to do… … but problems kept cropping up…

29. Ahhh, those pesky users, why can ’t they make up their minds?

30. So… …in summary…

31. We find designing up front hard…

32. ...and a bit bureaucratic

33. … and when we do get it right the users generally go and change the requirements…

34. … and it all changes in the next release anyway.

35. So are we taking the right approach

36. Software is supposed to be soft. That means it is supposed to be easy to change.

37. So is fixing the design up front the right way to do it?

38. But we ’ve seen that changing the design later in the project life cycle is expensive!

39. So does the cost curve have to look like this?

40. Can we design our systems so that we CAN change them later in the lifecycle?

41. The Cost of Change in an Agile application

42. How

43. By designing for change ** But not designing for any specific changes *** And writing lots and lots of tests

44. Agile Development facilitates this Code Base Test Test Test

46. This means that your system ’s design will constantly evolve.

47. So what does this imply for the Designer?

48. It implies that the designer must constantly steer the application so that it remains easy to understand and easy to change .

49. With everyone being responsible for the design.

50. So the designers role becomes about steering the applications design through others.

51. Shepherding the team!

55. Now we can switch to the architects hat.

56. Architecting for performance And why it can fight against good design

57. If speed is going to be a problem…. Then evolutionary design alone may not work

58. We need to seed the design with clever architectural decisions to ensure we get the speed we need

59. We use patterns and frameworks that increase speed But often at the expense of a clear programming model. i.e. these patterns can obfuscate the implementation.

60. How it fits together: A project timeline Set-up Architecture Design: Push patterns and reuse etc Amend Architecture

61. So lets look at how we architect for speed

63. Load Balancing: Horizontal Scalability

64. Load balancing is great way to get horizontal scalability without affecting the programming model much!!

65. But it is limited by the time taken for a single request i.e. it allows us to handle more load, but does not allow us to reduce the time taken to execute single process

66. What if we want to make a single (possibly long running) processes faster? Lets look at an example

67. Sum the numbers between 1 and 10,000,000 int total for (n =1 to 10,000,000){ total+=n } A service has a hard limit on how fast it can execute this, defined by it ’s clock speed. Load balancing won ’t speed this up.

71. This is scaling up

72. But it costs

73. But we can also scale out. i.e. lots of normal hardware linked together

74. Scaling Out is Cost Effective Scaling out is much more cost effective per teraflop than scaling up.

75. But it adds complexity to the programming model

76. Key Point: Role of an Architect is to construct and application that performs - that often means a distributed system Distributed Systems can be much harder to manage than those that run on a single machine Why?

77. Because standard computing models don ’t work in a distributed world.

78. The Trials of Distributed Computing

79. As we distribute our application across multiple machines, complexity is moved from hardware to software.

80. The major problem is the lack of fast shared memory

82. We can ’t ignore ‘wire’ time. We need to make sure programmers think about it.

83. The complexity of shared memory has been moved from the hardware domain to the software domain. Simple problems like accessing other objects are now more time consuming

84. But lets step back a little and look at why we need to distribute processing

85. Sum the numbers between 1 and 10,000,000 int total for (n =1 to 10,000,000){ total+=n } A service has a hard limit on how fast it can execute this

88. Parallel execution on a grid Server Grid node Grid node Grid node Grid node Send code + data Receive result Code + data (1) Code + data (2) Code + data (3) Code + data (4) Processing time is 4 x synchronous case (assuming processing time >> wire time)

89. Grid computing solves the processing problem. i.e. we can do complex computations very quickly by doing them in parallel.

90. But it complicates the programming model

91. Example: Report Generation for (Report report : reports){ Data data = getDataFromDB(report); format(data); present(data); }

92. ... so visually... Get data DB Format Present Loop For n

93. ...but on the grid... Start DB Format Present Loop n times Grid Runner Asynchronous Synchronous Grid Callback Grid

94. Note how this muddles the design A simple loop has become a set of distributed invocations and asynchronous call backs.

95. Grids allow us to process computations quickly through parallelism. But this leads to the problem getting fast enough access to the data we want to operate on

97. Why is the database a bottleneck? Server Grid node Grid node Grid node Grid node Send code Receive result Database Get data

99. We can scale up by using memory not disk Memory access is much faster than disk access.

101. But Single Machine Data Stores Don ’t Scale, even if they are in memory Server Grid node Grid node Grid node Grid node Send code Receive result In Memory Database Get data BOTTLENECK

102. What we need is a distributed data source? Welcome to the world of distributed caching

103. Distributed Caching Solves This Problem by Splitting The Data Over All Servers 1/5 data 1/5 data 1/5 data 1/5 data 1/5 data Client Client Client Client This is parallel processing for data access. Data requests are split across multiple machines.

104. Now we have removed the data bottleneck Server Grid node Grid node Grid node Grid node (1) Send code (2) Receive result Data Fabric 1/6 1/6 1/6 1/6 1/6 1/6

105. This gives us access to a fast shared memory across multiple machines

106. We are now massively parallel With lightning fast data access.

107. But we can get faster than this. How?? Server Grid node Grid node Grid node Grid node (1) Send code (2) Receive result Data Fabric 1/6 1/6 1/6 1/6 1/6 1/6

108. Superimpose compute and data fabrics into one entity Data Fabric 1/6 1/6 1/6 1/6 1/6 1/6 Server (1) Send code (2) Receive result

110. So remember the two hats

113. The trick is balancing them! How much architecture is enough?

114. But fundamentally, you need them both!

115. Thanks Slides: http://www.BenStopford.com Vacation Placements: [email_address]