Models, conceptual structures, and enterprise architecture
•Download as PPTX, PDF•
3 likes•1,348 views
Many disciplines rely on models to represent reality. Models may range from a miniature representation of some physical entity, to a simplified representation of a system or phenomenon so we can understand and test it. Not all models can represent their corresponding real-world entities as easily as a model of a building or a motor car. Models of economic or social systems for instance are representations more of concepts and beliefs than physical forms. An enterprise, such as Sheffield Hallam University, is more than just its buildings, equipment or financial statements. Such visible entities are simply the structures that follow from its strategy, which is just as real. Strategy is moreover the driving entity and the enterprise is ineffective without it. Enterprise Architecture (EA)recognises that enterprises (profit-making or not) are essentially creative human endeavours. They are embodied in conceptual models that sit uneasily ‘on the same page’ with the structural models that depict how enterprises physically organise themselves to achieve those endeavours. These models pull in different directions and the physical entities tend to win out due to their visible presence; history shows the emergence of bureaucratic structures, inter-departmental conflicts, inadequate computer systems and other experiences where strategy is lost and ends up following structure: ‘The tail wagging the dog’. For EA we desire ‘conceptual structures’, which align the expressivity of conceptual models with the simplicity of structural models. In EA frameworks, conceptual structures are presently expressed through ‘metamodels’ that attempt to bring together the conceptual with the structural. The seminar thus explores the adequacy of these metamodels through a simple Financial Trading case study. It is shown that by aligning the conceptual, logical and mathematical levels of the metamodels, constructive relationships can be made between concepts and structures. As such, structures support rather than hinder the human creativity that enables enterprises to better reach their goals.
Recommended
Recommended
More Related Content
Similar to Models, conceptual structures, and enterprise architecture
Similar to Models, conceptual structures, and enterprise architecture (20)
Recently uploaded
Recently uploaded (20)
Models, conceptual structures, and enterprise architecture
- 1. Models, Conceptual Structures, and Enterprise Architecture Simon Polovina Conceptual Structures Research Group C3RI / Department of Computing
- 2. Models of physical entities
- 3. Models of systems or phenomena • Only see through models • And noting that “All Models are Wrong, But Some are Useful” (Box, 1987) • Includes models of enterprises, which we can’t touch but are very real • Understood through “Enterprise Architecture” Sowa (2002)
- 4. Enterprise • “Space: the final frontier. These are the voyages of the starship Enterprise. Its five-year mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no man has gone before.” (Star Trek, quotes) • Origin: late Middle English: from Old French, 'something undertaken', feminine past participle (used as a noun) of entreprendre, based on Latin prendere, prehendere 'to take‘ (OED) • An undertaking, especially one of some scope, complication, and risk (thefreedictionary.com) • A business organisation (thefreedictionary.com) • You and me
- 5. Architecture • The art or practice of designing and constructing buildings (OED) • The complex or carefully designed structure of something (OED) • The conceptual structure and logical organization of a computer or computer-based system (OED) • Winchester Mystery House, Why • “From a blank piece of paper to the last nail in the wall”
- 6. Sowa & Zachman (1992) Enterprise + Architecture
- 7. &Today
- 8. Ontology • In Philosophy: – A theory of being – “does truth exist?” or “does energy exist?” • In Computer Science – Gruber “In the context of knowledge sharing, I use the term ontology to mean a specification of a conceptualization. That is, an ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy.” (emphasis added).” (Malik, 2009)
- 9. TOGAF (v9.1) • 1980’s TAFIM (from US DoD) • 1995 TOGAF v1 • Now v9.1 • Includes the ADM i.e. the Architecture Development Method (as shown) • And the Content Metamodel (shown next)
- 10. TOGAF’s Content Metamodel • Meta = ‘about’ • White entities are “core” and not to be omitted • Red/Blue/Green entities are “extensions” and can be omitted • Entity renaming is possible • Modification and removal of entities is not recommended • It’s the base template for your EA
- 11. Domain Semantics Rule of 3: Object Object relation
- 13. An Enterprise (Concepts and Structures)
- 14. A (Simplified) SHU EA
- 16. Architecting a Financial Trading Enterprise TRA Inc. buys and sells numbers of shares of securities and manages its clients’ assets. e.g. ‘Portfolio Manager’ Creates and manages portfolio Place (Buy/Sell) Order Derive profit on 'SQQ' (size, quantity and quality) of transactions. 25% market share by 2014; Top 3 of best-of-breed in Service polls Right down to the Database server, Network, …
- 17. As a Conceptual Structure (using Peirce’s cuts)
- 18. As a Conceptual Structure (Logical Level) Polovina & Andrews (2013)
- 19. As a Conceptual Structure (Mathematical Level) Polovina & Andrews (2013)
- 20. Redefined (Logical Level) Polovina & Andrews (2013)
- 21. As a Conceptual Structure (Mathematical Level) Polovina & Andrews (2013)
- 22. Concluding Remarks • Explored Models • Enterprise Architecture • Concepts and Structures • Examples – Sheffield Hallam University – Financial Trading • Conceptual, Logical & Mathematical • Questions?
Editor's Notes
- Title slide
- Abstract
- Where models are used that look like their real-world entities e.g. a car or a city
- And where they do not
- Definitions of Enterprise, which can just as easily range from Star Trek to us as individuals as well as business organisations (e.g. Shell, Sheffield Hallam University). Business organisations are an outcome of an enterprise, which needs to build an organisation to make its mission operational (‘make it so’ to use another Star Trek analogy).
- Definitions of Architecture, and its holistic scope as given in the last remark. For enterprises this would be from its purpose (why) thus its strategy (vision and mission) brought about through it organisational structure, processes, assets right down to the illustrated example of the network cable. Otherwise why is any of it there? Another thought: Is Winchester Mystery House an example of _good_ architecture, as it was to spec from the purpose right down to the last nail? Quoting from the link “Mrs. Sarah L. Winchester’s response to the deaths of her child and husband left a bizarre and impressive architectural reflection of her psyche.”
- Zachman’s original ISA Framework, first shown in Sowa & Zachman (1992). It shows the ontological relationships between the various models used by enterprises that range from its purpose (why), strategy (vision and mission), organisational structure, processes, and assets right down to the illustrated example of the network cable on the previous slide. By interrelating the models in such a way, the value of each aspect of the enterprise is brought onto the ‘same page’. Gaps are thus identified such as a) a mismatch through assets that do not align with the purpose or b) assets that are currently missing to realise the purpose. Further background is given in “A Brief History of Enterprise Architecture” (Sessions, 2007) : The field of enterprise architecture essentially started in 1987, with the publication in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman. In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed systems. As Zachman said: The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework.
- For more info refer to http://www.zachman.com/about-the-zachman-framework © 2008 John A. Zachman, CEO Zachman International®, Inc. And we see the term ‘Ontology’ being directly referred to.
- Malik (2009) argues that the Zachman Framework is not an ontology, essentially as there are no implicit relationships between terms in an ontology as Zachman suggests in his grid. We’ll see explicit relations in the TOGAF metamodel described shortly. We could counter-argue that the grid structure does give those relations as described earlier. What is pertinent is that for ontology we have concepts (or entities or objects) and relations. Zachman’s grid shows the relations of the models to each other thus their value to each other. In that sense it is ontological.
- TOGAF was initiated early 1990s as methodology for the development of technical architecture, and has been developed by The Open Group into an extensive enterprise architecture framework. In 1995, the first version of TOGAF (TOGAF 1.0) was presented. This version was mainly based on the Technical Architecture Framework for Information Management (TAFIM), developed since the late 1980s by the US Department of Defense In December 2001 TOGAF 7, the "Technical Edition", was published. TOGAF 8 ("Enterprise Edition") was first published in December 2002 and republished in updated form as TOGAF 8.1 in December 2003. Around 2005 TOGAFTM became a registered trademark of The Open Group. In November 2006 the Open Group released TOGAF 8.1.1. According to The Open Group, as of February 2011, over 15,000 individuals are TOGAF Certified. As of September 2012 the official register has over 20,000 certified individuals. The latest version is TOGAF 9.1, launched on 1 December 2011. An evolutionary development from TOGAF 8, TOGAF 9 includes many new features including: Increased rigor, including a formal Content Metamodel that links the artifacts of TOGAF together Elimination of unnecessary differences Many more examples and templates (http://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework)
- Metamodel is the model about the model; the diagram shown is TOGAF’s content metamodel. Specifically, it’s Figure 34-8: Relationships between Entities in the Full Metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html#tagfcjh_64 in chapter “34. Content Metamodel”). Essentially _every_ enterprise conforms to this model, particularly the white (core) entities. The coloured entities are extensions that extend the core entities, emphasising some particular aspect that we may wish to focus on e.g. the motivation extensions (Driver / Goal / Objective) shown in red. -- The metamodel content is signified by the viewpoints that http://www.togaf.info/togaf9/togafSlides9/TOGAF-V9-Sample-Catalogs-Matrics-Diagrams-v2.pdf illustrates -- Key Entities: DRIVER: An external or internal condition that motivates the organisation to meet or redefine its goals e.g.: Global banking crisis giving reduced access to external capital GOAL: A high-level statement of intent or direction for an organisation. Typically used to measure success of an organisation e.g.: Deliver the best customer service in our industry OBJECTIVE: A time-bounded milestone for an organisation used to demonstrate progress towards a goal e.g.: Increase capacity utilization by 30% by the end of 2014 ORGANISATION: A self-contained unit of resources with line management responsibility, goals, objectives and measures. Organisations may include external parties and business partner organisations. e.g.: Shell plc (or one of its brands…) ACTOR: A person, organisation or system that has a role that initiates or interacts with activities. Actors may be internal or external to an organisation. e.g.: A Sales representative who travels to visit customers ROLE: The usual or expected function of an actor, or the part somebody plans in a particular action or event. An actor may have a number of roles. e.g.: Warehouse Supervisor FUNCTION: Delivers business capabilities closely aligned to an organisation, but not explicitly governed by the organisation. e.g.: Make-to-Order Manufacturing BUSINESS SERVICE: Supports business capabilities through an explicitly defined interface and is explicitly governed by an organisation. e.g.: Credit Checking PROCESS: Represents flow of control between functions and/or services. e.g.: A process flow describing the Purchase Request Processing function, showing controls and events APPLICATION COMPONENT: An encapsulation of application functionality that is aligned to implementation structuring. e.g.: Purchasing Application DATA ENTITY: An encapsulation of data that is recognised by a business domain expert as a thing e.g.: Purchase Order TECHNOLOGY COMPONENT: An encapsulation of technology infrastructure that represents a class of technology product or specific technology product. e.g.: A bought-in vendor's Supply Chain Management technology PLATFORM SERVICE: A technical capability required to provide enabling infrastructure that supports the delivery of applications. e.g.: A bought-in vendor's Business Process Management platform
- SAP was a key contributor to TOGAF 9. Here is their metamodel for interest. Note some of the terminology (e.g. Business Information Service) is different and the Motivation extension (Red entities) in TOGAF is white (i.e. core) in SAP EAF, but its metamodel conforms to TOGAF as it ‘has not taken anything away’. We’ll use the SAP EAF in the next two slides to illustrate the population of the metamodel with its case study, the BEEST motor manufacturer (based on Porsche) and another being a High-Tech Manufacturer called “Infinity”.
- This is BEEST ‘as-is’ (baseline), in comparison to ‘to-be’ (target). So where BEEST is where it is today (as shown above) as opposed to where it wants to be (not shown). The difference is the gap.
- Another SAP EAF example, a High-Tech Manufacturer called “Infinity”
- With the above understanding of ontology, we have a definition of semantics – objects (concepts, entities) related to each other through relations, all set in a context (or domain of interest e.g. Business Architecture)
- The diagram describes TOGAF’s (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html, Figure 34-3: Interactions between Metamodel, Building Blocks, Diagrams, and Stakeholders). It illustrates TOGAF’s broader perspective, driven by its ADM. Note the pivotal position that Metamodel has is in the diagram. As you can see all the flows pass through it.
- An enterprise, such as Sheffield Hallam University (SHU), is more than just its buildings, equipment or financial statements. Here the physical structure is illustrated by the plan of the campus and represents what can be seen and touched. Next we are reminded of its ‘vision and mission’ (strategy) visualised through ‘What we do’ in its website. This cannot be touched but is very real and drives SHU. In this example it points to its staff that, like the campus, is (or ought to be) the physical realisation of What SHU does. This entities extend to the pivotal roles of students, research, and honorary (e.g. degree) awards. There of course others e.g. its computer-based information systems. These physical entities ‘make it so’ i.e. the structural features of the concepts (its strategy) that define SHU’s purpose. The measure of SHU’s success is illustrated by ‘Driving the Economy’ and the National Student Survey. These are KPI’s (Key Performance Indicators) by which SHU’s purpose can be evaluated. All the aspects described can be seen in the TOGAF metamodel, in its core, motivation and governance extensions as well as the others e.g. the Application, Data and Technology entities. Notably they are on ‘the same page’ and interlink through the relations that link between them. Hence Concepts and Structures brought into the same plane as Zachman originally depicted but in a more formal, semantic model (refer Semantics slide shown earlier).
- The model of the left shows a simplified conceptual structure for SHU. Admittedly it doesn’t map immediately onto the TOGAF metamodel for the sake of simplicity, but demonstrates the same EA principle. This is a ‘logical-level’ model as it is formalised by the concept-relations described earlier. It is shown using Sowa’s Conceptual Graphs (CGs), an introduction to which is given by Polovina (2007). Formal Concept Analysis (FCA) adds a mathematical level, further detailed in Hitzler and Scharfe (2009). As such it can test the logical model, shown by the model on the right. This concept lattice is generated by the CGtoFCA algorithm and accompanying software (Andrews and Polovina, 2011). Put simply, the algorithm takes the first concept before the arrow that points to its relation. That relation is then appended to (or concatenated to) that source concept. The destination concept (i.e. the second concept) that the relation arrow points to is shown by the line in the lattice. Chaining them together produces the FCA concept lattice that is the right hand side model. We can see that there is a concept (depicted in FCA by the circles) that has no label. Why?
- The ‘culprit’ is the fulfils relation in the previous slide – look at the direction the arrows were pointing in that model. Remember the earlier remark “From the blank piece of paper to the last nail in the wall”. To accord with the pertinence of that remark, as well as thinking about how the concepts and relations are named we should see on overall flow from the very top to the very bottom with every concept and relation thus interlined along the way. That is, after all, EA. Inspect the diagrams of this slide. The fulfils relation has become fulfilled-by. That’s a simple renaming, but all the arrows now follow one overall direction with all concepts and relations interlinked in that direction. FCA, through CGtoFCA identified it at the mathematical level. The left hand diagram was drawn by hand, as typical in many EA tools, but the right-hand diagram was computer generated. The productivity of computers has been applied to the creativity of human thinking – conceptual structures. Remember that enterprises are creative human endeavours. The overall flow depicts how structure should follow strategy. As such, structures support rather than hinder the human creativity that enables enterprises to better reach their goals.
- Here’s the CGtoFCA Algorithm, described in Andrews and Polovina (2011)
- And here’s a simple illustration of how it works, taken from Andrews and Polovina (2011)
- We now move onto exploring the adequacy of these metamodels through a more detailed but nonetheless simple Financial Trading (FT) case study. This enterprise, called TechRules Advisors (TRA Inc.) is a fictitious asset management firm (© Said Tabet and Gerd Wagner). Notably it includes Business Rules, which can be regarded as objects and their relations in a conditional form (e.g. ‘if-then’). They thus form a key part of the semantics in an EA. Description of the Case Study The company (TRA Inc.) buys and sells shares of securities and manages its clients' assets. Portfolio managers create and manage accounts. A portfolio is owned by a legal entity. The portfolio is managed by a portfolio manager who works for an investment firm. A portfolio is described by a creation date and a value. It has a number of positions. Each position holds an asset and is described by a quantity and an acquisition date. The value of a portfolio is the total value of all the securities held in the portfolio. There are three different categories of assets: real estate, cash, and securities. Real estate and cash are described by a name. Securities are described by: a security ID, a name and a price. There are three categories of securities: options, bonds, and stocks. Securities are issued by a legal entity that is called an issuer. The issuer can be: a company, a municipality, an agency, or a government. There are many reasons that motivate issuers to issue securities. For example, the issuer might need to repay debts or raise capital (get some money to invest). Issuers and the securities they have issued can be positively or negatively affected by market events. Market events could be upgrades or downgrades by credit rating agencies. Some issuers are classified as `restricted' by portfolio owners and investment firms. Orders (for buying or selling assets) are placed in the interest of a portfolio. An order is placed by a trader or by a portfolio manager. FT’s Business Rules The following are FT’s business rules: Securities issued by a ‘restricted’ issuer must NOT be bought. An asset must NOT be sold if it has been in the portfolio for less than 30 days. The total asset value (TAV) is the sum of the market value of all positions. The value of cash assets must be less than or equal to 10% of total asset value. A portfolio is rated platinum, if TAV is greater than 1 Mio dollars. It is rated gold, if TAV is less than 1 Mio dollars and greater than 100.000 dollars. It is rated regular, if TAV is less than 100.000 dollars. If there is a downgrade for a security held in a portfolio, the portfolio owner must be sent a “dispose recommendation”. This advises the owner that they should sell the security. An order placed in the interest of a portfolio must not refer to more than one asset held in a position of that portfolio. The trade date of an order placed in the interest of a portfolio must be after the date that portfolio was created. An order must not be placed both by the trader and by the portfolio manager.
- This slide shows the FT case study with its business rules using Peirce’s cuts and further expounded by Polovina and Andrews (2013). Polovina (2007) describes the workings of these cuts (the rounded rectangles in the above illustration). The cuts visualise the inferences in the model, which uses Conceptual Graphs (CGs). Essentially the cuts are used to depict the business rules in the case study. For example: Securities issued by a ‘restricted’ issuer must NOT be bought. Peirce's cuts capture that: IF a security is issued by a ‘restricted’ issuer THEN it must not be bought. It also captures that: IF a security is bought from an issuer THEN the issuer is NOT restricted. The business rules referring to the types of portfolio are also visualised by Peirce’s cuts, as are the other rules. Indeed the whole transaction is visualised as a rule, showing that if the conditions as described in the transaction are satisfied then it is an FT_Transaction. That distinguishes it from other types of transactions e.g. buying a book. It defines the very nature of FT; the enterprise that TRA Inc. is in. This particular approach, called the Transaction-Oriented Architecture is outlined by Polovina (2013) but the arguments presented can apply equally in any metamodel e.g. TOGAF (as already discussed) or, as another example, LEADing Practice (www.leadingpractice.com) that has developed on from TOGAF, Zachman and others.
- Polovina and Andrews (2013) describes the transformation from a CG (Conceptual Graph) that includes Peirce’s cuts thus the business rules into the ‘simple’ form shown above. For our purposes it puts the model into a logical level form that can be checked at the mathematical level using CGtoFCA.
- Through CGtoFCA and the accompanying software the above FCA lattice is produced from the CGs model, the ‘FT Transaction Graph’. From the lattice for the FT case study we can observe the following: The identification of FT_Transaction object as the overarching superconcept at the top of the lattice with the flow down through the lattice in line with the direction of relational arrows that link the concepts by their relations in the FT Transaction CGs Graph. There is no object identified with the bottommost concept that we need to investigate further, as we did with the Sheffield Hallam University example The flow down from the Transaction object aligns with the FT Transaction Graph. For example Transaction flows along the Transaction_part attribute to the objects Message, Cash_Movement and Order. The TAV concept can be identified in the lattice as one of the central objects with its extents in line with the FT Transaction Graph, namely Platinum_Portfolio market_value, Gold_Portfolio market_value, Regular_Portfolio market value, Position sum, and Portfolio market_value. There is no explicit relationship that points between ‘inside’ agent (Issuer or Restricted_Issuer) in this transaction to Investment_Firm: TRA_Inc., which again we will need to investigate further as it too points to a disharmony between strategy and structure. From the lattice for the FT case study we can observe that as Andrews & Polovina (2011) also demonstrated using another case study (‘P-H University’), the lattice has revealed that there ought to be a flow from an uppermost Transaction object and culminating in TRA_Inc. as the bottommost object (for examples based on the Transaction-Oriented Architecture mentioned earlier as it’s version of “from a blank piece of paper to the last nail in the wall” architectural principle). Interestingly, the FT_Transaction definition target attribute is the Transaction object, thus as we are describing an FT_Transaction that is correctly shown as the topmost object with Transaction below it through the FT_Transaction definition attribute. Portfolio is however also topmost, when it part of the transaction. It suggests that there is a missing downward CG relationship from Transaction to Portfolio. The bottommost concept lacks its own object, namely Investment Firm: TRA_Inc. As it is this enterprise’s transaction, the intent of this object should be all the attributes in the lattice. Going the other way, the extent of FT_Transaction definition are all the objects in the lattice including TRA_Inc. It is what defines the transaction. Therefore just like the simple university case study exemplar of Andrews and Polovina (2011) we need to refine the FT Transaction Graph so that the CGs arcs (the arrows connecting CG concepts through relations) cascade down from FT_Transaction to TRA_Inc. The automatically generated mathematical level model (the FT Lattice) alerts the human modeller (e.g. the Enterprise Architect) to consider how (s)he and the enterprise could update the logical level model (in our case using CGs). The productivity of computers and creativity of humans thus work in harmony, hence conceptual structures.
- The result of these human updates to the model are shown above, as the human modeller (e.g. the Enterprise Architect) returns to the logical level model to make them so. However to make the arrows point in the right direction, use was made of ‘..._of’ relations, which read as 'source concept is relation_of target concept' e.g. Portfolio_Manager is manager_of Portfolio. In a conventional reading of a CG in its notation, we follow the pattern ‘the relation of a concept is a concept’ e.g. “The manager of a portfolio is a portfolio manager” (Polovina, 2007) . Though this reading pattern was not used in the Sheffield Hallam University example, the FT example does. The benefits and issues of these alternatives are discussed elsewhere (Polovina and Andrews, 2013). We can nonetheless state that semantically, the direction of the arrows from top to bottom is the overarching theme in that for FT_Transaction the CG concepts are pointed to TRA_Inc. In FCA terms the intent of TRA_Inc. are all the attributes of the transaction that describe the FT_Transaction and why those attributes are core to it. The extent of the FT_Transaction is the constituent objects that together make up that transaction. Thus the naming of the relations should conform to the overall, downward flow. The arrow direction thereby defines these names; hence it is valid to use the ‘..._of’ relations. Without FCA this would not have been highlighted. The Transaction Graph is thus updated by adding 8 new '..._of' relations as shown above.
- The lattice reveals that Investment_Firm: TRA_Inc. is still not at the bottommost concept. Why? Even within the modified Transaction Graph the arrows are still not all pointing collectively in the downward direction. From the lattice it is easy to identify that the culprit is Trade_Date as this is not in TRA_Inc.'s extent. As we have seen, the arrow direction in CGs is rather informal, relying on the names of the relations to give a sense of this direction. Indeed it is easily possible to mix up the direction even in introductory CGs as one paper’s typos in its CGs will reveal on a careful examination (Polovina, 2007). FCA eradicates this issue; the focus is on the direction and the concepts, and informs the names of the relations.
- Back at the logical level, two changes were made to the Transaction Graph. The first one, changing the ‘less_than’ relation name to ‘greater_than’ was relatively straightforward (and had the interesting side-effect of pondering over if one should use less_than or greater_than; FCA immediately took care of that). The other was harder in that the characteristic relation looked as if it had to be ‘fabricated’ just to fit the model; that relation demands that the arrows point in its original direction especially as Creation_Date is a characteristic of Portfolio that is being described! However, following the principle of using ‘..._to’ relations and as a reminder that the simple naming of relations was secondary to the concepts and the directions of the arcs, the relation was renamed 'characteristic_to' accordingly. The semantics were thus preserved. The relation could be better named by, say, 'is_characterised_by'. The TOGAF metamodel in fact uses such terminology, where relations are instead described by arcs (lines) between entities going in both directions e.g. Actor accesses a Function / Function is accessed by an Actor (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html#tagfcjh_64 in chapter “34. Content Metamodel”). Pertinent is that the direction of the object relations guide how we name the relations; in semiotic terms the referent (the object) thus conveys the correct sign (by its name) to the interpretant (e.g. the Enterprise Architect) rather than relying on a relatively arbitrary synthesis of the names with its consequent misinterpretations (Sowa, 2000, pp.394-402). Indeed, we have seen illustrations of such happenings in our Sheffield Hallam and FT examples.
- The resulting lattice, demonstrating that the identified issues are now resolved. This of course is not necessarily the end point; rather it represents a solidly, mathematically-validated foundation upon which further interpretations and iterations of the models can be made as the enterprise goes forward.
- The Concluding Remarks, reflecting what has been covered and that by aligning the conceptual, logical and mathematical levels of the metamodels, constructive relationships can be made between concepts and structures. As such, structures support rather than hinder the human creativity that enables enterprises to better reach their goals.
- Andrews, S.; Polovina, S (2011) "A Mapping from Conceptual Graphs to Formal Concept Analysis“, Conceptual Structures for Discovering Knowledge, Lecture Notes in Computer Science, Vol. 6828 (Subseries: Lecture Notes in Artificial Intelligence), Springer, 63-76. Box, G. (1987, p.424) In: Box, .G. & Draper, N.R. (1987) Empirical Model-Building and Response Surfaces, Wiley Series in Probability and Statistics Hitzler, P.; Scharfe. H. (2009) Conceptual Structures in Practice, CRC Press Malik, N. (2009) Why the Zachman Framework is not an ontology, http://blogs.msdn.com/b/nickmalik/archive/2009/12/18/why-the-zachman-framework-is-not-an-ontology.aspx Polovina, S.; Andrews, S. (2013) "CGs to FCA Including Peirce's Cuts", International Journal of Conceptual Structures and Smart Applications (IJCSSA), 1(1), IGI-Global Publishing, 90-103. Polovina, S. (2013) "A Transaction-Oriented Architecture for Enterprise Systems, IJIIT, October-December 2013, Vol. 9, No. 4, pp.69-79 Polovina, S. (2007) "An Introduction to Conceptual Graphs", Conceptual Structures: Knowledge Architectures for Smart Applications, Lecture Notes in Artificial Intelligence (LNAI 4604), Springer, 1-15 Sessions, R. (2007) A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx Sowa, J. F. (2000) Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks/Cole Sowa, J. F. (2002) Representing Knowledge Soup in Language and Logic, http://www.jfsowa.com/talks/souprepr.htm Sowa, J. F. & Zachman, J. A. (1992) Extending and formalizing the framework for information systems architecture, IBM Systems Journal 31(3), 590-616. TOGAF (2011) TOGAF® 9.1, http://pubs.opengroup.org/architecture/togaf9-doc/arch/ Zachman, J.A. (1987) A Framework for Information Systems Architecture, IBM Systems Journal, 26(3), 276-292