Architecture Ecosystem Foundation (AEF) RFP

1. Architecture Ecosystem Foundation (AEF) RFP aesig/10-05-01 Draft RFP Presentation June 2010

2. Presentation Goals • Describe the status of the Architecture Ecosystem Foundation RFP • Introduce the problem statement and value proposition • Summarize requirements for addressing the problem statement • Show that the result is achievable • Work to be done

3. Architecture Ecosystem Foundation (AEF) RFP Status • Substantial discussions within the Architecture Ecosystem SIG have identified the need for an improved foundation for modeling • one that better enables a “whole systems perspective” (but this term is still under discussion) based on models, from multiple sources, representing multiple perspectives and defined in multiple languages • This is the first public draft and discussion of the RFP for an “Architecture Ecosystem Foundation” which we propose be issued by ADTF • Given community refinement and consensus this RFP could be issued at the Cambridge Meeting • Discussion takes place on the architecture-ecosystem mail list, the wiki (http://www.omgwiki.org/architecture-ecosystem/) and the AESIG meeting Thursday AM

4. Summary Of Objectives • The full value of modeling and architecture is achieved by understanding and defining systems from many perspectives • We call this the “whole systems perspective”, also called “macro modeling” • “Systems” are inclusive of the enterprise, business architectures, information systems architectures, software, processes, rules, services and information. • Systems are not insular, they are composed of and interact with other systems • Today's models typically represent one perspective of one system and are difficult to combine with other perspectives so the whole system of systems can be understood • These different perspectives come from different stakeholders using different tools and different languages – but they all talk about the same systems and express overlapping information • Our objective is to enable the whole systems perspective using model and language integration expressed using multiple viewpoints • This must be done in an open environment that can leverage a broad community

5. Semantically Federating Multiple Viewpoints and Standards

6. Problem Statements • OMG “Meta muddle” problem • Multiple redundant and unconnected standards that redefine rather than reuse concepts, creating meta-stovepipes • A tendency for each stovepipe to grow to cover everything • Difficulty for users to make connections between models in different OMG and non-OMG languages • UML Futures RFI that called for an improved capability to express UML and connect it with other languages with support for viewpoints • Business architecture white paper – identified a need for connecting business and technical viewpoints • UPDM – had difficulty in integrating OMG languages (some MOF, some UML profiles) for their needs • Weak semantics in language definition • Inability to achieve greater value - to support an evolution in architecture where whole systems are modeled from multiple, interconnected and mutually supportive viewpoints. Viewpoints are dynamically defined by architects to tailor the modeling capability to their needs.

7. The Model Integration Problem • The enterprise typically has many models for different parts of the enterprise expressing different areas of concern • While the concerns may be different, the concepts being modeled are cross-cutting • Stakeholders need to be able share model information with others, who may have different concerns and perspectives, to make better business and technical decisions • We need to be able to connect and reason about independently conceived models so that elements and relations can cross those models regardless of source, perspective or language • To do this we need to “connect the dots” between models • Example: A process in BPMN may satisfy a requirement in BMM

8. The Language Integration Problem • Languages are a means of expressing and communicating views • Languages are inclusive of textual and diagrammatic representations of information • Different languages express overlapping concepts and concerns in different ways that are difficult to connect • By better understanding the common semantics of languages we can better understand the common elements of models • We need better capabilities to express the semantic relationships between languages and the common semantics of languages • Information about a system should be able to be projected onto multiple languages (textual or graphical), as is suited for a particular purpose • This will simplify our set of languages as well as support the definition of whole systems perspectives that utilize multiple languages • Example: A service defined in SoaML may be implemented by a BPMN process and transfer data defined in OWL. These elements should be able to be used as if they were defined in the “local” language

9. The Need for Viewpoints • While we want to understand the whole system, we need to enable stakeholders to see it in their terms • Viewpoints provide a lens into the whole system tuned to the needs of particular stakeholders • Viewpoints combine particular parts of the system model and using particular languages to create views of the system suitable for a stakeholder • Viewpoints may subset the information in the whole system, may specialize vocabulary and use specific notations and syntaxes • Viewpoint separation: Separating different aspects of a system • Viewpoint integration: Integrating consistent aspects of a system • Note: viewpoints and the need for them need to be clarified. • Example: A security viewpoint deals with roles, processes, data and rights using particular diagrams and tables

10. The Need for Semantics • In current meta-models semantics is mixed with syntax and often poorly defined, yet over specified • The same and related concepts are re-invented without any connection between them • Semantics grounds the languages in what they mean • We have a need for a better semantics foundation to represent the concepts we are modeling (in use models and in languages) • Semantic models need to be able to be layered and modular, not requiring a “universal model” • While we want to enable a semantic foundation, not all language concepts should have to be semantically grounded • Example: The concept of classification by types is almost universal, yet UML classifier has no relation to the well defined concept outside of UML that may be similar but different

11. Notional Architecture Viewpoint Viewpoint Viewpoint BPMN Notations (Languages) BPMN Languages UML Notations (Languages) UML Languages Other Languages Other Viewpoints Terminology, Structure & Notation Projection Projection Mapping Projection Grounding Modular & Layered Semantic Models Shared & Linking Concepts Grounding Grounding Language Definition & Linking Language (UML+)

12. Requirements (1-4) • [Core Semantic Model] The ecosystem foundation shall specify or utilize an abstract syntax and formal semantics for those concepts required to define, federate and integrate multiple languages and models in multiple languages in support of federated domain models that utilize multiple languages. The choice of approach and/or logic for specifying semantics shall be explicit. Languages in this context shall include modeling languages, business architecture languages, software development languages and logical languages. • [Concept Relationships] The ecosystem foundation abstract syntax and semantics shall include capabilities to semantically relate identical and similar concepts that have been independently conceived and represented in the same or different models using the same or different languages. This shall include differences in name, structure, representation, property sets and underlying theories. • [Relationship to MOF] The concepts defined for the ecosystem foundation (6.5.1) shall be a superset of the concepts defined in MOF unless specific justification can be made for retiring a MOF concept or meeting the same requirements in some other way. • [Reusable and Layered Modules] The ecosystem foundation shall provide for reusable and layered model specification modules and the semantics and mechanisms for defining the relationships between these modules. The ecosystem foundation must support modules that are overlapping and/or conflicting as well as modules representing modeling capabilities that can be combined to form a consistent theory. Model specification modules must be usable for the specification of languages and may be usable for the specification of domain models.

13. Requirements (5-8) • [Core Shall Define Reusable Modules] The concepts that are defined in the abstract syntax and semantics for the ecosystem foundation (6.5.1) shall be defined using reusable language specification modules. Reusability of these modules for other purposes will be a factor in evaluating the quality of the approach but proof of generality will not be required. • [Exchange Syntax] The ecosystem foundation shall define or utilize a distinguished concrete syntax for the exchange of models and model fragments that are instances of the foundation abstract syntax and formal semantics. If different from OMG-XMI a lossless transform shall be specified between OMG-XMI and the ecosystem exchange format. • [Language for Language Definition] The ecosystem foundation shall define one or more concrete syntaxes that represent the user viewpoint for specifying and integrating languages. One of these concrete syntaxes shall be specified as a profile of UML that is a superset of the subset of UML that is currently used to specify OMG languages • [Language for Model Linking] The ecosystem foundation shall define one or more concrete syntaxes that represent the user viewpoint for integrating and federating user domain models with semantic relationships. This viewpoint shall support the integration and federation of arbitrary models expressed in ecosystem languages

14. Requirements (9-11) • [Projection] The ecosystem shall support the projection of models defined using the ecosystem abstract syntax and semantics to syntaxes that may or may not have been defined within the context of the OMG • [Semantic Grounding] The ecosystem shall support semantic grounding of model concepts but shall not require that all concepts are grounded. Where there are informal but accepted common concepts the ecosystem shall allow utilization of those informal concepts and definitions. Domain models, languages & viewpoints may have their own “private” concepts that have no grounding at all. • [Shared Concepts] The ecosystem shall support the definition and use of well defined representations of shared concepts found in modeling languages (e.g., processes, sub processes, activities, classes, properties, associations, integrity rules, derivation rules, events, exceptions and such) and domain models (e.g., an accounting, marketing or simulation model). It is only required to define shared concepts for concepts that are to be shared as connections between viewpoints may be done through such a shared and well defined concept. Well defined does not necessarily mean FOL or even logic, but the level of precision needed for the domain.

15. Requirements (12-15) • [Viewpoints] The ecosystem shall define and provide for a concept of “viewpoints” where a viewpoint represents a particular configuration of models presented to the user in a particular vocabulary, structure and syntax including but not limited to diagrams and/or text. The ecosystem shall provide for the same information to be related and synchronized across viewpoints that share the same underlying model(s). Viewpoints shall be able to be dynamically created by ecosystem architects by assembling the models appropriate to a category of stakeholders. • [Models as Web Resources] The ecosystem shall provide for modeling concepts and model content to be web addressable resources, have a unique web identity and be dereferenceable based on that identity. • [Query] The ecosystem shall specify or utilize a mechanism to query across a defined set of models or viewpoints [potentially] as web resources. • [Examples] The ecosystem foundation shall be explicitly validated by a representative set of domain models which also are validated by a representative set of examples

16. Definitions • What do we mean by “language”? • We mean structured languages, not natural languages. • Structured languages provide a means to model systems, where systems can be: • An enterprise, an I.T. system, a physical assembly (like an automobile), information, a military unit, etc. • Languages defined by OMG: • UML, BPMN, BMM, SoaML, SysML, SBVR, UPDM… • Structured languages defined externally: • SQL, XSD, OWL, RDF, Common Logic, Java, C#, Cobol… • What is a system? • A system is a set of parts and the relationships between them that, from some perspective, can be treated as or act as a whole • Some systems interact with their environment, others are closed systems • What is a viewpoint? • A viewpoint is a lens on the model(s) relative to a system for a particular stakeholders needs expressed using an appropriate set of languages

17. Next Steps • Review the draft RFP • Refine and resolve issues • Meet Thursday AM to discuss • Ongoing discussion on AESIG mail list • Goal: Issue at next meeting

18. Issues to discuss • Kinds of models • Languages (Meta models) • Generic models (e.g. Patterns) • Domain models (Domain specific part of the “T BOX”) • Instance models (“A BOX”) • Goal: Languages that can range over the union of all kinds of models • “Alignments” as first class models including shared and linking concepts • Implications of the term “whole systems perspective”, may want another term • Define “system” • Reducing RFP size • Are viewpoints additive such that they could be done later? Are viewpoints and languages the same thing? Are viewpoints, languages and models 3 terms for 2 concepts? • Packaging • Closing the world • Must exchange syntax have angle brackets?

19. Use Cases • “Systems Architect” • Define a model and supporting viewpoints • Extend an existing model, and extend or define new viewpoints on that model • Create a new model and viewpoints that integrate, bridge or link to concepts represented by elements of other models and viewpoints • Provide the model and viewpoints to the open Web where they can be exchanged and linked to other information in order to drive business value • Extend and specialize modeling languages for their purpose, making new “domain specific” modeling languages based on existing languages • Make semantic connections between modeling languages that can either constrain or assist the modeling process • “Language & Methodology Designer” • Define language semantics, syntax and notations • Use pre-existing language concepts and specialize them for use in a specific language • Define new language concept modules that may or may not be used in other languages • Make semantic relationships between language concepts • Relate the syntax, vocabulary and notation of a modeling language to pre-existing language definitions or language specific concepts • Relate a language model to pre-existing exchange formats and meta models.

20. Goals • Enable • Model definition and integration • Modeling language definition and integration • Support for viewpoints • Support for an open world • Semantic linking between viewpoints and languages [clarify] • Improved model semantics • Improved Domain & Language Model Modularity • Improved Reuse of Model & Language Concepts • Support for Internet protocols exposing model Information • Integration of Current Models & Languages • A vibrant community! • Provide • A Language Definition & Integration Viewpoint • A Model Integration Viewpoint

21. Optional Requirements • Non normative integration or refactoring of existing OMG languages • Open reference implementation (s) • Test cases