The Strategy is a term that originates out of the Greek language stratēgia, (στρατηγία), where the meaning is centred on the military concept “art of troop leader; office of general, command, generalship” (Liddell, Scott, 1940). The expression ‘strategy’ came into use, in the 6th century AD (Islamic Hijri calendar -50) in the east roman area. It first entered the western world in the 18th century. At that time and until the 20th century, the word “strategy” contrariwise was about “a comprehensive way to try to pursue political ends, including the threat or actual use of force, in a dialectic of wills”. This was however more related to battle struggle, in which both opponents interact (Freedman, 2013).

Today, within the Defense industry it refers to planning directional components and manoeuvring the resources, even before the enemy is actually engaged. Once the enemy is engaged it is all about strategy execution, therefore once the enemy has been engaged, attention shifts to tactics. However, to ensure the continuous improvement of strategy it is the activities undertaken at the operational level that enable this to happen. Knowing the centuries-old military origins of strategy allows us to connect some of the commonly business terms today, for example:

• Strategy refers to basic directional decisions, i.e. purpose and mission.
• Strategy consists of the important actions necessary to realise these directions.
• Strategy is also or has planning components
• Strategy is positioning; that is, it reflects on decisions needed to be a specific position in particular markets.
• Strategy is perspective, that is, vision and direction.
• Strategy is a “how,” a means of getting from here to there. Therefore, strategy should answer the question: What should the resources be doing?
• Strategy should also address: What are the ends we seek and how should we achieve them?

Henry Mintzberg already in his 1994 book, The Rise and Fall of Strategic Planning (Mintzberg, 1994), points out that people use “strategy” in several different ways. For example, strategic planning isn’t strategic thinking. One is analysis, and the other is synthesis (Mintzberg, 1994). In a 1996 Harvard Business Review article (Porter, 1996) and in an earlier book (Porter, 1996), Porter argues that competitive strategy is “about being different.” He adds, “It means deliberately choosing a different set of activities to deliver a unique mix of value.” In short, Porter argues to embrace strategy as both plan and position. Others such as Benjamin Tregoe and John Zimmerman (Tregoe, Zimmerman, 1980), define strategy as “the framework which guides those choices that determine the nature and direction of an organisation.”

While Freedman debates that a strategy should describe how the ends (goals) will be achieved by the means (resources) (Freedman, 2015). Simandan, argues that strategy generally involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions (Simandan, 2018). Of course, there are many more definitions and descriptions that add to the confusion on what strategy is and what it isn’t. While different writers argue that strategy is the one thing and the other argue that it is the other, we believe it encompasses most discussed. In other words, strategy consists of: viewpoint, standpoint, direction, position, plan, pattern/concepts by which the ends will be attained. In a business context, we therefore use the strategy definition used by the enterprise standard body LEADing Practice in their Strategy Reference Content (LEAD-ES10001PG). They define strategy the following way: “Strategy is the direction, the plan and ends to which the enterprise seeks to position itself, as well as the means and methods by which the ends will be attained”.

It is vital to understand strategy and the nature of how it is applied within the organisation. Why? Because it is having different contexts and scope depending on the organisation. For example, we can think about the corporate enterprise strategy and where it is applied. This is where different strategies might play a special role in the evolution or transformation of the organisation, its areas/units or its operation. However, we could also think of a specific organisational area/unit strategy or the operational strategy (von Rosing, et al, 2017). We can therefore conclude, inside an organisation, strategies can exist on three main levels:

1. Strategic Level: Enterprise-level Strategy is concerned with the overall scope of an organisation and how value is added to the constituent organisation from the organisational whole. Enterprise-level strategy matters include geographical scope, diversity of products and services, acquisitions of new businesses, and how resources are allocated between the different elements of the organisation (von Rosing, Laurier, 2015). Being clear about Enterprise-level strategy is important; determining the range of businesses to include is the basis of other strategic decisions, such as acquisitions and alliances.
2. Tactical Level: Group-level Strategies is about how the individual organisational groups should compete in their particular markets (for this reason group-level strategy is often called “competitive strategy”). These individual organisational groups might be standalone businesses, for instance entrepreneurial start-ups, or organisational units within a larger corporation. In the public sector, the equivalent of group-level strategy is decisions about how units (such as individual hospitals or schools) should provide best-value services. Where the organisational groups are units within a larger organisation, group-level strategies should clearly fit with Enterprise-level strategy.
3. Operational Level- Operations Strategies are concerned with how the components of an organisation effectively deliver the Enterprise- and group-level strategies in terms of resources, processes and people. For example, a magazine company who has to keep raising external finance to fund its rapid growth will have its operational strategy partly geared to meeting investment needs. In most organisational groups, successful strategies depend to a large extent on decisions that are taken, or activities that occur, at the operational level. Operational decisions need therefore to be closely linked to group-level strategy. They are vital to successful strategy implementation.

