extension mechanism for integrating new technology elements into viewpoint based enterprise...

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.