Extension Mechanism for Integrating New Technology Elements into Viewpoint based Enterprise Architecture Framework
2 likes1,567 views
The document discusses an extension mechanism for integrating new technology elements into viewpoint-based enterprise architecture frameworks. It proposes using meta-modeling and profiling with package merge to create flexible enterprise architectures that can easily integrate new technologies as they emerge. Key points include developing meta-models for the enterprise architecture framework (RM-ODP) and new technologies, and using model transformations to integrate overlapping concepts between the meta-models in a way that maintains consistency.
![Meta-‐models
• Meta-‐model
is
a
model,
[for
specific
domain,]
[consis/ng
of
iden/fied
concepts,
rela/onships
among
them,
and
constraints
on
them,]
for
defining
models
[of
that
domain].
– E.g.
UML
specifica3on
includes
meta-‐model
of
UML
itself,
expressed
using
subset
of
UML
Class
Diagram.
• In
our
work,
we
needed
meta-‐models
for
RM-‐ODP
and
for
New
Technologies
– RM-‐ODP’s
meta-‐model
is
in
RM-‐ODP
standard.
– Searched
exis3ng
work
and
developed
simple
Meta-‐models
for
example
technologies.](https://image.slidesharecdn.com/modelingeawithnewtechnologies-130902104045-phpapp02/85/Extension-Mechanism-for-Integrating-New-Technology-Elements-into-Viewpoint-based-Enterprise-Architecture-Framework-9-320.jpg)
Extension Mechanism for Integrating New Technology Elements into Viewpoint based Enterprise Architecture Framework
- 1. Extension Mechanism for Integra3ng New Technology Elements into Viewpoint based Enterprise Architecture Framework Akira Tanaka, view5 LLC
- 2. Agenda • Background (context and issues) – Modeling SoJware – Enterprise Architecture – New technologies • Flexible Enterprise Architecture against new technologies – Proposed Mechanism: Meta-‐modeling and Profiling with Package Merge – Use Cases • Discussion • Conclusion
- 3. Background (1 of 3) • Architecture for SoJware Systems – Iden3fies components, their behavior, and rela3onships among them for specific domain • Examples: MVC, Client/Server, Three Tier, SOA … • Enterprise Architecture – Architecture for Enterprise Compu3ng Systems • Combina3on of business and IT architectures for business execu3ons • Examples: Zachman, TOGAF, FEA, DoDAF, MODAF, and RM-‐ODP – A way of organizing system specifica3ons from mul3ple viewpoints or perspec3ves, some3mes used to contrast as-‐is and to-‐be specifica3ons and develop to-‐be system from as-‐is system – Issues: • Enterprise Compu3ng Systems (instances) evolve over 3me to become more and more complex and difficult to understand. • A gap between architecture and its implementa3on widens unless there is an effort for synchroniza3on in place.
- 4. Background (2 of 3) • New Technologies – May arrive at any moment • Hard to predict what comes and when it comes – May have impact upon enterprise • Organiza3on structure, informa3on structure, human behavior, and IT pla_orms • System management and Security aspects – Examples • Mobile Compu3ng (Smart Phone and Tablet) • Social Networking • Cloud Compu3ng • NoSQL • E-‐Books • Big Data • E-‐health (new external domain) … etc.
- 5. Background (3 of 3) • SoJware Modeling – Raising the level of abstrac3ons by suppressing unnecessary details • Programming Languages: – Machine language -‐> Assembler, C, C++, LISP, COBOL, Pascal, Smalltalk, Java, JavaScript, Ruby, … • Libraries, Components, Frameworks, … • SoJware Modeling – Modeling “SoJware” • Formal Specifica3ons (preciseness) and Valida3ons • Model Driven SoJware Development/Engineering – MOF, UML(Class, Ac3vity, etc.), BPMN, … – Model Transforma3ons and Code Genera3on – Issues • Choosing appropriate or suitable level of abstrac3on • Synchroniza3on between model and code
- 6. Problem Statements and Proposed Approach • For “enterprise compu3ng” domain, there is no widely accepted way for developing flexible or “designed/ready-‐for-‐change” enterprise systems. – Addi3ons of new technology elements should not be a problem. It should also enable smooth migra3on. • Proposed approach: Use Modeling and Enterprise Architecture – Design and develop at higher level of abstrac3on • Make best use of Modeling technologies including UML and its extension mechanism • Make Models flexible and easy to integrate • Choose/Use enterprise applica3on framework to achieve/keep consistency
- 7. Choices made for this work • Choice of Modeling Language – UML is the most widely used modeling language and interna3onal standard • MOF: A subset of UML Class Diagram is used as nota3on. • Others: Graphical/Textual DSLs, Tool specific nota3ons, etc. • Choice of Enterprise Architecture Framework – RM-‐ODP is, at this moment, the only open one (standard specifica3ons and UML Profile are freely available on-‐line) • Zachman Framework: Not open • TOGAF: Semi open (consor3um backed) • FEA, DoDAF, and MODAF: Openly published but government owned • Choice of example technologies for discussion – Mobile Compu3ng, Cloud Compu3ng, and Social Networking
- 9. Meta-‐models • Meta-‐model is a model, [for specific domain,] [consis/ng of iden/fied concepts, rela/onships among them, and constraints on them,] for defining models [of that domain]. – E.g. UML specifica3on includes meta-‐model of UML itself, expressed using subset of UML Class Diagram. • In our work, we needed meta-‐models for RM-‐ODP and for New Technologies – RM-‐ODP’s meta-‐model is in RM-‐ODP standard. – Searched exis3ng work and developed simple Meta-‐models for example technologies.
- 10. Layers of Models Meta-‐meta model Metamodel Model Instance or Object Model Instance of conform to conform to MOF (CMOF, EMOF/ecore) e.g. UML, SOA, BPMN, … e.g. UML models, SOA models, BPMN models, … M3 M2 M1 M0
- 11. Meta-‐models (in general) Enterprise Architecture Domain Meta-‐Models for Technologies type #1 Meta-‐models for Enterprise Architecture Type #1: Completely independent of Enterprise Architecture Type #2: With some overlap with Enterprise Architecture Type #3: Specializing a part of Enterprise Architecture Overlapping meta-‐models Meta-‐Models for Technologies type #2 Meta-‐Models for Technologies type #3 UML
- 12. Integra3ng Meta-‐models • At the highest level, package merge is used to achieve the flexible extensions (used in UML specifica3on to define UML Meta-‐model).
- 13. UML Package Merge (merged package) (receiving package) (resul3ng package) NOTE: Research Paper – “Modeling UML 2 Package Merge with Alloy”
- 14. UML Profile • Standard Extension mechanism for UML – Many UML Profile standards exist today • Workflow for developing and using UML Profile – Define Meta-‐model for target domain – Define mapping of meta-‐model elements onto UML by extending meta-‐classes and by defining stereotypes, tag-‐defini3ons, and constraints – Implement UML Profile (stereotypes and others) within your UML tool – Create UML models and apply defined UML Profile • UML Profile for – RM-‐ODP: exists as a standard – New Technologies: can be developed based on their meta-‐models
- 15. UML Profile Standard examples Source OMG : hop://www.omg.org/spec/
- 16. UML and UML Profiles (in general) Enterprise Architecture Domain UML Profiles for Technologies type #1 UML Profiles for Enterprise Architecture Type #1: Completely independent of Enterprise Architecture Type #2: With some overlap with Enterprise Architecture Type #3: Specializing a part of Enterprise Architecture Overlapping UML Profiles UML Profiles for Technologies type #2 UML Profiles for Technologies type #3
- 17. Integra3ng UML Profiles • Since UML Profile is represented as a package with stereotype «profile», package merge can also be applied (in theory).
- 19. Reference Model for Open Distributed Processing • RM-‐ODP defines founda3onal concepts, viewpoint languages, correspondences etc.
- 20. RM-‐ODP Meta-‐Model NOTE: Par3al diagram from standard’s working model
- 21. RM-‐ODP Profile NOTE: Par3al profile data
- 22. EXAMPLE NEW TECHNOLOGIES Social Networking NoSQL
- 23. Mobile Compu3ng Meta-‐Model Class Node «stereotype» Place Device Execu3onEnvironment Associa3on «stereotype» NodeLoca3on Dependency Deployment DeploymentTarget «stereotype» AllowedDeployment «stereotype» CurrentDeployment 1 +loca3on +loca3on Node «stereotype» Place +loca3on +nestedNode +nestedNode +nestedNode A UML Profile to Model Mobile Systems V. Grassi, R. Mirandola, A. Sabeoa «UML» 2004 – The Unified Modeling Language Source: UML Meta-‐model element Introduced element
- 24. NIST’s Cloud Taxonomy hop://collaborate.nist.gov/twiki-‐cloud-‐compu3ng/pub/CloudCompu3ng/ReferenceArchitectureTaxonomy/RA_Cloud_Taxonomy_Version_1.pdf Source (also a part of NIST Cloud Compu3ng Reference Architecture): Important aspects from cloud consumer’s point of view
- 25. Mobile & Cloud extensions i.e. all other concepts are s3ll available for mobile and cloud system specifica3ons. Par3al enterprise language means e.g.
- 26. Social Network Meta-‐Model Simplified version of Facebook meta-‐model published on the web (hop:// commons.wikimedia.org/wiki/ File:Metamodel_of_Facebook.jpg) Source: “Represen3ng Social Structures in UML,” by H. Van Dyke Parunak and James J. Odell
- 27. Social Network extension means e.g. Par3al enterprise language
- 28. UML Profile Integra3on • Mobile and Cloud – By modifying exis3ng UML Profile for RM-‐ODP
- 29. UML Profile Integra3on • Social Networking – By modifying exis3ng UML Profile for RM-‐ODP Rela3vely small number of modifica3ons is due to the fact that RM-‐ODP, one of Enterprise Architecture Framework, has already captured some core concepts even applicable for new technologies.
- 30. Sample Diagram Fragment Enterprise Viewpoint
- 31. Sample Diagram Fragment Informa3on Viewpoint «merge» Cloud-‐aware and social-‐aware object types can be added to exis3ng informa3on model.
- 32. Sample Diagram Fragment Computa3onal Viewpoint Mobile-‐aware objects and cloud-‐aware object can be added to exis3ng model (needs re-‐wiring etc.)
- 33. Sample Diagram Fragment Engineering Viewpoint Cloud-‐aware channel can be introduced to exis3ng engineering model.
- 34. Sample Diagram Fragment Technology Viewpoint Mobile Object/ Phone can be added to exis3ng model
- 35. Sample Diagram Fragment Correspondence • Correspondence is to ensure the rela3onship of the elements in two different views. – Examples • Order Processing (Enterprise) should be processed by PurchaseManager on the cloud (Engineering). • GUI_Employee (Engineering) should be supported by MobilePhoneApp (Technology).
- 36. Summary of our proposed Extension Mechanism • Basic steps – Choose the main domain and narrow down by selec3ng usable specifica3ons • Enterprise Architecture -‐> RM-‐ODP (could be other one) – Move to Meta-‐Modeling space, analyze the target domain to capture all the core concepts (e.g. for New Technologies) – Associate those concepts to exis3ng RM-‐ODP concepts (package merge). – Move to UML Profile defini3on space – Modify exis3ng Profile elements to reflect new meta-‐model elements, or add new elements if no relevant profile element existed (package merge).
- 37. Discussion (1 of 3) • What’s the point of having flexible EA? – Enterprise systems are developed to execute day-‐to-‐day opera3ons, and therefore should be very stable. Is proposed mechanism good enough to make this “ready-‐for-‐change”? • Three use cases have shown it is applicable. • More complex cases should be studied in future, especially around conflict resolu3ons. – To plan and execute at higher level of abstrac3on on top of stable founda3on or EA is logical and beneficial to stakeholders. • Especially true for complex systems like enterprise systems – Further work • Conflict resolu3ons at meta-‐model level and at profile level
- 38. Discussion (2 of 3) • Next step? – UML models are not just drawings. They should be used as input to Model Driven SoJware Development (MDSD). • Use of (meta-‐)modeling is – a good prac3ce, if it helps increase stability, flexibility and produc3vity. – an overhead, if output is not effec3vely used/consumed • Model-‐based Enterprise Architecture – Processing models • Structural aspect of system specifica3ons can be transformed into code with model-‐to-‐text transforma3on template and engine. • Behavioral aspect of system specifica3ons are not ready for model transforma3on into code. Ac3vity-‐based models (e.g. Ac3vity and BPMN) do not standardize ac3ons and their granularity (Further work). – Prac3cal tools for UML modeling and model processing • Open source tools such as eclipse Papyrus, EMF, GMF, Acceleo, and Xtext/Xtend may have a place in the tool chain.
- 39. Discussion (3 of 3) • Interoperability among Enterprise Architecture Frameworks – The explained mechanism is applicable to other EA Framework, provided that • they have good documenta3on (for understanding) • they have Meta-‐Model (preferably published one) • they have UML Profile (can be defined based on above) – Even done so, interoperability requires common language, otherwise more than necessary transforma3ons will be needed. – As of today, RM-‐ODP is well suited as common language, since it is a standard, document is published, and meta-‐model and UML Profile data are also published for other framework players to use. – Further work • Discussion with open source enterprise architecture tools, e.g. Essen3al, may be the next step for common language.
- 40. Conclusion • The three example use cases have shown that proposed mechanism is applicable to enterprise compu3ng domain. – Meta-‐modeling and UML Profiling is a good tool for architectural modeling. – Integra3on should be done with Package Merge, which will help future automa3on. • Meta-‐models and UML Profiles can be selec3vely used like library. Real tool support is expected. – Output UML model should be used as an input to MDSD process. – Behavioral modeling based on Ac3vity or Business Process is important and for further study. – Tooling is important and integra3on of open source tools is promising toward this direc3on. – This proposed mechanism could be applied to other domain than enterprise compu3ng.