Recommendations(for(EA(Technique(Developers(

2.5.1 Research(Steps(

Figure 2.13 summarizes different research steps that can be taken to develop EA techniques that have a higher likelihood of acceptance in SMEs.

Figure 2.13: Research steps

First, both SMEs and EA have to be analyzed and relevant characteristics should be examined. From these characteristics, criteria could be extracted. This step is already done for SMEs (see the criteria for SMEs) and EA (see the criteria for EA techniques). The criteria should enable a good fit of EA with SMEs, which enhances both the actual efficiency and effectiveness.

Second, an initial metamodel can be developed, based on these criteria.

Third, during case studies in SMEs, the initial metamodel can be refined.

Fourth, the case studies will also help to develop and refine a method including step-by-step guidelines to develop an EA model of the SME. The criteria are not directly linked with the method, because it is developed from scratch during the case studies. As Moody (2003) and Rescher (1977) emphasized, the validity of a method can only be established by applicative success in practice.

Fifth, software tool support has to be developed. Tool support can help automating certain tasks, but cannot help if we do not understand the development process (Lindland et al. 1994). Tool support can have several advantages. It can facilitate the input (actual efficiency) and enhance the output (actual effectiveness). However, tool support can have disadvantages as well, especially with respect to the actual efficiency (e.g., it can be costly, there is a learning curve, users need to be able to work on a computer, ...).

Perceived ease of use refers to user friendliness of the system, the ease in learning the system, and the help features provided by the system. Therefore, we can infer that a user-friendly business architecture method and tool is

more likely to be adopted by small businesses. This user-friendliness could be operationalized as context-sensitive help or an intuitive user interface. We argue that tool support, if properly developed, can have substantial benefits for EA techniques. The metamodel and method, in combination with criteria for developing effective and efficient tool support, can be used to develop this tool support.

Sixth, this tool support enables both the validation in the case studies, as the validation by SMEs themselves that can use the tools. This validation step is crucial in getting from actual to perceived efficacy.

2.5.2 Design(Science(

Design science (Hevner et al. 2004) is a well-known methodology to develop an artifact (construct, model, method, or instantiation). The different steps of design science can be applied to the research steps for the development of EA techniques for SMEs (Figure 2.14). The development and refinement of the metamodel and method are part of the build step. The validation by the case studies is part of the evaluate step, while the tool support enables the evaluate step. The goal of design science is not the truth, but utility. Utility is found in the search for a higher perceived ease of use and usefulness of EA in SMEs. The link to existing EA approaches has to enhance the rigor of the research, while the link to and case studies in SMEs enhances the relevance of the research.

Figure 2.14: Information Systems Research Framework (from (Hevner et al. 2004))

The seven guidelines presented in (Hevner et al. 2004) can be applied to the research steps. A metamodel and method are created (guideline 1:

creation of an artifact) for SMEs (guideline 2: for a specified problem domain). The approach is evaluated in case studies (guideline 3: thorough evaluation of the artifact). No specific EA approach for SMEs exists

CHAPTER 2 78

(guideline 4: innovative, novelty). The metamodel and method have to be formalized (guideline 5: the artifact must be rigorously defined, formally represented, coherent, and internally consistent). The case studies are used to refine the metamodel and develop and refine the method (guideline 6: search process). Finally, articles have to be written about the approach, both in academic journals as in journals for practitioners. Even more important, the approach has to be implemented and tested in practice (guideline 7:

communication both to a technical and managerial audience).

2.5.3 A(Starting(Point(for(EA(for(SMEs(

Bharati and Chaudhury (2006) noticed that simpler technologies and software packages have a much wider application in SMEs than more complex ones. It could be a good idea to make an initial approach according to Einstein’s principle: “Everything should be made as simple as possible, but not simpler”. In order to keep the approach as simple as possible, while mitigating the risk of making it too simple and loosing advantages of EA, every part of the metamodel later on has to be carefully discussed with experts (e.g., SME experts, practitioners, and academics) and tested in case studies to get a balanced result. A good starting point could be to make an EA approach, based on the core elements of existing EA techniques (see the key concepts of enterprise architecture techniques), to make the approach as simple as possible, but not simpler (Figure 2.9). A strategic dimension (why), an active actor dimension (who), an operation dimension (how), and an object dimension (what) can form the highest and most important layer, the business architecture layer, of the EA model. To get a holistic overview, these four dimensions should be interrelated. An example of this proposed business architecture layer (Bernaert and Poels 2011b) is given in Figure 2.15.

Figure 2.15: An example of a starting point for the business architecture layer (from (Bernaert and Poels 2011a))

This business architecture layer has to be supported by an application layer, which has to be supported by a technology layer.

The initial metamodel should be developed according to the criteria of both SMEs and EA techniques (see the previously mentioned criteria), and more important, it should be tested extensively in real SMEs. Regardless of the potential benefits of EA approaches published, unless they are used in practice, these benefits cannot be realized.

3 ⁽