## 7 Summary and Outlook  
We have seen how the pattern catalog may guide application developers during the creation of application components. The patterns implemented by individual application components also guided the application managers during the identification of management patterns that he could use to manage the application component. We have defined such abstract management flows in a pattern format to handle elasticity, resiliency, and for moving application components between different environments or updating them to a new version. Using the proposed pattern catalog and annotated implementation artifacts, we have further shown how these abstract management flows could be refined for different components of an exemplary web shop application. Future use of patterns in architecture diagrams will have to be further refined to handle a larger catalog of patterns and have to be integrated into architecture modeling tools. An extension of architecture modeling languages, such xADL [60], could be one solution. The general challenge that needs to be addressed is the creation of a composition language to connect the icons of architectural patterns in a structured and well-defined manner. To extend tool support, patterns should further be associated with properties of the application that they enable, for example, high-availability, privacy, _etc._ With an increasing size of the catalog, such annotations provide an easier accessibility of the patterns.  
A limitation of the presented approach is that the management flows currently consider isolated application components. While such isolated management of application components can be helpful during the runtime management of the application, considering the complete application would be even more powerful. For example, based on the architectural diagram of the example Web shop application seen in Figure 18 of Section 6 management tasks may be automated for the overall application as well. Conceptually, this would result in a management flow that executes the individual management flows of application components in a particular order. This order can likely be determined automatically by a graph-analysis of the dependencies expressed in  
middleware and hardware to compute the order of provisioning tasks. To incorporate the links of architecture diagrams, these models and corresponding algorithms need to be extended respectively.  
Another limitation is that individual components are refined to use separate middleware and hardware stacks, thus, each application component is individually combined with cloud offerings by the application developer. However, in practice, application components often share middleware and hardware due to performance and licensing issues. In [61], we proposed a method, how application architecture diagrams can be used to optimize the assignment of application components to different middleware installations, virtual machines, and clouds. The above mentioned management flows considering the complete application, therefore, have to respect the impact of shared middleware, hardware, and cloud offerings as well. The challenge to merge redundant middleware and hardware also arises if outsourced IT resources are moved back into a company or two companies merge. Therefore, approaches targeting these challenges may be applicable in the domain of pattern-based development and management of cloud applications. Recently, [62] started to capture these concepts.