Skip to main content

Advertisement

SpringerLink
Log in

CHOOSE: Towards a metamodel for enterprise architecture in small and medium-sized enterprises

  • Published:
Information Systems Frontiers Aims and scope Submit manuscript

Abstract

Enterprise architecture (EA) is a coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and IT infrastructure. Recent research indicates the need for EA in small and medium-sized enterprises (SMEs), important drivers of the economy, as they struggle with problems related to a lack of structure and overview of their business. However, existing EA frameworks are perceived as too complex and, to date, none of the EA approaches are sufficiently adapted to the SME context. Therefore, this paper presents the CHOOSE metamodel for EA in SMEs that was developed and evaluated through action research in an SME and further refined and validated through case study research in five other SMEs. This metamodel is based on the essential dimensions of EA frameworks and is kept simple so that it may be applied in an SME context. The final CHOOSE metamodel includes only four essential concepts (i.e. goal, actor, operation, object), one for each most frequently used EA focus. As an example, an extract is included from the specific model that was created for the SME used in our action research. Finally, the CHOOSE metamodel is evaluated according to the dimensions essential in EA and the requirements for EA in an SME context.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10

Similar content being viewed by others

References

  • Aarabi, M., Saman, M. Z. M., Wong, K. Y., Beheshti, H. M., & Hemdi, A. R. (2011). The effect of enterprise architecture for enterprise resource planning in small and medium enterprises: A review and research direction. In IESS, Indonesia (pp. 159–163).

  • Andersson, B., Johannesson, P., & Zdravkovic, J. (2009). Aligning goals and services through goal and business modelling. Information System and e-Business Management, 7(2), 143–169.

    Article  Google Scholar 

  • Anton, A. I. (1996). Goal-based requirements analysis. In ICRE (pp. 136–144).

  • Anton, A. I., McCracken, W. M., & Potts, C. (1994). Goal decomposition and scenario analysis in business process reengineering. In CAiSE (Vol. 811, pp. 94–104, LNCS). Utrecht: Springer.

  • Balabko, P., & Wegmann, A. (2006). Systemic classification of concern-based design methods in the context of enterprise architecture. Information Systems Frontiers, 8(2), 115–131.

    Article  Google Scholar 

  • Baskerville, R., & Myers, M. D. (2004). Special issue on action research in information systems: making IS research relevant to practice: foreword. MIS Quarterly, 28(3), 329–335.

    Google Scholar 

  • Bernaert, M., & Poels, G. (2011). The quest for know-how, know-why, know-what and know-who: Using KAOS for enterprise modelling. In CAiSE international workshops (Vol. 83, pp. 29–40, LNBIP): Heidelberg: Springer.

  • Bernaert, M., Maes, J., & Poels, G. (2013a). An android tablet tool for enterprise architecture modeling in small and medium-sized enterprises. In The practice of enterprise modeling (pp. 145–160). Heidelberg: Springer.

    Chapter  Google Scholar 

  • Bernaert, M., Poels, G., Snoeck, M., & De Backer, M. (2013b). Enterprise architecture for small and medium-sized enterprises: A starting point for bringing EA to SMEs, based on adoption models. In Information systems and small and medium-sized enterprises (SMEs): State of art of IS research in SMEs. Berlin: Springer.

    Google Scholar 

  • Bhagwat, R., & Sharma, M. K. (2007). Information system architecture: a framework for a cluster of small- and medium-sized enterprises (SMEs). Production Planning and Control, 18(4), 283–296.

    Article  Google Scholar 

  • Bidan, M., Rowe, F., & Truex, D. (2012). An empirical study of IS architectures in French SMEs: integration approaches. European Journal of Information Systems, 21(3), 287–302.

    Article  Google Scholar 

  • Bittler, R. S., & Kreizmann, G. (2005). Gartner enterprise architecture process. Evolution, 21.

  • Boman, M., Bubenko, J. A., Johannesson, P., & Wangler, B. (1997). Conceptual modelling. London: Prentice-Hall, Inc.

    Google Scholar 

  • Boone, S., Bernaert, M., Roelens, B., Mertens, S., & Poels, G. (2014). Evaluating and improving the visualisation of CHOOSE, an enterprise architecture approach for SMEs. In The practice of enterprise modeling (Vol. 197, pp. 87–102, LNBIP). Berlin: Springer.

  • Braun, C., & Winter, R. (2005). A comprehensive enterprise architecture metamodel and its implementation using a metamodeling platform. In EMISA (pp. 64–79).

  • Bubenko, J. (1993). Extending the scope of information modelling. In DAISD (pp. 73–97).

  • Business Transformation Agency. (2009). Vocabulary-Driven Enterprise Architecture Development: Guidelines for DoDAF AV-2: Design and Development of the Integrated Dictionary.

  • Businska, L., Kirikova, M., Penicina, L., Buksa, I., & Rudzajs, P. (2012). Enterprise modeling for respecting regulations. In PoEM (pp. 106–117).

  • Clark, T., Barn, B. S., & Oussena, S. (2011). LEAP: A precise lightweight framework for enterprise architecture. In ISEC (pp. 85–94). ACM.

  • Daneva, M., & van Eck, P. (2007). What enterprise architecture and enterprise systems usage can and can not tell about each other. International Journal of Computer Science and Applications, 4, 93–109.

    Google Scholar 

  • Dardenne, A., Fickas, S., & van Lamsweerde, A. (1991). Goal-directed concept acquisition in requirements elicitation. In IWSSD (pp. 14–21). Los Alamitos: IEEE.

    Google Scholar 

  • Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directed requirements acquisition. Science of Computer Programming, 20(1–2), 3–50.

    Article  Google Scholar 

  • Database Systems Group. (2013). USE: A UML based Specification Environment. http://sourceforge.net/projects/useocl/.

  • Denzin, N. K. (2006). Sociological methods: A sourcebook. Transaction Publishers: Piscataway.

    Google Scholar 

  • Devos, J. (2011). IT governance for SMEs. Ghent: University of Ghent.

    Google Scholar 

  • DoD. (2010). DoDAF Architecture Framework Version 2.2. http://dodcio.defense.gov/dodaf20.aspx.

  • Dumeez, J., Bernaert, M., & Poels, G. (2013). Development of software tool support for enterprise architecture in small and medium-sized enterprises. In CAiSE international workshops (LNBIP). Springer.

  • Engelsman, W., & Wieringa, R. (2012). Goal-oriented requirements engineering and enterprise architecture: Two case studies and some lessons learned. In REFSQ (Vol. 7195, pp. 306–320, LNCS). Heidelberg: Springer.

  • Engelsman, W., Quartel, D., Jonkers, H., & van Sinderen, M. (2011). Extending enterprise architecture modelling with business goals and requirements. Enterprise Information Systems, 5(1), 9–36.

    Article  Google Scholar 

  • Erickson, J., & Siau, K. (2007 ). Can UML be simplified? Practitioner use of UML in separate domains. In EMMSAD (pp. 89–98). Citeseer.

  • Eriksson, H.-E., & Penker, M. (2000). Business modeling with UML: Business patterns at work. New York: Wiley.

    Google Scholar 

  • Ernst, A. M., Lankes, J., Schweda, C. M., & Wittenburg, A. (2006). Tool support for enterprise architecture management—Strengths and weaknesses. In EDOC (pp. 13–22)

  • European Commission. (2011). Are EU SMEs recovering from the crisis? Annual Report on EU Small and Medium sized Enterprises 2010/2011.

  • French, W. L., & Bell, C. H. (1973). Organization development: Behavioral science interventions for organization improvement. Englewood Cliffs: Prentice-Hall.

    Google Scholar 

  • Gartner (2012). Gartner’s 2011 Global Enterprise Architecture Survey: EA Frameworks Are Still Homemade and Hybrid.

  • Georgiadis, G. (2015). Development of an ontology and risk-led method for selecting and tailoring Enterprise Architecture Frameworks. In W. Paper (Ed.), Working Paper, Ghent University.

  • Glissman, S., & Sanz, J. (2009). A comparative review of business architecture. San Jose: IBM.

    Google Scholar 

  • Gogolla, M., Büttner, F., & Richters, M. (2007). USE: a UML-based specification environment for validating UML and OCL. Science of Computer Programming, 69(1–3), 27–34.

    Article  Google Scholar 

  • Hannon, P. D., & Atherton, A. (1998). Small firm success and the art of orienteering: the value of plans, planning, and strategic awareness in the competitive small firm. Journal of Small Business and Enterprise Development, 5(2), 102–119.

    Article  Google Scholar 

  • Hegge, H. M. H., & Wortmann, J. C. (1991). Generic bill-of-material: a new product model. International Journal of Production Economics, 23(1–3), 117–128.

    Article  Google Scholar 

  • Henderson, J. C., & Venkatraman, N. (1993). Strategic alignment: leveraging information technology for transforming organizations. IBM Systems Journal, 32(1), 4–16.

    Article  Google Scholar 

  • Henderson-Sellers, B., Low, G., & Gonzalez-Perez, C. (2012). Semiotic considerations for the design of an agent-oriented modelling language. In EMMSAD (Vol. 113, pp. 422–434). Springer LNBIP.

  • Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1), 75–105.

    Google Scholar 

  • Heyse, M., Bernaert, M., & Poels, G. (2012). Keuzes Maken binnen Processen: Het Vermijden van een Russische Roulette voor de Organisaties. Ghent: University of Ghent.

    Google Scholar 

  • Hoogervorst, J. (2004). Enterprise architecture: enabling integration, agility and change. International Journal of Cooperative Information Systems, 13(3), 213–233.

    Article  Google Scholar 

  • IEEE Computer Society. (2000). IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Std 1471–2000.

  • IFEAD. (2005). Trends in Enterprise Architecture 2005: How are Organizations Progressing?

  • IFEAD. (2006). Extended Enterprise Architecture Framework Essentials Guide.

  • Ingelbeen, D., Bernaert, M., & Poels, G. (2013). Enterprise architecture software tool support for small and medium-sized enterprises: EASE. In AMCIS.

  • ISACA. (2012). COBIT 5. http://www.isaca.org/COBIT/Pages/COBIT-5-Framework-product-page.aspx.

  • Jacobs, D., Kotzé, P., van der Merwe, A., & Gerber, A. (2011). Enterprise architecture for small and medium enterprise growth. In EEWC (Vol. 79, pp. 61–75, LNBIP). Heidelberg: Springer.

  • James, G. A., Handler, R. A., Lapkin, A., & Gall, N. (2005). Gartner Enterprise Architecture Framework. Evolution.

  • Järvinen, P. (2007). Action research is similar to design science. Quality & Quantity, 41(1), 37–54.

    Article  Google Scholar 

  • Jonkers, H., Lankhorst, M. M., ter Doest, H. W. L., Arbab, F., Bosma, H., & Wieringa, R. J. (2006). Enterprise architecture: management tool and blueprint for the organisation. Information Systems Frontiers, 8(2), 63–66.

    Article  Google Scholar 

  • Kerzner, H. R. (2013). Project management: A systems approach to planning, scheduling, and controlling (Vol. 11). Hoboken: Wiley.

    Google Scholar 

  • Kroon, B., Voorde, K., & Timmers, J. (2012). High performance work practices in small firms: a resource-poverty and strategic decision-making perspective. Small Business Economics, 1, 1–21.

    Google Scholar 

  • Lankhorst, M. (2013). Enterprise architecture at work: Modelling, communication and analysis (Vol. 3). New York: Springer.

    Book  Google Scholar 

  • Leist, S., & Zellner, G. (2006). Evaluation of current architecture frameworks. In SAC (pp. 1546–1553). New York: ACM.

    Google Scholar 

  • Letier, E., & van Lamsweerde, A. (2002). Deriving operational software specifications from system goals. In SIGSOFT (pp. 119–128). New York: ACM.

    Google Scholar 

  • Letier, E., & van Lamsweerde, A. (2004). Reasoning about partial goal satisfaction for requirements and design engineering. In SIGSOFT (pp. 53–62). Newport Beach: ACM.

    Google Scholar 

  • Lindström, A., Johnson, P., Johansson, E., Ekstedt, M., & Simonsson, M. (2006). A survey on CIO concerns-do enterprise architecture frameworks support them? Information Systems Frontiers, 8(2), 81–90.

    Article  Google Scholar 

  • Loucopoulos, P., & Kavakli, E. (1995). Enterprise modelling and the teleological approach to requirements engineering. International Journal of Cooperative Information Systems, 4(1), 45–79.

    Article  Google Scholar 

  • Luftman, J., & Ben-Zvi, T. (2011). Key issues for IT executives 2011: cautious optimism in uncertain economic times. MIS Quarterly Executive, 10(4), 203–212.

    Google Scholar 

  • Lybaert, N. (1998). The information use in a SME: its importance and some elements of influence. Small Business Economics, 10(2), 171–191.

    Article  Google Scholar 

  • Moody, D. L. (2003). The method evaluation model: A theoretical model for validating information systems design methods. In ECIS.

  • Moody, D. (2009). The physics of notations: toward a scientific basis for constructing visual notations in software engineering. IEEE Transactions on Software Engineering, 35(6), 756–779.

    Article  Google Scholar 

  • Mostow, J. (1985). Towards better models of the design process. AI Magazine, 6(1), 44–57.

    Google Scholar 

  • Mylopoulos, J., Chung, L., & Nixon, B. (1992). Representing and using nonfunctional requirements: a process-oriented approach. IEEE Transactions on Software Engineering, 18(6), 483–497.

    Article  Google Scholar 

  • OMG. (2008). Semantics of Business Vocabulary and Business Rules (SBVR) (v1.0). http://www.omg.org/spec/SBVR/1.0/.

  • OMG. (2009). Organization Structure Metamodel (OSM). http://www.omg.org/cgi-bin/doc?bmi/09-08-02.

  • OMG. (2010). Business Motivation Model (BMM) (v1.1). http://www.omg.org/spec/BMM/1.1/.

  • OMG. (2011a). Business Process Model and Notation (BPMN) (v2.0). http://www.omg.org/spec/BPMN/2.0/.

  • OMG. (2011b). OMG Unified Modeling Language (OMG UML), Infrastructure (v2.4.1). http://www.omg.org/spec/UML/2.4.1/.

  • OMG. (2011c). OMG Unified Modeling Language (OMG UML), Superstructure (v2.4.1). http://www.omg.org/spec/UML/2.4.1/.

  • OMG. (2012a). OMG Object Constraint Language (OCL) (v2.3.1). http://www.omg.org/spec/OCL/2.3.1/.

  • OMG. (2012b). OMG’s MetaObject Facility. http://www.omg.org/mof/.

  • OMG. (2013). MDA—The Architecture Of Choice For A Changing World. http://www.omg.org/mda/.

  • O’Regan, N., & Ghobadian, A. (2004). The importance of capabilities for strategic direction and performance. Management Decisions, 42(2), 292–313.

    Article  Google Scholar 

  • Paige, R. F., Brooke, P. J., & Ostroff, J. S. (2007). Metamodel-based model conformance and multiview consistency checking. ACM Transactions on Software Engineering and Methodology, 16(3).

  • Project Management Institute. (2013). Project Management Body of Knowlegde (PMBOK). http://www.pmi.org/PMBOK-Guide-and-Standards.aspx.

  • Radeke, F. (2011). Toward understanding enterprise architecture management’s role in strategic change: Antecedents, processes, outcomes. In WI (Vol. 2011).

  • Rescher, N. (1977). Methodological pragmatism: Systems-theoretic approach to the theory of knowledge. Oxford: Blackwell Publishers.

    Google Scholar 

  • Respect-IT. (2007). A KAOS Tutorial. http://www.respect-it.be/.

  • Roose, D., Vansteenlandt, J., Bernaert, M., & Poels, G. (2013). Development of a common base for enterprise architecture: Building the bridge between CHOOSE and ArchiMate. Ghent: University of Ghent.

    Google Scholar 

  • Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Boston: Harvard Business Review Press.

    Google Scholar 

  • Rossi, M., & Brinkkemper, S. (1996). Complexity metrics for systems development methods and techniques. Information Systems, 21(2), 209–227.

    Article  Google Scholar 

  • Sandkuhl, K., Stirna, J., Persson, A., & Wißotzki, M. (2014). Enterprise modeling: Tackling business challenges with the 4EM method. Berlin: Springer.

    Book  Google Scholar 

  • Scheer, A.-W. (2000). ARIS—Business process modeling (Vol. 3). Berlin: Springer.

    Book  Google Scholar 

  • Schekkerman, J. (2006). How to survive in the jungle of enterprise architecture frameworks: Creating or choosing an enterprise architecture framework. Victoria: Trafford Publishing.

    Google Scholar 

  • Sessions, R. (2007). Comparison of the top four enterprise architecture methodologies. Microsoft.

  • Small Business Administration. (2011). How Important are Small Businesses to the U.S. Economy? http://www.sba.gov/advo.

  • Smith, J. A. (1998). Strategies for start-ups. Long Range Planning, 31(6), 857–872.

    Article  Google Scholar 

  • Snoeck, M., Dedene, G., Verhelst, M., & Depuydt, A.-M. (1999). Object-oriented enterprise modelling with MERODE. Leuven: Leuven University Press.

    Google Scholar 

  • Stirna, J., & Persson, A. (2007). Ten years plus with EKD: Reflections from using an enterprise modeling method in practice. In EMMSAD (pp. 99–108).

  • Susman, G. I., & Evered, R. D. (1978). An assessment of the scientific merits of action research. Administrative Science Quarterly, 23(4), 582–603.

    Article  Google Scholar 

  • Tamm, T., Seddon, P. B., Shanks, G., & Reynolds, P. (2011). How does enterprise architecture add value to organisations? CAIS, 28(1)

  • The Open Group. (2009). TOGAF Version 9. http://www.opengroup.org/togaf.

  • The Open Group. (2012). ArchiMate 2.0. http://www3.opengroup.org/subjectareas/enterprise/archimate.

  • The White House OMB. (2012). The Common Approach To Federal Enterprise Architecture.

  • The White House OMB. (2013). Federal Enterprise Architecture. http://www.whitehouse.gov/omb/e-gov/FEA.

  • Urbaczewski, L., & Mrdalj, S. (2006). A comparison of enterprise architecture frameworks. Issues in Information Systems, 7(2), 18–23.

    Google Scholar 

  • Van Lamsweerde, A. (2009). Requirements engineering: From system goals to UML models to software specifications (Vol. 3). New York: Wiley.

    Google Scholar 

  • van Lamsweerde, A., Dardenne, A., Delcourt, B., & Dubisy, F. (1991). The KAOS project: Knowledge acquisition in automated specification of software. In AAAI Spring Symposium Series, Stanford University (pp. 59–62).

  • van Lamsweerde, A., Darimont, R., & Massonet, P. (1995). Goal-directed elaboration of requirements for a meeting scheduler: Problems and lessons learnt. In RE (pp. 194–203). IEEE.

  • van Lamsweerde, A., Darimont, R., & Letier, E. (2002). Managing conflicts in goal-driven requirements engineering. IEEE Transactions on Software Engineering, 24(11), 908–926.

    Article  Google Scholar 

  • van’t Wout, J., Waage, M., Hartman, H., Stahlecker, M., & Hofman, A. (2010). The integrated architecture framework explained: Why, what, how. Berlin: Springer.

    Book  Google Scholar 

  • Veasey, P. W. (2001). Use of enterprise architectures in managing strategic change. Business Process Management Journal, 7(5), 420–436.

    Article  Google Scholar 

  • Wagter, R., van den Berg, M., Luijpers, J., & van Steenbergen, M. (2005). Dynamic enterprise architecture: How to make it work. New York: Wiley.

    Google Scholar 

  • Warmer, J., & Kleppe, A. (2003). The object constraint language: Getting your models ready for MDA (Vol. 2). Addison-Wesley Professional.

  • Wegmann, A., Regev, G., Rychkova, I., Lê, L.-S., de la Cruz, J. D., & Julia, P. (2007). Business and IT alignment with SEAM for enterprise architecture. In EDOC.

  • Weske, M. (2012). Business process management: Concepts, languages, architectures (Vol. 2). Berlin: Springer.

    Book  Google Scholar 

  • Winter, R., & Fischer, R. (2007). Essential layers, artifacts, and dependencies of enterprise architecture. Journal of Enterprise Architecture, 3(2), 7–18.

    Google Scholar 

  • Wißotzki, M., & Sonnenberger, A. (2012). Enterprise architecture management—State of research analysis & a comparison of selected approaches. In PoEM (pp. 37).

  • Yu, E. S. K. (1993). Modelling organizations for information systems requirements engineering. In RE (pp. 34–41). IEEE.

  • Zach, O. (2012). ERP system implementation in small and medium-sized enterprises. Agder: University of Agder.

    Google Scholar 

  • Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276–292.

    Article  Google Scholar 

  • Zachman International. (2011). Zachman Version 3.0. http://www.zachman.com.

