extension mechanism for integrating new technology elements into viewpoint based enterprise...
DESCRIPTION
It's about integrating mobile, cloud, and social networking into RM-ODP (experimental).TRANSCRIPT
Extension Mechanism for Integra3ng New Technology Elements into
Viewpoint based Enterprise Architecture Framework
Akira Tanaka, view5 LLC
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
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.
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.
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
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
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
SOFTWARE MODELING
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.
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
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
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).
UML Package Merge (merged package)
(receiving package) (resul3ng package)
NOTE: Research Paper – “Modeling UML 2 Package Merge with Alloy”
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
UML Profile Standard examples
Source OMG : hop://www.omg.org/spec/
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
Integra3ng UML Profiles • Since UML Profile is represented as a package with stereotype
«profile», package merge can also be applied (in theory).
ENTERPRISE ARCHITECTURE
DoDAF
RM-‐ODP
Reference Model for Open Distributed Processing
• RM-‐ODP defines founda3onal concepts, viewpoint languages, correspondences etc.
RM-‐ODP Meta-‐Model
NOTE: Par3al diagram from standard’s working model
RM-‐ODP Profile
NOTE: Par3al profile data
EXAMPLE NEW TECHNOLOGIES
Social Netw
orking
NoSQL
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
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
Mobile & Cloud extensions
i.e. all other concepts are s3ll available for mobile and cloud system specifica3ons.
Par3al enterprise language
means e.g.
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
Social Network extension
means e.g.
Par3al enterprise language
UML Profile Integra3on
• Mobile and Cloud – By modifying exis3ng UML Profile for RM-‐ODP
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.
Sample Diagram Fragment Enterprise Viewpoint
Sample Diagram Fragment Informa3on Viewpoint
«merge»
Cloud-‐aware and social-‐aware object types can be added to exis3ng informa3on model.
Sample Diagram Fragment Computa3onal Viewpoint
Mobile-‐aware objects and cloud-‐aware object can be added to exis3ng model (needs re-‐wiring etc.)
Sample Diagram Fragment Engineering Viewpoint
Cloud-‐aware channel can be introduced to exis3ng engineering model.
Sample Diagram Fragment Technology Viewpoint
Mobile Object/Phone can be added to exis3ng model
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).
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).
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
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.
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.
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.