Lenguajes de Programación

Hofer (2013) focused the research on application landscape transformation. The research was motivated by the fact that even though the awareness of model necessity in reaching the organization’s business process transformation exists, there are no specialized modeling approaches for transformation. The aim of the research is to describe the characteristics of such a specialized modeling approach should hold. Organizations, together with their business processes and applications landscape are interwoven and thus, changes in one component will likely to affect the other components, or called co-evolution. Therefore, transformation process requires knowledge about components and the dependencies, how applications support business processes and how users work with applications. Such information cannot be gathered by measuring and automated analysis only. Observations, interviews and sometimes assumptions must take place. Models are therefore come in handy to record the knowledge

49 Page and make it accessible.

The research proposed six requirements that should be fulfilled by the modeling approaches that are used to support application landscape transformation. By application landscape, the research refers to the entirety of the business applications and their relationships to other elements. In addition, to make it more precise, only the applications that are used in the context with the human work will be considered. Thus, groups of applications that jointly or fully automatically carry out business processes are not taken into account. The six requirements for modeling approaches for transformation projects are:

● The modeling approach should make the available information manageable. Information on complex application landscapes is both incomplete and beyond comprehensibility. Therefore, a modeling approach should provide guideline on how to create and use models in such an environment.

● The modeling approach should be able to show contradictions. Applications are technical systems and information about them could be gathered and measured automatically. However, modeling in the context of application landscape is a social process because it involves interviews and observations about how people will use an application system. Various goals and even conflicting interests are inevitable and thus, the modeling approaches should consider contradictions.

● The modeling approach should be able to express how an application landscape supports business process. The model that shows the relations between business process and the supporting applications is needed for testing and effect analysis purpose.

● The modeling approach should be able to express an application landscape’s dependencies even for business process that use several applications and are carried out by more than one organizational unit. Since the people using the applications are used to fragmented scope which is related only to their area, information how the application landscape and business processes work together as a whole might be misunderstood and inaccurately interpreted. The division of work results in little understanding of overall process.

● The modeling approach should be able to express dependencies between applications even if they cannot be mapped into technical interfaces. The model should consider the types of dependencies that do not correspond to any technical interface (call functions, methods, network segment, and virtual machine) and can only be recognized by analyzing the business process: dependency by time and order.

● The modeling approach should be able to express how an application landscape changes over time. Since application landscapes experience series of change until the target state is reached, it is important to know how and when changes will affect the work processes.

The research also evaluated some of the existing modeling approaches with regards to the six requirements along with the ratings where (++) means fulfilled, (+) rudimentary but insufficient solution for the requirement, (=) requirement not fulfilled but approach offers means for

50 Page enhancement and (-) means not fulfilled. The Table 3 below depicts the summary.

Table 3: Result of Modeling Approaches Evaluation (Hofer, 2013)

No Requirements UML ArchiMate EAM-Patterns MEMO ADOit BEN

1 Manageable information = = + = = -

2 Contradictions + - - - = -

3 Business process support ++ + + + + -

4 Dependencies across boundaries ++ ++ + + + +

5 Non-technical dependencies = = - = = -

6 Change over time - + + = ++ +

The specific requirements for modeling approaches are needed and beneficial to improve the suitability of the approaches for transformation projects. None of the assessed modeling approaches fulfill the requirements completely. However, the research does not suggest develop a new modeling approach. The existing approaches could be complemented so that they are better suited for transformation projects.

3.4 Summary

This chapter has discussed how the roadmap plan of migration or transformation plan is supported by the EA tools. Although the research chose only three EA tools, the implication of how these tools support the roadmap plan generation could somehow represent the other existing tools. The research took two most leading EA tools in the market according to Gartner MQ 2013: ABACUS and IBM Rational System Architect. Also, BiZZdesign Architect was explored on its capability in supporting the roadmap plan generation because the research was conducted at BiZZdesign. Also, the chapter has identified some practical problems and limitations encountered by the key user in dealing with the EA tool to support the EA transformation, especially in the roadmap plan development process by using ArchiSurance case study as an example. Moreover, some challenges with regards to the guidelines provided by the EA framework have been identified.

Some initiatives or researches proposing the performance improvement of the EA tools in supporting the roadmap plan analysis and visualization are discussed. The above researches agreed on the importance of analysis and visualization of roadmap plan. Therefore, the support provided by the EA tools becomes necessary and needs special attention. The roadmap plan improvement could be initiated from different perspectives ranging from the timeline visualization of roadmap plan, interactive (and automated) roadmap plan generation upto basic requirements needed for the EA tools to accomplish. Together with the key findings from Chapter 2, the information gathered in this chapter will be used to design the proposed solution in improving the capability roadmap plan of the EA tool.

51 Page

4 Addressing the Selected Problems/Limitations

After several problems and/or limitations, which are categorized as practicality- and guideline- related problems, have been identified in previous chapter, this chapter discusses the proposed artifacts of this research to address the problems. This chapter addresses research question 3 about how the development of roadmap plan could be improved in ArchiMate and Architect. The chapter is organized as follows. Section 4.1 briefly explains which of the problems have been selected to be further elaborated and addressed. Section 4.2 introduces the first artifact, which deals with the first problem: the aggregating a relation problem. Section 4.3 introduces the second artifact, in the form of step by step framework, which deals with the second problem: consolidate gaps, solutions and dependencies matrix. Finally, section 4.4 summarizes the chapter.