Download references

Author information

Authors and Affiliations

  1. Department of Business Informatics and Operations Management, Ghent University, Tweekerkenstraat 2, 9000, Ghent, Belgium

    Maxime Bernaert, Geert Poels & Manu De Backer

  2. Master of ICT Enterprise Architecture, inno.com Institute, Heiststeenweg 131, 2580, Beerzel, Belgium

    Maxime Bernaert

  3. Department of Decision Sciences and Information Management, K.U. Leuven, Naamsestraat 69, 3000, Leuven, Belgium

    Monique Snoeck

  4. Department of Management Information Systems, University of Antwerp, Prinsstraat 13, 2000, Antwerp, Belgium

    Manu De Backer

Authors
  1. Maxime Bernaert
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Geert Poels
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Monique Snoeck
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Manu De Backer
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Maxime Bernaert.

Appendices

Appendix 1: KAOS metamodel

Each viewpoint is discussed separately and then the integrated KAOS metamodel is presented in Fig. 11. Concepts from the goal, agent, operation, object, and behaviour viewpoints will be respectively coloured in yellow, red, purple, green, and grey. Attributes between square brackets are optional attributes.

1.1 KAOS goal viewpoint

The central element of the KAOS goal viewpoint is a Goal. A Goal is a prescriptive statement of intent that the system should satisfy through the cooperation of its Agents. The formulation is declarative, unlike Operational procedures to implement it. A Goal can be of a specific type (SoftGoal or BehaviourGoal (Achieve or Maintain/Avoid)) and of a specific [Category] (functional or non-functional).

