Your SlideShare is downloading. ×
  • Like


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Choose'10: Uwe Zdun - Compliance in service-oriented architectures: A model-driven and view-based approach


Presented at the Choose Forum 2010 in Bern.

Presented at the Choose Forum 2010 in Bern.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Compliance in service-oriented architectures: A model-driven and view-based approach Uwe Zdun Software Architecture Group Department of Distributed and Multimedia Systems University of Vienna
  • 2. COMPLIANCE: THE PROBLEM DOMAIN 2 software architecture group
  • 3. IT Compliance IT compliance means in general complying to regulations that apply to an IT system Examples of regulations are: Basel II, IFRS, MiFID, Cobit, LSF, Tabaksblat, Sarbanes-Oxley Act These cover issues such as auditor independence, corporate governance, and enhanced financial disclosure 3 software architecture group
  • 4. Other Compliance Sources Regulations are just one example There are many other rules and constraints in a software system that have similar characteristics Service composition/Deployment rules Service execution order rules Information exchange policies Security policies QoS rules Business rules Laws Licenses 4 software architecture group
  • 5. Current Practice for Dealing with Compliance Ideal case: A SW-framework for automatically dealing with compliance Problem: It is impossible to formalize all details of a jurisdictional text Interpretation by domain experts needed Complex references to other (jurisdictional) texts Hence, in many cases, compliance today is reached on a per-case basis 5 software architecture group
  • 6. Issues with the Current Practice Systems are hard to maintain hard to evolve or change hard to reuse hard to understand It is difficult to ensure guaranteed compliance to a given set of rules and regulations It is difficult to keep up with constant changes in regulations and laws Domain experts are not involved enough 6 software architecture group
  • 7. Compliance in SOAs So far the SOA approach does not provide any clear technological strategy or concept of how to realize, enforce, or validate various compliance concerns
  • 8. OUR APPROACH 8 software architecture group
  • 9. Approach Overview Execution, monitoring, and Models and enforcement of meta-models for compliance the specification concerns in the of the SOA and running SOA compliance concerns Domain-specific languages (DSLs) and architectural views for compliance concerns Model-driven validation and generation of the SOA from the models
  • 10. Approach: Auditor’s View Regulation / Legislation Risk Management Norm/Standard Department Controls Manual Automated Manual Report Implementation Controls Controls
  • 11. Approach: Auditor’s View Regulation / Legislation Risk Management Norm/Standard Department Controls View-based, model-driven Approach Automated Manual Report Controls Controls Generated Implementation
  • 12. Architectural Overview Design time MDSD Software Framework Compliance Repositories Request Language Verification Tools Dashboard Application Servers, Online Monitoring ESB Data Offline Monitoring Warehouse Runtime 12 software architecture group
  • 13. Compliance Solution: Overview & Roles 13 software architecture group
  • 14. View-based, Model-driven Architecture Separation of concerns using architectural views Separate different concerns in view-based models Separation of abstraction levels: Separate technical and domain-oriented views Integrate via model relations and matching algorithms using the model-driven generator 14 software architecture group
  • 15. View-based Modeling Framework (VbMF)
  • 16. View-based Modeling Framework (VbMF) Separation of concerns
  • 17. View-based Modeling Framework (VbMF) Separation of technical and domain-oriented views
  • 18. Extended VbMF: Modelling and Integration of Compliance Concerns Core Model extends extends extends extends Security policy QoS policy DSL DSL Flow View Collaboration Information Model View Model View Model Intellectual property Regulatory or and license legislative extends extends extends DSL DSL BPEL BPEL BPEL FLow View Collaboration Information Model View Model View Model annotates Compliance instance-of Metadata Model Process-driven model instances with annotated compliance metadata annotates generates generates Schematic Recurrent Code & Configurations Documentation Business Process Modeling Compliance Modeling
  • 19. Domain-Specific Languages Tooling: High-level and low-level DSLs Business/Domain experts IT/Technical experts
  • 20. DSL – An Example High-Level DSL - Editor Low-Level DSL
  • 21. Compliance Metadata-Model A bridge between compliance concerns and SOA elements Compliance metadata model elements: References to regulations, standards, norms, licenses, etc. Controls Referencing Services, Processes, etc. (elements that implement the control) Control type (e.g., change management control) Risks associated to the controls This allows us to specify statements like: “Service/Process X is a change management control, defined in COBIT, to comply with SOX”
  • 22. Model-Driven Tool Chain Transformation Templates
  • 23. Execution and Monitoring Dashboard Governance of Compliance Event Bus Event Audit Process Service Other IT event Model Trail engine monitors detector 23 software architecture group
  • 24. Compliance Governance Dashboard 24 software architecture group
  • 25. EXAMPLE 25 software architecture group
  • 26. An Example of Process Design 26 software architecture group
  • 27. Searching for process fragments realizing SOX 409 concerns using the Compliance Request Language Query Models 27 software architecture group
  • 28. No suitable fragments are found. We model the concern using the MDD framework Models Verified Models Generated Code 28 software architecture group
  • 29. Monitor The Process at Runtime Display Information Events Display Information 29 software architecture group
  • 30. Analyze compliance violation: Perform root cause analysis using the models from the model repository Models Compliance Violation 30 software architecture group
  • 31. Root cause analysis and process redesign in detail MORSE Repository 1. Deploy process models Business 2. Emit events UUID 1 2 UUID UUID 3 UUID 1 process UUID 2 engine ! 4. Process Personal info lost or stolen? UUID 3 UUID 5 and Assess Intrusion Response yes Write Approve Publish End analyze Form 8-K Form 8-K Form 8-K no events Monitoring 3. Get compliance models UUID 1 Infrastructure (rules) for process UUID 4 UUID 5 Violation detected : ComplianceConcern : PublishDeadline ID = „Sec 409 Real time issuer disclosures“ formID = „Form8K“ 5. Retrieve responsible / ... duration = 2 corresponding models unit = BusinessDays ... UUID 4 6. Report violation Compliance governance Web UI UUID 1 7. Root cause analysis / manipulation of model(s) Response Before: sequential task execution; slow, lots of violations Intrusion Personal info detected lost or stolen? Assess yes Write Approve Publish After: parallel task execution; faster, fewer violations ! Intrusion Form 8-K Form 8-K Form 8-K End no 31 software architecture group
  • 32. Lessons Learned On The nature of business compliance in a SOA system Scattered through many system’s elements at different abstraction levels Existing in different development phases: analysis, design, implementation, and runtime Enabling methods and technologies for business compliance in SOAs should Tackling the compliance from multiple perspectives at multiple levels of abstraction Taking into account for the constant needs for changes of laws regulations, policies, etc., to ensure incremental compliance Engaging relevant stakeholders (business/domain experts, technical experts) by providing appropriate tooling and methods 32 software architecture group
  • 33. Many thanks for your attention! Uwe Zdun Software Architecture Group Department of Distributed and Multimedia Systems University of Vienna 33 software architecture group