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

Compliance in service-oriented architectures: A model-driven and

view-based approach

Uwe ZdunSoftware Architecture Group

Department of Distributed and Multimedia SystemsUniversity of Vienna

http://cs.univie.ac.at/swa

2 software architecture group

COMPLIANCE: THE PROBLEM DOMAIN


IT Compliance

IT compliance means in general complying to regulations that apply to an IT systemExamples of regulations are: Basel II, IFRS, MiFID, Cobit, LSF, Tabaksblat, Sarbanes-Oxley ActThese cover issues such as auditor independence, corporate governance, and enhanced financial disclosure


Other Compliance Sources

Regulations are just one exampleThere are many other rules and constraints in a software system that have similar characteristics

Service composition/Deployment rulesService execution order rulesInformation exchange policiesSecurity policiesQoS rulesBusiness rulesLawsLicenses


Current Practice for Dealing with Compliance

Ideal case: A SW-framework for automatically dealing with complianceProblem: It is impossible to formalize all details of a jurisdictional text

Interpretation by domain experts neededComplex references to other (jurisdictional) texts

Hence, in many cases, compliance today is reached on a per-case basis


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 regulationsIt is difficult to keep up with constant changes in regulations and lawsDomain experts are not involved enough

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


OUR APPROACH

Approach Overview

Models and meta-models for the specification of the SOA and compliance concerns

Domain-specific languages (DSLs) and architectural views for compliance concerns

Model-driven validation and generation of the SOA from the models

Execution, monitoring, and enforcement of compliance concerns in the running SOA

Approach: Auditor’s View

Regulation /Legislation

Norm/Standard

Controls

Automated Controls Report Manual

ControlsManual

Implementation

Risk Management Department

Regulation /Legislation

Norm/Standard

Controls

Automated Controls Report Manual

Controls

View-based, model-driven

Approach

GeneratedImplementation

Risk Management Department

Approach: Auditor’s View


Architectural Overview

MDSD Software

Framework

Repositories

Application Servers,ESB Online Monitoring

Offline Monitoring

Dashboard

Data Warehouse

Verification Tools

Compliance Request

Language

Design time

Runtime


Compliance Solution: Overview & Roles


View-based, Model-driven Architecture

Separation of concerns using architectural views Separate different concerns in view-based modelsSeparation of abstraction levels: Separate technical and domain-oriented views

Integrate via model relations and matching algorithms using the model-driven generator

View-based Modeling Framework (VbMF)


Separation of concerns


Separation of technicaland domain-orientedviews

Extended VbMF: Modelling and Integration of Compliance Concerns

Core Model

Flow View Model

CollaborationView Model

InformationView Model

Intellectual property and license

DSL

extends extends extends

BPELFLow View

Model

BPELCollaborationView Model

BPELInformationView Model

extends extends extends

Business Process Modeling

QoS policyDSL

Security policyDSL

Compliance Modeling

annotates

Process-driven model instances with annotated

compliance metadata

instance-of

Schematic RecurrentCode & Configurations

generates

extends

Regulatory or legislative

DSL

Compliance Metadata Model

annotates

Documentation

generates

Domain-Specific Languages Tooling: High-level and low-level DSLs

Business/Domain experts

IT/Technicalexperts

DSL – An Example

High-Level DSL - Editor

Low-Level DSL

Compliance Metadata-Model

A bridge between compliance concerns and SOA elementsCompliance 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 controlsThis allows us to specify statements like:

“Service/Process X is a change management control, defined in COBIT, to comply with SOX”

Model-Driven Tool Chain

TransformationTemplates


Execution and Monitoring

Process engine

Service monitors

Other IT event detector

Event Bus

Governance of Compliance

AuditTrail

Event Model

Dashboard


Compliance Governance Dashboard


EXAMPLE


An Example of Process Design


Searching for process fragments realizing SOX 409 concerns using the Compliance Request Language

Query

Models


No suitable fragments are found. We model the concern using the MDD framework

Models

Generated Code

Verified Models

Generated CodeGenerated CodeGenerated Code


Monitor The Process at Runtime

EventsEvents

Display Information

Display Information


Analyze compliance violation: Perform root cause analysis using the models from the model repository

Models

ComplianceViolation


Root cause analysis and process redesign in detail

Before: sequential task execution; slow, lots of violations

MORSE RepositoryUUID 1

formID = „Form8K“duration = 2unit = BusinessDays...

: PublishDeadline

UUID 5

Business process engine

1. Deploy process models

Monitoring Infrastructure

2. Emit events UUID 3UUID 2UUID 1

3. Get compliance models (rules) for process

4. Process and

analyze events

UUID 1

Violationdetected

5. Retrieve responsible / corresponding models

ID = „Sec 409 Real time issuer disclosures“...

: ComplianceConcern

UUID 4

Compliance governance

Web UI

6. Report violation

7. Root cause analysis / manipulation of model(s)

Assess Intrusion End

yes

no

Personal info lost or stolen?

Response Write Form 8-K

Approve Form 8-K

Publish Form 8-K

!UUID 3

UUID 2

UUID 4

UUID 5

Assess Intrusion End

yes

no

Personal info lost or stolen?

Response

Write Form 8-K

Approve Form 8-K

Intrusion detected

Publish Form 8-K!After: parallel task execution; faster, fewer violations

UUID 1


Lessons Learned

On The nature of business compliance in a SOA systemScattered through many system’s elements at different abstraction levelsExisting 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 abstractionTaking into account for the constant needs for changes of laws regulations, policies, etc., to ensure incremental complianceEngaging relevant stakeholders (business/domain experts, technical experts) by providing appropriate tooling and methods


Many thanks for your attention!

Uwe Zdun

Software Architecture GroupDepartment of Distributed and Multimedia SystemsUniversity of Viennahttp://cs.univie.ac.at/swa

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

Documents

compliance metadatamodel

compliance problem

guaranteed compliance

various compliance concerns

modeldriven approach

compliance sources regulations

model relations

compliance ideal case