Goal Refinement is enabled by refining higher-level Goals in zero or more Refinements (OR-Ref) that group (AND-Ref) one or more lower-level Goals. An AND-Ref (OR-Ref) means that the parent Goal can be satisfied/satisficed by satisfying/satisficing all (one or more) child Goals in the Refinement. A LeafGoal is a Goal that can be under the Responsibility of exactly one Agent and is a Requirement or Expectation, depending on the type of Agent that has a Responsibility relationship with it (respectively SoftwareToBeAgent and EnvironmentAgent).

Domain properties (DomInvar) or hypotheses (DomHyp) are descriptive statements (DomDescript) holding regardless of how system Agents behave. Domain properties typically correspond to physical laws that cannot be broken.

Goals can be ObstructedBy Obstacles or can be a Resolution for Obstacles. Obstacles can be refined by O-Refinements in the same way as Goals can be refined by Refinements. Conflict links may interconnect Goal nodes to capture potential Conflicts among them. They are not explicitly represented in the metamodel, but are captured in the Divergence relation, which captures a potential Conflict, where some statements become logically inconsistent if a BoundaryCondition becomes true.

1.2 KAOS agent viewpoint

The central element of the KAOS agent viewpoint is an Agent. Agents are active system Objects that are responsible for the LeafGoals in a goal model. An Agent is responsible for a Goal by a Responsibility relationship if restricting its individual behaviour by adequate control of system items is sufficient for ensuring Goal satisfaction/satisficing.