The confusion around strategy and its definition and nature has been discussed throughout the last century. There is a noticeable increase in this discussion between 1956 to 1996 (Urwick, 1956, Liddell Hart1967, Steiner, 1979, Andrews, Dow-Jones, 1980, Tregoe, Zimmerman, 1980, Porter, 1986, Robert, McGraw-Hill, 1993, Treacy Wiersema, 1994, Mintzberg, 1994, Porter, 1996). Despite this fact and the several ways in which strategy is applied (de Wit, 2017, Duggal, 2018, Danford, 2018, Gray, 2018) there are very many useful theories i.e. frameworks, methods, approaches and artefacts. We don’t wish to critique them or discuss their usefulness, but rather discuss the need of alignment and harmonization in order work more integrated and have the ability to model, engineer and architect strategies along the strategy lifecycle. What we therefore do critique is that none of them build on a common ontology, as a matter of fact; they all use different concepts, definitions, terms, objects and symbols. Therefore, in reality, for organisations applying these theories, it becomes clear that there is no underlying concept. The organisational strategy management landscape is rich with various models, frameworks and theories. It is a well-established academic field that complements the endeavour of strategy practitioners in industry. Nonetheless, the more these are applied, the more siloed the end result becomes. This endangers the entire strategy lifecycle process from strategy analysis, strategy design, strategy development, to strategy execution and the continuous improvement of the strategy (Caine, von Rosing, 2018). No wonder organisations have such a low success rate, within and around the work of strategy (Caine, von Rosing 2018). This is where we will learn from another discipline called Ontology and apply it to strategy. Ontology, within an enterprise modelling context allows us to share and reuse meaning (Grubber, 1995). Some of the most recognised strategic models and theories shall be briefly discussed through an ontology lens, to help contextualise the need for a Strategy Ontology. A fundamental principle we consider whilst discussing each of the theories is whether each of them intend to implement a shared business vocabulary and symbols that can be adopted and integrated into other existing theories and models. Furthermore, we discuss if there is an intention of reusability amongst the concepts. Reusability within an enterprise modelling discipline enables more effective integration throughout the enterprise layers (von Rosing & Laurier 2015). It doesn’t take long to identify some of the most recognised academic and industry strategic management methods, Godfrey (2016) & Johnson & Gerry (2017) both discuss Balance Scorecard, Five Forces, Generic Strategies (Competitive Strategy), Value Chain (Porter, 2001) and Blue Ocean Strategy (Kim and Maugborne, 2005) with this inclination. Due to the limitation length on this paper other models and theories are excluded from the discussion, but the same principles and findings apply, where fundamental gaps of strategy ontology exist. In order to prove that point, we will therefore concentrate on some of the most widely used concepts.

1.1. The Balanced Scorecard

Kaplan and Norton’s (1996) Balanced Scorecard (BSC) method gained traction with its justification rooted in the practical application to twelve representative organisations from different industries (Kaplan & Norton 1996). At a time when financial measures of a company dominated the concept of valuing business and where intangible assets were not deemed significant towards organisational performance; the BSC recognised the importance of combining intangible with tangible assets in order to achieve desired strategic outcomes (Kaplan 2009). As intended, an enhanced performance management system is the basis of the BSC focusing on 4 main organisational metrics with the financial metric the most significant namely: customer, learning and growth, internal process and financial. Whilst these four metrics are important, the fundamental questions within the model miss key integrated aspects of the organisation. For example, processes exist to deliver a specific service which in turn is part of an organisational function, but these fundamental aspects are not considered at this early stage (Caine & Polovina 2018).

The BSC informs the Strategy Map artefact that forms a pivotal step within its approach. This takes key information from the four aspects highlighted in the scorecard (objectives, metrics, targets and initiatives) and places them within a causal linkage structure that aims to display a high-level perspective detailing the linkage starting with employees and continuing through to process, customer and then ending with financial performance.

Further developments of the BSC have replaced the emphasis on it being a ‘enhanced performance management system’ to what is now known as the ‘interactive management system for strategy execution’ (Kaplan 2009). This is an attempt to capture the lifecycle of strategy from development through to design, execution and strategy monitoring. It advocates that it needs to be part of a system wherein all aspects should be aligned. It is the alignment of all aspects associated with strategy that we argue with the Strategy Ontology. Although there is some evidence of the BSC aligning aspects of strategy there is no claim to an underlying ontology, nor is there an exhaustive set of semantic relationships that explicitly delineate all the possible relationships between the aspects of strategy. In the later chapters we will detail how the strategy ontology builds upon the BSC and through doing so, it provides a more rigorous approach to strategy analysis, design, development, execution and continuous improvement.

1.2 Porter’s Contribution to Strategy