From an operational standpoint, an Agent can be defined as a processor that performs (Performance) Operations under restricted conditions to satisfy the Goals for which it is responsible (Responsibility). For an Agent to be assigned (Assignment) to a Goal, the Goal must be realizable by the Agent in view of its capabilities. Agent capabilities are defined in terms of Object Attributes and Associations that the Agent can Monitor or Control. Monitor means that an Agent can get the values of the Attribute or can evaluate whether the Association holds, while Control means that an Agent can set values for this Attribute or can create or delete an Association.

An Agent can be decomposed into finer-grained ones with finer-grained Responsibilities through the recursive Aggregation relationship. An Agent may be related to other Agents through Dependency links. A depender depends on a dependee for a Goal, if a dependee’s failure to get this Goal satisfied/satisficed can result in a depender’s failure to get one of its Assigned Goals satisfied/satisficed.

An agent model defines the boundary between the software-to-be and its environment, as an Agent can be a SoftwareToBeAgent or an EnvironmentAgent. An Agent can be of a different [Category], while this is not explicitly visible in the metamodel: NewSoftwareAgents to be developed, ExistingSoftwareAgents with which the software-to-be will have to interoperate, Devices, and HumanAgents playing specific Roles.

The Wish meta-relationship is not shown in the metamodel. It links Goal and HumanAgent and captures the fact that this HumanAgent would like the Goal to be satisfied/satisficed.