The 1980’s witnessed the intervention of Michael Porter’s strategy paradigm. Renown for the Five Forces, Generic Strategies and Value Chain his works is still part of academic and industry practice today. The five forces model was created with the purpose of assessing the attractiveness (profitability) of a selected industry. The model is based around five forces that Porter believes remain attached to industries no matter what type or time era (Godfrey, 2016). In practice, once the strategy practitioner has assessed the profitability of the industry, the emphasis is then placed upon reshaping the forces to further enhance profitability and reduce the risk of being vulnerable to attacks from competitors. One cannot expect to map all the forces (internal or external) that impact an organisation by use of the five forces model. This is not the intention of the model however, one cannot ignore the importance of this step during strategy analysis (Johnson & Gerry 2017). Later in this paper we discuss how the strategy ontology encompasses the five forces in addition to the remaining forces (internal and external) that need to be considered during your strategy development. Through this we demonstrate how the strategy ontology complements and builds upon the five forces model.

1.2.1 Porters Generic Strategies – Competitive Strategy

Porter developed the Generic Strategies with the intention to place a specific focus behind the organisational strategy. Having determined the profitability of the selected industry through the five forces, the generic strategies now places emphasis on how an organisation should compete (Godfrey 2016). Cost leadership (1) and differentiation (2) whether broad (3) or focussed (4) form the basis of the four generic strategies. These have a relationship with the five forces and propose guiding principles that help organisations maintain competitive advantage. Later we shall discuss how the strategy ontology provides the foundation to apply interlinked modelling disciplines such as cost modelling and value modelling that builds upon the generic strategies. This also provides the basis to connect to other strategic propositions and thus apply associated business modelling, architecture and engineering techniques that extend the use in reusability of concepts within enterprise modelling.

1.2.2 Porter’s Value Chain – Competitive Advantage

The value chain aims to bridge the gap between strategy formulation and implementation. With a focus on manufacturing it classifies organisation activities into primary and supporting with the aim of each primary activity adding value down the chain ultimately leading to increased profits (margin). The value chain model (Porter, 2001) is at a conceptual high-level perspective therefore each activity whether primary or secondary is not accompanied with detailed implementation steps neither is each activity integrated into an architecture that interlinks all aspects of strategy. Before one is able to interlink aspects of strategy an underlying ontology must be in place to enable a shared vocabulary that supports the interlinking of strategy concepts and; just as important the reusability of concepts. Something which is missing in traditional strategy development (von Rosing & Laurier, 2015).

1.3 Blue Ocean Strategy – Value Innovation

Kim and Maugborne (2005) argue that value innovation consists of placing emphasis on deriving value from a customer focussed perspective as opposed to focussing on your competitors. Blue ocean strategy, arguably the most recognised value innovation strategic theory places innovation at its core in creating uncontested market space (Godfrey 2016). Whether within a red ocean (an existing competitive market space) or a totally new market – blue ocean strategy entails the use of a strategy canvas and four action framework. The canvas captures the current competitive factors for the selected industry and yours and your competitors offering level for each factor. This can quickly give you an insight to the associated value curves and also highlight the potential white space (or uncontested markets). To help carve out the uncontested market Kim and Mauborgne propose the four action framework. Essentially, this is four questions that focus on: eliminating industrial assumptions that no longer have value, determining what aspects can be reduced as a result of over serving customers, identifying where you can create value that is untapped and raising the level of value in an uncontested space. Whist these are very important questions, it is still high level and like the other strategic theories there is no underlying ontology. Whilst this is a very brief summary of the development in strategy concepts, it is important to understand the gaps in the existing theoretical strategy landscape. For example Porter’s Five Forces does not integrate with strategy options and strategy design, the BCG Matrix does not integrate with strategy execution. The Value Chain which has the highest level of organisational view, does not integrate with the developed strategies or even strategy governance. Newer concepts such as the strategy map, are neglecting the needed links to internal or external forces and trends, the organisational competencies, roles involved in terms of owners, as well as an absent relation-ship to mission and vision. The gap between the relationship of strategy and its con-text i.e. forces, mission, vision, organisational components, owners, etc. in existing theory is what separates the ability to work with strategy in the course of its lifecycle. In the later chapters we will delineate gaps filled by the Strategy Lifecycle and through doing so establish its position.

We have just elaborated on the various gaps in the existing theoretical strategy landscape and how there is a need to work with strategy in the course of its lifecycle. What we need is to manage the entire Strategy Lifecycle, from strategy understanding and analysis, strategy options and design, strategy development to strategy execution as well as strategy governance and continuous strategy improvement. A lifecycle approach is needed, as it is an instrument to represent the course of developmental changes through which the strategy evolves during its lifetime. Both in terms of evolution but also changes as it passes through different phases during its lifetime exinstance. As illustrated in figure 1, from strategy understanding and analysis, strategy options and design, strategy development, strategy execution as well as strategy governance and continuous strategy improvement, the lifecycle helps guide the strategy practitioners to work with the strategy during its development phases and lifespan. It enables the mapping of relevant components such as forces and trends, risk, organisational competencies, owners as well as the specification of activities needed for strategy execution and governance. What is also worth commenting is the necessity of continuous strategy improvement that facilitates the feedback loop in a systematic approach, where depending on the degree of change it can help an organisation optimize its underlying strategy and activities to achieve more efficient results.