1.3 KAOS operation viewpoint

The operation viewpoint captures the functional services that the target system should provide in order to meet its Goals. An Operation is a binary relation over system States. Is has a tuple of Input variables and a tuple of Output variables defining its signature. An Input variable designates an Object instance to which the Operation applies. The State of this instance affects the application of the Operation. An Output variable designates an Object instance on which the Operation acts. The State of this instance is changed by the application of the Operation. An Input variable can be an Output variable for the same Operation. A particular application of the Operation yields a State Transition from a State in InputState to a State in OutputState.

An Agent performs (Performance) an Operation if the applications of this Operation are activated by instances of the Agent. Every Operation is Performed by exactly one Agent. Operationalization refers to the process of mapping LeafGoals, under the Responsibility of single Agents, to Operations ensuring them. Each such Operation is performed (Performance) by the responsible (Responsibility) Agent under restricted conditions for satisfaction/satisficing of its Goals. While a single Operation may operationalize (Operationalization) multiple Goals, a single Goal will in general be operationalized (Operationalization) by multiple Operations.

It is important to notice the difference between a Goal and an Operation. A Goal is an intentional specification: it leaves the Operations realizing it implicit, whereas an Operation is an operational specification: it leaves the intentions underlying it implicit. A Goal has a higher stability than an Operation (van Lamsweerde et al. 1995). A Goal captures an objective that the system should satisfy and is specified declaratively. An Operation captures a functional service that the system should provide to satisfy such an objective and maybe others and is specified by conditions characterizing its applicability and effect. Semantically speaking, a BehaviouralGoal constrains entire sequences of system State Transitions, while an Operation constrains single State Transitions within such sequences.

In KAOS, Operations are atomic and cannot be decomposed into finer-grained ones. Goal Refinements will be favoured, from which fine-grained Operations are derived, over Goal-free Operation refinement in an operational model (Letier and van Lamsweerde 2002).

1.4 KAOS object viewpoint

The object viewpoint provides a structural view of the system and is represented by entity-relationship diagrams using the UML class diagram notation. Entities and the structural features of Events and Agents will be represented as Operation-free UML classes and Associations will be represented as UML associations. The object model gathers all concept definitions and domain properties used in the goal, agent, operation, and behaviour models and introduces a common vocabulary to refer to. The object model can later on provide a basis for generating a database schema and for elaborating a software architecture.

A conceptual Object is a discrete set of instances of a domain-specific concept that are manipulated by the modelled system. These instances are distinctly identifiable, can be enumerated in any system State, share similar features, and may differ from each other in their individual States and State Transitions. The set of instances that are members of an Object will thus generally change over time. The semantic InstanceOf relation is kept implicit in the metamodel. This built-in semantic relation allows determining which individuals are instances of the Object in the current State.

An Object can be an Association, an Entity, an Event, or an Agent. An Entity is an autonomous and passive Object. An Association is a passive Object dependent on other Objects that it Links and it is also used under the synonymous term relationship. Each Linked Object plays a specific Role in the Association. An Event is an instantaneous Object. An Agent is as already mentioned an autonomous and active Object. It is important to notice that an Agent is a subtype of an Object and inherits the relationships of an Object (Dardenne et al. 1993). An Association can Link two or more Objects, can be reflexive, can have different Multiplicities and can be a Specialization, an Aggregation, or an ApplicationSpecific type. An Association can have a Name, so a user can define different Associations with different Names. Concern links connect Goal nodes to the Objects to which they refer.