The Strategy Lifecycle thereby consists of a set of phases in which each phase is interlinked with the previous one. It provides a highly useful sequence of phases and steps that any strategy practitioner, executive, business analyst or even business architect can follow, regardless of industry and size of organisation. The proposed Strategy Lifecycle concepts are as discussed interlinked between each other, but it also can be combined with any kind of other lifecycle thinking, such as the product lifecycle, value lifecycle, service lifecycle, process lifecycle, application lifecycle or an enterprise architecture lifecycle [27]. The previously mentioned possibility to integrate lifecycle thinking, helps various practitioners place focus on all relevant strategy aspects from business, information and technology aspects. Which on the one hand is a part of strategy execution, but can also help with the Strategy Lifecycle phases of strategy analysis, strategy design input as well strategy development.

In the context of the analyse and understand phase, the most relevant steps, include assessing the forces, identify drivers, analyse the existing strategy on both enterprise area and group level. At this point it is evaluated if there are new forces and drivers, which includes analysing and understanding the market, the competitors, the complementors, etc. It is important to recognise which forces and drivers are not properly addressed by the existing strategy. It is very unlikely that an existing strategy is able to address all new forces, trends, and drivers (value or performance). As a part of the analyse and understand phase it is not only vital to identify impacted organisational areas and groups but also the impacted roles i.e. stakeholders, owners and/or critical participants. In the wider context of the Strategy Lifecycle, this phase includes a link to change management and based on the degree of change a relationship to the Continuous Strategy Improvement loop.

After having analysed and understood the strategic situation, the next stage is to explore the strategic options. Following this is the insight gained into the strategy design possibilities. The most significant steps, include evaluate the strategic options to address the forces. This encompasses as illustrated in figure 2 specifying which new forces and trends are addresses by which enterprise and or organisational area strategy. This encompasses the external customer, partner and supplier drivers as well as the internal performance and value drivers. Objectives and goals that link to the strategies are established. Too sadly an often forgotten step, is the determination of the organisational change potential i.e. business model and operating model innovation and transformation. In the wider context of the Strategy Lifecycle, this phase includes a link to change management and to the Continuous Strategy Improvement loop, based on the degree of medium to high change.

After having evaluated the strategy options and design possibilities, the strategy development is the next natural phase. This is where the actual enterprise, and possibly organisational area and group strategies are defined. Objectives and goals that link to the strategies are established. The organisational change needs are outlined and so are the innovation and transformation needs. At this phase also the enterprise portfolio changes are detailed and the various strategy owners should be aligned. If the last mentioned point doesn’t happen, it will create siloed strategy execution and additional alignment work is needed [28]. In this phase the change management component plays a more active role. As the previous described phases, based on the degree change, this phase has a link to the Continuous Strategy Improvement loop.

Once the strategy has been developed the succeeding phase is strategy execution. This is where the actual enterprise, and possibly organisational area and group strategies are communicated. The interlinked objectives, goals and related measures are rolled out. As already discussed in the earlier Strategy Lifecycle phases, the nature of the forces and trends determine the strategic options and therefore the developed strategy and objectives. It also specifies the associated modelling disciplines, which is relevant for the strategy execution. As illustrated in figure 3, in order to enable the objective of ‘strengthen innovation’ to support the strategy ‘improving your competiveness’ one would need to entail revenue and service modelling concepts. Improve operation excellence denotes a different approach to modelling, where it is more relevant to apply operating modelling concepts and process modelling as you are aiming to increase efficiency in the way you do things.

Table 1: Example of Integrated Artefacts.

It is therefore in this phase where the organisational changes such as re-organisation and roles and thereby competency re-allocation is put into operation. Our empirical data proved that if in this phase, the changes or re-allocation of organisational functions does not lead to innovation of the services or processes then besides a new strategy; nothing else has really changed. The strategy execution will not succeed as intended. While there is a link to the Continuous Strategy Improvement loop, at this phase the degree of change potential in that loop is low to medium.

As most strategies are implemented and maintained for a number of years, long term strategies tend to stretch from 5-10 years, sometimes even longer. Short term strategies will typically range from 1-3 years. The Strategy Governance is a vital component of maintaining, upholding, updating and sustaining the direction. This is where a board, based upon the organisation’s mission, vision, values, strategies and defined objectives administrates the strategic business plan. In addition, risk evaluation against the existing strategy, portfolio and project initiatives. The majority of this is done through existing performance measures and reports, which are tracked against business scorecards. Further to the mentioned strategy governance concepts, the strategic, tactical and operational management, monitoring and audits ensure the direction taken is maintained and if needed is adjusted. When major directional changes are needed, it initiates the next phase, which is the Continuous Strategy Improvement.

Continuous improvement, in an executive management context means a never-ending effort to identify performance and value potential and remove issues and problems [29]. Depending on the performance and value potential as well as the issues and problems, continuous improvement for the most involves various incremental or small-step improvements rather than one overwhelming transformation or innovation. Continuous strategy improvement is a concept, supporting the Strategy Lifecycle phases with a change feedback loop, infusing the progression of all strategy related subjects, from adjusting the strategy, improve measures, fine-tune and enable organisational innovation and transformation. It involves everyone, management and labour-force, in finding and eliminating both issues and problems but also enabling change.

Godfrey (2016) argues the concept of the CEO as Strategy Architect but there is no suggestion of an architectural framework that connects all aspects to strategy. A fundamental pillar of software engineering is the ability to reuse existing software to facilitate the specification, production, classification, similarities in requirements and the ability to retrieve in order to enhance development productivity (Kotovs, 2009). Without reusability the process of producing software becomes less efficient and less standardised. When examining the traditional approaches to strategy and some of the commonly used models and theory, there is a distinctive lack of common taxonomy and thereby reusability. When applying the models and theories, the associated outputs are not designed to interlink, relate and be reused. The models above don’t use a common standard vocabulary which means that if there is any chance of reuse the nature of the models negate this possibility. The foundation of providing the opportunity for reuse has to have a shared standard for use of vocabulary or in the case of strategy, business terms (von Rosing & Laurier 2015). The challenge that the strategist faces is to devise an effective means of filtering the high level plans into operative tasks that execute the strategy. When the principle of reuse is applied in software development it enables the development of a more robust software architecture that relates components throughout the different software modules. Strategy needs to benefit from the same principle so that high level strategies can be related to different levels and layers of the enterprise therefore providing an enhanced ability to monitor and execute strategy.

We have the body of literature on the possibility of representing objects through their respective relationships and how this is built into nearly all engineering, architecture and modelling languages. From conceptual modelling (Polovina, von Rosing, 2017), process modelling (von Rosing, et al 2014), value modelling (OMG VDML) or concepts like enterprise architecture (Albano, Bergamini, Ghelli & Orsini, 1993), they all have the possibility of representing objects through their respective relationships and to provide models of understanding and models of execution. Yet no consensus has been reached as to how strategy concepts (Caine, von Rosing, 2018) should be represented or integrated into the established concepts (Bock & Odell 1998). A good example is OMG (Object Management Group), which creates various modelling software standards. They have strategy or strategy related objects in various standards within their Business Motivation Model specification. While it should illustrate how various business factors and elements interrelate, they also have some of these elements in the Value Delivery Modelling Language (OMG VDML, 2017), Business Architecture Meta Model (OMG BAMM), Case Management Model and Notation (OMG CMMN, 2017), as well as many others. Nevertheless, none of the ‘same’ elements have the same notation/shape, attributes, class types, definition and while it could be argued that the mismatch of ontology will not impact the principles of the specific software tool. It does add to the confusion, misunderstanding and siloed enterprise modelling. It also leads to possible mixups, misinterpretation of and potentially an inability to reuse the content.

The discussed concepts, don’t only have different descriptors (for the same), but also diverse semantic relationships in different standards and modelling languages, even when they relate to the same or similar objects. The confusion doesn’t stop there, none of the mentioned standards i.e. BMM, BAMM, DMN, CMMN, VDML etc. use or apply the definition set up by the OMG standard “Semantics of Business Vocabulary and Rules” (OMG SBVR, 2017). This confusion of taxonomy as well as semantics enforces siloed modelling. This also applies to other Strategy concepts that exist within other standard bodies like ISO, CEN, NATO, UN and even the architecture standard body Open Group. It clearly illustrates that there are no underlying ontology or semantics that describe how Strategies are defined, expressed, portrayed or related. Moreover, it doesn’t specify which class types exist and how could or should Strategies be modelled. It is therefore the objective of the requirements to a Strategy Ontology to specify the relevant objects, define how class types can be defined, state clear descriptors, illustrate the shapes i.e. notations as well as define the attributes. In addition to that it will outline how the semantic relations and a meta model should be defined.

We have extrapolated various challenges, issues and problems around the topic of Enterprise Taxonomy requirements to Strategy concepts. We have quantified a lot of different requirements, which have been sorted and summarized in short below:

1. Meaning of what strategy is and what it isn’t
2. Identification of the strategy relevant objects
3. Clear defined descriptors to the strategy relevant objects

We have extrapolated various challenges, issues and problems around the topic of Semiotics and Enterprise Semantic requirements to Strategy concepts. We have quantified a lot of different requirements, which have been sorted and summarized in short below:

1. Nouns and Verbs: The nouns representing classes of objects and the verbs representing relations between the objects.
2. Strategies can address and relate to other Strategies. This mirrors the condition that a specific strategy can relate to another strategy. The Strategy Ontology should therefore incorporate and enable strategies to have instances, stereotypes or subtypes, all with the ability to semantically relate.
3. Strategies depend on relationships. Most strategies are only meaningful in the context of a specific semantic relationship. For example, a specific strategy addresses the market, while another could address cost reduction and again another could address risk or operational excellence. Although a fundamental characteristic, many definitions of the strategy concept do not consider it, although the states or phases of an object are equally regarded as their strategies. Consequently, the Strategy Ontology should have the meaningful semantic relationships defined.
4. A strategy can be related from or through one object to another. For example, there is no semantic relationship between strategy and specific process tasks. However, a strategy could relate to a functional area, where the process task is executed, where the strategy therefore is relevant, maybe even critical. In the Strategy Ontology it should therefore be possible to let a specific strategy be related indirect through the semantic relations. The indirect relationships should all be located in the strategy meta model (see section 5).
5. Delegation of attributes. When objects that have direct relationship to a strategy, relate to other objects, they may share structure and behaviour through delegation of attributes. This usually means that Strategy definitions inherit from each other, but sometimes also that the definitions of Strategies rely on features of the objects relating to them. This delegation of attributes should therefore be ensured in a Strategy Ontology. It should be done, through specification of which objects relate directly and indirectly to each other. Through these clear documented relationships, the shared structure and behaviour through delegation of attributes is ensured.

We have extrapolated various challenges, issues and problems around the topic of Enterprise Modelling requirements to Strategy concepts. We have quantified a lot of different requirements, which have been sorted and summarized in short below:

1. Since Enterprise Modelling is the abstract representation, display and graphical description of any arrangement. Strategy modelling should be the discipline of representing and replicating the strategy relevant aspects that are being modelled to have a simplified representation of the real thing (As-Is) or the thing to come (To-Be).
2. Strategy Notations. The body of literature on the possibility of representing enterprise objects through their respective symbol is immense and built into nearly all enterprise modelling as well as engineering languages (Albano, Bergamini, Ghelli & Orsini, 1993). However, to provide models of understanding and/or models of execution, no consensus has been reached as to how a strategy and strategy related objects should be graphical represented (Caine, von Rosing, 2018). Therefore, a pivotal aspect of a Strategy Ontology is the graphical symbol representation in terms of shapes/notations for the strategies and strategy related objects.
3. An object may, in real life and within any model, relate to the same strategy several times, simultaneously (same semantic relationship), but have different attributes and properties. This is an equally fundamental finding, a frequent example of which being an employee holding several employments. Unlike with different strategies, where a specific disruptive force could be impacting several strategies. However, it does not correspond to multiple frameworks classifications. For example, a strategy addresses one driver, trend or force, but the same strategy could also address other drivers, trends or forces. The main reason to distinguish multiple occurrences in the same strategy is that each occurrence of the object in a Strategy is associated with a different state (see next point)
4. The sequence in which Strategies may be developed and relinquished can be subject to restrictions. For example, a specific strategy can commence after certain tasks have been fulfilled. Like rules of employment. A person can become a teaching assistant only after becoming a student. Same principles apply to strategy work. The usual sequence specifying formalisms in the Strategy Ontology, are in use through rules that apply. Therefore, rules must be able to apply to strategy relevant objects.
5. Features of an object can be strategy-specific. Attributes and behaviour of an object may be overloaded on a by-strategy basis, i.e., different strategies may have the same focus or even function and thereby declare the same features. But they may realise or execute them differently. An example may be through different processes that address the same strategy. The Strategy Ontology should be able to relate several strategies to the same objects. For example, a specific strategy ‘Increase competitiveness’ can have the same ‘feature and function type’ like the strategy ‘improve Customer Interaction’. This is ensured through permitting different strategies, to address and have the same function and thereby declare the same features.
6. A strategy object and its purpose, objective, responsibilities, functions and processes (may) have different identities. This view, which is quite singular, is attributed to the so-called counting problem (von Rosing, Zachman, 2017). It refers to the situation in which instances counted within strategies yield a greater number than the same instances counted by the objects addressing the strategies. Therefore, in the Strategy Ontology, each strategy instance of any strategy class type, should be able to have different identities.
7. An object and its strategies (may) share identity. We just discussed in point 14 that in the Strategy Ontology, each strategy instance of any strategy class type are able to have different identities. However, it should also be able to have the same identity so that the concept of reusability can be performed when called upon.
8. The state of an object as separate instances. The state of an object may vary depending on the strategy which it is addressing. Together with item 4, 6, 13 and 14 i.e., the possibility of one object, addressing the same strategy through multiple instances at the same time, should be implemented in the Strategy Ontology. This is done through the facility that each strategy defined by the organisation, should be viewed as a separate instance of a strategy object. Depending on decomposition, this could be a separate instance of a strategy class type object, or a stereotype, type or a subtype.

We have extrapolated various challenges, issues and problems around the topic of Enterprise Engineering requirements to Strategy concepts. We have quantified a lot of different requirements, which have been sorted and summarized in short below: 