An Attribute is an intrinsic feature of an Object regardless of other Objects in the model. It has a Name and a Range of values.

1.5 KAOS behaviour viewpoint

The behaviour viewpoint completes the static representation of system functionalities by capturing the required system dynamics. An operation model focuses on classes of Input–output State Transitions, an object model declares and structures the variables undergoing State Transitions, and an agent model indicates which variable is controlled by which Agent.

Since this behaviour viewpoint will not be included in the CHOOSE metamodel, it is not further explained.

1.6 Integrated KAOS metamodel and adaptation to the CHOOSE metamodel

The viewpoints (excluding the behaviour viewpoint) can be combined to form the integrated KAOS metamodel (Fig. 11). The core element is each time represented in the corresponding colour. In Fig. 12, the green parts of the KAOS metamodel are the ones that were retained in the CHOOSE metamodel. Figure 13 depicts how these elements were either used as such (green) or adapted (orange), or where new elements were added (purple) to form the CHOOSE metamodel.

Fig. 11
figure 11

KAOS integrated metamodel

Full size image
Fig. 12
figure 12

KAOS elements being retained in CHOOSE

Full size image
Fig. 13
figure 13

Adjusting and adding elements from KAOS to CHOOSE

Full size image

Appendix 2: OCL constraints

The complete CHOOSE metamodel’s classes and associations were input in the USE tool (Fig. 14). Next, constraints were added and tested by instantiating the metamodel in the tool. In Table 3 the metamodel including constraints is presented as a text file serving as an input for the USE tool. The objectified relationships Association, Aggregation, and Specialization are defined as normal relationships and the association class of Link and Performance is not shown. Due to tool limits, both aggregation and specialization relationships are modelled as normal associations. If interested, this text file can be used directly as an input for the USE tool following the guidelines on (Database Systems Group 2013) to test the metamodel and OCL constraints.

Fig. 14
figure 14

CHOOSE metamodel in USE tool

Full size image
Table 3 CHOOSE metamodel and constraints as input for the USE tool
Full size table

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Bernaert, M., Poels, G., Snoeck, M. et al. CHOOSE: Towards a metamodel for enterprise architecture in small and medium-sized enterprises. Inf Syst Front 18, 781–818 (2016). https://doi.org/10.1007/s10796-015-9559-0

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10796-015-9559-0

Keywords

Search

Navigation