1. Interlink the strategy levels: It needs to link the Enterprise level, group-level and operational levels. Each level needs to be aligned with the others. The demands of integrating levels define an important characteristic of strategy; strategy is typically complex, requiring careful and sensitive management.
2. Strategy has no existence apart from the ends sought. It is a general concept that provides guidance for actions to be taken in a specific phase of the strategy. There is a need to enable the modelling practices around strategy concepts, considering the entire Strategy Lifecycle, from strategy analysis, design, development, execution and continuous improvement. (Caine, von Rosing, 2018).
3. As specific strategy comes with its own properties and behaviour. This basic property suggests that any kind of strategies are types. Therefore, any Strategy Ontology should have strategy class types defined, where there are rules and concepts of how to breakdown strategies into its smaller parts.
4. Any business object may address different Strategies simultaneously. For example, a business strategy, could also have specific information i.e. application strategy relevance. Because a strategy is usually regarded as a type (see item 1), it amounts to the multiple classification of objects in for example business, information and technology categorisations and classifications.
5. An object may relate and abandon strategies dynamically. This is a dynamic property of the strategy concept that comes close to object migration or dynamic (re)classification. However, the two are not necessarily the same. Subsequently, the Strategy Ontology should be able to use the strategy classes for dynamic (re)classification.
6. Objects of unrelated types can apply to the same strategy. Although a fundamental observation complementing those of items 5, 6 and 18, it is not acknowledged by all strategy concepts. From a theoretical point of view, this feature amounts to an alternative basis for inclusion polymorphism. The Strategy Ontology should therefore through the attributes of the objects and the semantic relations have polymorphic ability. There should be several fundamentally different kinds of polymorphism abilities within a Strategy Ontology, namely:
   1. Ad hoc polymorphism: when a function denotes different and potentially heterogeneous strategy implementations, depending on a limited range of individually specified types and combinations.
   2. Parametric polymorphism: when a new strategy instance is created, without classifying it to any specific class type, it can be used transparently with any number of new types. In the object-oriented community, this is often known as generics or generic categorisation. In the functional programming community, this is often shortened to polymorphism (Tucker, 2004).
   3. Subtype polymorphism or inclusion polymorphism: when a name denotes instances of many different classes related by some common superclass and the subtypes are specified (Booch, et al, 2007). In the object-oriented community, this is often referred to as simply polymorphism.

We have extrapolated various challenges, issues and problems around the topic of Enterprise Architecture requirements to Strategy concepts. We have quantified a lot of different requirements, which have been sorted and summarized in short below: 

1. Enterprise Architecture encompasses the organisation, administration of contextual, conceptual, logical and physical relationships and connectivity of specific objects and artefacts to each other (and the environment) in order to understand complexity and manage structure to enable transformation, performance or value. A strategy ontology should enable the structuring of its objects and artefacts according to contextual, conceptual, logical and physical representations.
2. A strategy ontology and its meta model should portray semantic relations across the enterprise layers of the Business Layer, Information Layer and Technology Layer.
3. The structuring and thereby the affiliation of meta objects according to their relevant architectural relevant layers enables practitioners to use them in their direct context. This principle also applies to strategy, especially since strategy relevant meta objects have multiple interaction points within one layer and across the architectural sublayers e. Value Architecture, Capability Architecture, Service Architecture, Process Architecture, Application Architecture, Data Architecture, Platform Architecture, Infrastructure Architecture.
4. Integrated Artefacts: A Strategy Artefact is a product documentation that consists of strategy map, strategy matrix, or strategy model. With relationship to the strategy ontology, the different strategy artefacts should be part of an overarching ontological based specification which ensures that all of the objects are semantically related. The relationship between strategy ontology and artefacts should also be found in the strategy meta model. Reuse of the content of one strategy artefact or view to another is therefore ensured.

An ontology is a formal description of entities, descriptors and their properties, relationships, constraints and behaviours (Gruninger, M., 1997). In this segment, we discover how the Strategy Ontology as an application ontology should relate to other enterprise ontologies, specific domain ontologies and enterprise task ontologies. We will therefore elaborate on the concept of ontologies and the need for a holistic and integrated enterprise ontology (von Rosing, Zachman, 2017). This should begin with the categorisation as well as classifications of the relating ontologies. Specifying the relationship among the ontologies and moving through to the semantics and axiomatization of ontologies until we come to the specific Strategy Ontology.

There are various categorisations as well as classifications of ontologies both in academic literature (Gomez-Perez et al. 2004; von Rosing & Laurier, 2016; Borgo 2007, Lassila and McGuinness 2001; etc) as well as in practice OWL, OMG MOF, etc. Each of them have a specific purpose, therefore the categorization and the classification are focused on the expressivity and formality of the specific languages used or proposed i.e. natural language or formal language. In the context of the Strategy Ontology, what is relevant is that as an application ontology, it is proven to have relationships and be interlinked with other application ontologies, domain ontologies, core reference ontologies and the foundational ontology (Roussey et al, 2011, von Rosing, Zachman 2017).

For example, Fonseca et al. (2006) describes a foundational ontology of geographic objects and a similarity measure to evaluate the interoperability of domain ontologies based on this higher level ontology. As each ontology has a specific purpose, therefore the categorization and the classification to other enterprise ontologies are relevant to its context (von Rosing, Zachman 2017). We will therefore specify some requirements to the Strategy Ontology categorisation and classification to other enterprise ontologies. We will start at the top and thereby the highest level of relationships i.e. the foundational ontology, then to the relationship to core reference ontology, domain ontology, task ontology and then the relationship to other application ontologies.

All consistent ontology should have a foundational ontology. (Roussey et al, 2011, von Rosing, Zachman 2017) Foundational ontology can be compared to the meta model of a conceptual schema (Fonseca et al. 2003). It is a system of meta-level categories that commits to a specific initial-view. The relationship between the Strategy Ontology and the Foundational Ontology is that foundational ontologies can be viewed as meta ontologies that describe the upper level concepts or primitives used to define the other ontologies. (Roussey, C., Pinet, F., Ah Kang, M., and Corcho, O. 2011). In the case of the Strategy Ontology, an Enterprise Ontology should be used as the foundational ontology, providing the fundamentals, like basic objects, relations, structure, arrangements, notations/shapes and so on.

When considering the Strategy Ontology, there should be numerous foundational ontology objects and semantic relations that are relevant. This was also specified as a requirement to the Strategy concepts in. As an application ontology, the Strategy Ontology should be a specification of the concepts of the particular domain and task ontologies, which again relates to a core reference ontology i.e. enterprise/business ontology. Thereby fulfilling the specific purpose of applying only the strategy concepts, but being able to relate to other enterprise concepts. Having the ability to categorise and classify the Strategy Ontology round other related ontologies is a major benefit. The scope of the Strategy Ontology, is narrower than the scope of the domain ontologies i.e. value ontology or competency ontology.

The domain ontologies have more specific concepts than the core reference ontologies, which contains the fundamental concept of a domain. So the requirement to the Strategy Ontology as an application ontology is that it relates to other relevant application ontologies, furthermore to the domain and task ontologies as well as to the core reference ontology and the foundational ontology. This ensures that strategy can relate to other relevant enterprise concepts.

The notion of meta modelling is well established and commonly used in the realm of model-driven engineering (Groener, Jekjantuk, Walter, Parreiras, Pan, 2013). There are standards which describe the model driven architecture (Pan, et al 2012) and provide language and modelling specifications such as UML (OMG UML). However, meta modelling is only weakly considered in the context and realm of ontologies and ontology engineering (Groener, et al, 2013). This is a weakness in two dimensions (Groener, et al, 2013). Firstly, from an ontology creation perspective, the modelling and design principles of model-driven engineering, including meta modelling, benefit from abstraction of a concrete system. These principles are only weakly exploited in ontology creation and design. Secondly, if we consider meta modelling more generally as modelling with metadata, this becomes very relevant.

The Strategy meta model would be relevant as it would be an abstraction of the strategy system, as it would describe and define the various Strategy Ontology objects class, stereotypes, types and subtypes, their relations and how they all integrate. The Strategy meta model should not only portray the strategy relevant objects, but also portray the strategy levels i.e. enterprise, groups and operations and linking the semantic possible related objects to these levels. As an application ontology meta model, the strategy meta model should relate to other relevant application ontology meta models. Moreover it should also relate to relevant domain and task ontology meta models as well as the core reference ontology meta meta model and the foundational ontology upper meta model. Therefore, the Strategy Ontology meta model should be a subset and should as discussed relate to the mentioned meta model and meta meta models.

The Strategy Ontology meta model should be visually represented, enabling first-order logic that facilitates the visualised objects and relations in the ontology to be articulated as a (class) hierarchy. By linking (meta) objects to each other through their object relations, the direct and indirect interrelationships in and across the various business concepts and class hierarchies can be discovered. It should be the vehicle by which it links to the Enterprise Ontology and the semantics foundation within can be linked and also expressed in the meta meta model (von Rosing, Laurier, 2015).

The Strategy meta model should, furthermore, be portrayed with strategy relevant objects at a class types level and where specifications like strategy levels i.e. enterprise, groups and operations are needed it should illustrate stereotypes and where necessary types, linking the semantic possible related objects. These relationships are polymorphic; properties affecting a super-object that will cascade to all its sub-objects. Thus, if we make an assertion about one part of the meta model i.e. the Strategy Meta Object of the meta model then that assertion will also apply to all its sub-objects. Note it does not apply the other way, thus for example an assentation made about the application Strategy will only affect that object. Otherwise it would wrongly affect everything that comes under all the Strategy objects and therefore to the entire meta model! Consequently, the strategy meta model would have the ability to apply reasoning at multiple levels and even at the core reference ontology layers i.e. business, information and technology as well as the domain ontology sub-layers. In the previous section we elaborated how the strategy meta model delineates the association and correlation of the objects within and across the layers (as defined in the requirement section above).

The strategy meta model should focus on the objects and relationships of the Strategy Ontology, which relate to the concepts of the domain ontology, where the graphical representation illustrates the cross relationship possibilities of the ontologies. It is imperative that the meta model shows the key “cross connections” or relationship between each of the related ontology concepts i.e. foundational ontology object and semantics specific to the Strategy Ontology in the context of the domain: value ontology.