architecting modern informaiton systems m3 application architecture

Architecting modern information systems

Module 3Application architecture

A. Samarin

Architecting modern information systems - Module 3 2

• Experience shows that business wants separate requests for change to be implemented quickly in existing IT systems

• These changes are typically small (from the point of view of the business) and unpredictable (from the point of view of the IT)

• To carry out these changes easily and in a managed way, business systems must be properly architected / designed / engineered

© A. Samarin 2012

Business context

Architecting modern information systems - Module 3

• Different estimations of the development/maintenance life-cycle cost ratio

© A. Samarin 2012 3

Applications need to be adaptive

2 – Estimated average in the IT industry

maintenance

development 80 %

20 %

2

40 %

60 %

1

95 %

5 %3

3 – A real scenario (governmental client)

1 – Estimated by an IT staff member


• Co-existence of many artefacts– vision, plans, processes,

capabilities, services, etc.• Dynamic and interrelated • Not all relationships between

artefacts are explicit• Not all relationships between

artefacts are interpreted consistently by different staff members and systems


Complexity


• Capturing artefacts and relationships is not sufficient – actionable models are necessary – all artefacts are versionable throughout their life-cycle– all artefacts are evolved to become digital, externalised, virtual

and components of clouds– all relationships between these artefacts are modelled explicitly – all models are made to be executable

• Since many models are designed for people, these models should not be very formal

• Enable changes at the pace of the business


Main architecting principles


• Digital – available in electronic form• Externalized – available as separate entities with proper

definition, naming, versioning, storage, security, traceability, etc. – e.g. transportation of objects between services

• Virtual – available independently of traditional IT resources (servers, databases, media, browsers) as services

• Components of clouds – available somewhere else outside the enterprise

© A. Samarin 2012

Improvement of artefacts


• Reveal all hidden relationships and structure them – examples:– static (in design phase)– dynamic (in execution phase)– composition (from atomic artefacts to a composite artefact)– instantiation (from a template to instances)– compatibility (between different versions)

• If possible, model relationships as formal, explicit, traceable, testable, secure, SLA aware and executable

© A. Samarin 2012

Relationships between artefacts


• Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators)

• Make these relationships explicit and executable

What you model is what you execute

© A. Samarin 2012

Business processes are complex relationships between artefacts


• BPM, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services

• SOA provides recommendationsfor the implementation, execution and governance of services


Synergy between BPM and SOA (1) – structuring relationships


• Each enterprise is a complex, dynamic, unique and “fractal” relationship between services and processes– All processes are services– Some operations of a service can be implemented as a process– A process includes services

in its implementation


Synergy between BPM and SOA (2) – structuring relationships

service process


• An enterprise is a complex, dynamic and self-evolving socio-technical system; one can improve it by:– measuring – observing – deciding – implementing

© A. Samarin 2012

Feedback improvement loop

1

2

3

4

Architecting modern information systems - Module 3© A. Samarin 2012 15

Process-oriented view of an enterprise (before BPM)

Architecting modern information systems - Module 3© A. Samarin 2012 16

Process-oriented view of an enterprise (with BPM)

Architecting modern information systems - Module 3 17© A. Samarin 2012

BPM suite components


• A graphical environment to manipulate with diagrams and other artefacts

© A. Samarin 2012

Process designer / modeller


• Management of process templates and instances by a system administrator

© A. Samarin 2012

Execution engine console (1)


• Access to audit trail of a process instance

© A. Samarin 2012

Execution engine console (2)


• Access to BPM for a « normal user »

© A. Samarin 2012

Worklist (1)


• Business Event Management (BEM) • A business rules engine (BRE) and decision management• Enterprise content management (ECM) system• Collaboration facilities• An Enterprise Service Bus (ESB) to provide a service-

oriented integration layer

© A. Samarin 2012

BPM suite components (optional)


BPM suite components (extended list)


• BEM is capturing of real-time business events and assigning them to proper decision maker

• Event-Driven Architecture (EDA) is a software architecture pattern promoting the production of, detection of, consumption of and reaction to events

© A. Samarin 2012

Business Event Management (BEM)


• A business rules engine separates the business rules from the application code

• This allows the business users to modify the rules whenever

• A business rules engine often uses a business-friendly, but proprietary, language

© A. Samarin 2012

Business rules engine (BRE) and decision management


• BAM refers to the aggregation, analysis and presentation of real-time information about activities inside organisations and involving customers and partners

• BAM is an enterprise solution primarily intended to provide a real-time summary of business activities to operations managers and upper management

© A. Samarin 2012

Business Activity Monitoring (BAM)


• BI refers to technologies, applications, and practices for the collection, integration, analysis, and presentation of business information

• BI systems provide historical, current and predictive views of business operations, most often using data that has been gathered over a long time

© A. Samarin 2012

Business Intelligence (BI)


Process monitoring, BAM and BI


• Access to BPM for a « manager »

© A. Samarin 2012

Dashboard


• ECM comprises the technologies used to capture, manage, store, preserve and deliver content and documents related to organisational processes

• About 70 % of business information is stored in an “unstructured” way (i.e. within documents)

© A. Samarin 2012

Enterprise Content Management (ECM)


• An environment for facilitating inter-service communication

© A. Samarin 2012

Enterprise Service Bus (ESB)


• Situation– some “pieces of work” are

being lost in a chain of applications

– ESB is not enough• Task

– coach how to apply new technologies

• Action– make the business process

explicit– mix BPM, BAM, BEM, CEP

34

Improving a core business application

Primary importance: the result of working together, but not individual exchanges

ESB-centric view: only flow of data

Process-centric view: bothflow of control and flow of data

© A. Samarin 2012


Convergenceg of BPM suites

Source: The Forrester Wave, Q4 2006


• Possible dimentions:– Modelling – Execition– Control– Automation– Measuring– Optimization– Integration between all above– Integration with environment– Product maturity

© A. Samarin 2012

Comparison of BPM suites


• See http://www.teamlog-services.ch/publications/forum-2009-nov-19– Pallas-Athena– E-serve– Aplhinat– IDS Scheer– Intalio

© A. Samarin 2012

Some BPM suites

http://www.teamlog-services.ch/publications/forum-2009-nov-19

http://www.teamlog-services.ch/publications/forum-2009-nov-19


Standards in BPM suites

BPMN

BPEL

XPDL

WSDL, XSD

GUI


• BPEL4People – developed by IBM and SAP

• Web Services Human Task – developed by Adobe, IBM, Oracle, SAP, etc.

• Both are being submitted to OASIS in 2008 for standardisation

© A. Samarin 2012

Human activities


• xForms is an XML application that represents the next generation of forms for the Web

• xForms 1.1 is a candidate recommendation in W3C

© A. Samarin 2012

Graphical User Interface


• AJAX• DHTML• JavaScript

© A. Samarin 2012

Rich User Interface


• XML Schema Definition (XSD)• Formal syntax encoding and structuring of data• XSD 1.0 is a W3C recommendation since 2001

© A. Samarin 2012

Transportation of data


• Web Services Description Language (WSDL)• Formal definition of an interface of a web service• WSDL 2.0 is a W3C recommendation since 2007

© A. Samarin 2012

Definition of services


• Do you use any BPMS?

• Is BPM vendor-centric or customer-centric?

© A. Samarin 2012

Homework 3-1


• Too many BPMS vendors• Every does processes• Standartisation is the war of vendors• No common terminology• No commonly agreed reference model• No good system of standards• No organisation which protects customers of BPM

© A. Samarin 2012

BPM: vendor-centric or customer-centric


• Events• Roles• Data structures• Documents• Rules• Audit trails• KPIs• Processes• Services

© A. Samarin 2012

BPM artifacts

KPIs

Processes Services

Events

Roles Data structures

Documents

Rules

Human “workflow”

Audit trails


• For each artefact– Definition and categories, if any– Naming convention, if any– Attributes– Volume– Security (e.g. ownership)– Life-cycle– Examples

© A. Samarin 2012

Knowledge about artefacts


• Any artefact can be versionable

• Compound artefacts, e.g. process templates

• Templates vs. instances

© A. Samarin 2012

Hidden complexity


• Request for absence– complete a standard HR form with details of the absence

requested – validate the proposed absence with your peers (e.g. those who

need to provide back up for you) – submit the completed form to the direct manager for approval– transfer the completed, approved, form to the HR department for

registration in a time-accounting system – announce the approved absence to a business partner

© A. Samarin 2012

Example process


• A construct that represents a solicited or unsolicited fact indicating a state change in the enterprise or its environment

• Categories– temporal– external– internal– spontaneous

© A. Samarin 2012

Event (1)


• Naming conventions:– <noun> + <verb in past tense> where <noun> is the name of

the dominant business object, e.g. InsuranceRequestReceived– May be “Started” and “Finished” of a process, e.g.

TreatAbsenceRequestStarted and TreatAbsenceRequestFinished• Attributes

• Name• Datetime stamp• Some classifications• Source• Extra (e.g. resources spent)

© A. Samarin 2012

Event (2)


• They are “locked” in database, logfiles, audits, etc.• Example:

© A. Samarin 2012

Capture artefacts – events

Case ID Activity Activity start timeActivity complete time Employee Case type

BZ-06-0501-001Register appeal 24-10-2006 21-11-2006 Person A Schoolbus

BZ-06-0501-001Confirm reception 21-11-2006 09-01-2007 Person A Schoolbus

BZ-06-0501-001

Register receipt of documents 09-01-2007 09-01-2007 Person C Schoolbus

BZ-06-0501-001

Result hearing / Write advice 09-01-2007 09-01-2007 Person C Schoolbus


• Usage– Decoupling of processes– Records management

• Challenges– Extract the events from existing applications

• In our example process– Spontaneous – Result of a routine check by HR

© A. Samarin 2012

Event (3)


• A construct that represents the relevant skills and responsibilities required to perform certain operations

• Follow the Role-Based Access Control (RBAC)

© A. Samarin 2012

Roles (1)


• Possible categories of roles– management – organizational– functional– special expertise– project – security– application

© A. Samarin 2012

Roles (2)


• A word of warning– Groups in LDAP is a tool to implement roles– Composition of clients into roles may be complex– Role assignment can be very dynamic (follows resource life-cycle)– Many tools and people treat “roles” differently

• Watch out for “Separation of duties”– a security principle which has as its primary objective the

prevention of fraud and errors

© A. Samarin 2012

Roles (3)


• Process needs– who may manage a particular process, i.e. who provides

“guidance” and control of its performance – who/what can carry out a particular activity, i.e. have access to a

particular set of resources– the general security of an artefact’s ownership

• Some naming conventions– <unit_name> + “.head”, e.g. “IT.head”– <process_name> + “.manager”– <process_name> + “.” + <activity_name> + “.worker”

© A. Samarin 2012

Roles (4)


• In our example process– the process owner– the requestor– the supervisor– the peers– the HR representative– the HR data owner

© A. Samarin 2012

Roles (5)


Model Automate Execute Control Measure Optimise

Process owner A A A A A

Super-userR A C R R R

User CI CI R I C

Biz analyst R A R C

Architect C R C C

Developer I R I

Operator I I I

© A. Samarin 2012

Roles vs activities (6)

Responsible – Position working on the activityAccountable – Position with yes/no authorityConsulted – Position involved prior to decision or actionInformed – Position that needs to know of the decision or action


• Business objects are formal information descriptions of real things and people which constitute the business

• Naming convention – <noun>, e.g. Person, Organisation, Form1A, QualityDocument,

etc. – Usually, the dominant object is prefixed by some qualifiers

© A. Samarin 2012

Objects (1)


• Derived from existing databases

• To be provided in the XSD (responsibilityof the IT)

• Examples - RoleDefinition, Employee, Absence, and AbsenceRequest

• Define their permissions (security) – who can access which data

© A. Samarin 2012

Objects – data structures (2)


Objects – data structures (3)


• Handled by ECM systems• Formats and metadata are important• Typical metadata for documents are:

– technical information, e.g. title, size, creation date, etc.– classifications for a filing plan– business-related associated information, e.g. reference to a

business object• Life-cycle, e.g. versioning and access control• Metadata to be provided in the XSD (responsibility of the

IT)

© A. Samarin 2012

Objects – documents (4)


• Business rules are constraints and conditions under which the enterprise operates

• Each such rule is an element of guidance that introduces an obligation or a necessity

• Maintenance by the users

© A. Samarin 2012

Rules (1)


Rules (2)


• Key Performance Indicators (KPIs) are a limited number of (agreed) quantifiable measurements that measure how well something or somebody is achieving its or his/her objectives

• In other words, KPIs measure the performance against the SLA

© A. Samarin 2012

KPIs (1)


KPIs (2)


Metrics for BPM from Gartner (1)


• Each human activity must have an SLA– duration, delegation, escalation, etc.

• Each activity is associated with the following generic functional roles:– owner/manager: exercising full control over this activity– Worker: receiving this activity and doing the job– administrator/foreman: exercising some (delegated)

owner/manager rights– Observer: ability to see information related to this activity, e.g. an

audit trail

© A. Samarin 2012

Human activities (1)


• We classify all human activities as intellectual (evaluation, decision-making, etc.), verification or administrative

• The goal is that the humans should perform only intellectual activities, and other activities should be automated (which may also improve quality)

© A. Samarin 2012



• Integration of human activities into processes– No integration: a human activity is stand-alone and is activated by

no process– Non-binding integration: a process “advises” a human what should

be done but does not impose any control (similar to the assistant in some IT tools for personal productivity)

– Reactive integration (see example below)– Form-base integration (see example below)– Complex integration

© A. Samarin 2012



Human activities – reactive (4)


Human activities – form-based (5)


• Recording some information about a BPM system to be able to analyse its behaviour at a later date

• Do not mix technical traceability and business traceability

• The latter may be explicitly embedded into a process

© A. Samarin 2012

Audit trails


• The same process can be modelled in different ways

© A. Samarin 2012

Processes (1)


• Different types of process– core– support – lead

• A popular grouping of processes is designed to handle different types of artefact (e.g. a role, rule, etc.)– create– read (or demand temporary access)– update– delete

© A. Samarin 2012

Processes (2)


Dependencies between artefacts


• Describe BPM artefacts for your project(s)

• Estimate the breakdown of your human activities, e.g. 50 % intellectual, 30 % verification and 20 % administrative

• Provide examples of core processes of your organisation

© A. Samarin 2012

Homework 3-3


• Services are considered to be explicitly-defined and operationally-independent units of functionality – Formal description– Operational independence– Invisible implementation

Services

© A. Samarin 2012


• Definition– architectural approach for constructing

software-intensive systems from a setof universally interconnected and interdependent services

• Advantages– use of standard and pre-fabricated

building blocks– high level of system flexibility– reducing complexity

84

Service-Oriented Architecture (SOA)

© A. Samarin 2012


• BPM, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services

• SOA provides recommendationsfor the implementation, execution and governance of services

85

Synergy between BPM and SOA – structuring relationships

© A. Samarin 2012


• A means of developing distributed systems where the components are stand-alone services

• Services may execute on different computers from different service providers

• Standard protocols have been developed to support service communication and information exchange

Service-oriented architectures

© A. Samarin 2012


• Services can be provided locally or outsourced to external providers

• Services are language-independent• Investment in legacy systems can be preserved• Inter-organisational computing is facilitated through

simplified information exchange

Benefits of SOA

© A. Samarin 2012


– Standardized Definition of Service Contracts– Service Loose Coupling– Service Abstraction– Service Reusability– Service Relative Autonomy– Service State Management– Service Composability– Service Discoverability– Service Execution Context– Service Separation of Concerns

Principles of Service Orientation, version 2008 (1)

© A. Samarin 2012


• Standardized Definition of Service Contracts– Just WSDL (Web Service Description

Language) is not enough– Service contract?– Relationship between contract

participants, i.e. service provider/service and service consumer

– Formalisation and standardisation of the contract parts or types of contained information

– Define a mechanism allowing comprehension of the contract by the contract participants

Principles of Service Orientation (2)

© A. Samarin 2012


• Service Loose Coupling– Service contracts impose low consumer coupling requirements

and are themselves loosely decoupled with their surrounding environment

• Service Abstraction– Service contract only contains essential service information that is

agreed between service provider/owner/steward and service consumer.

– The information has to be sufficient for interacting with the service, utilizing agreed service functionality and reaching agreed Real World Effect


© A. Samarin 2012


• Service Reusability– Services contain and express logic that can be reused in the

execution contexts; services can be positioned as reusable enterprise resources

• Service Relative Autonomy– Services exercise a relative level of control over their underlying

runtime execution environment; if the service does not own or control used entities such as resources or other utilised services, the service must posses contractual control over the use of those entities


© A. Samarin 2012


• Service State Management– Services minimize resource consumption by deferring the

management of state information when necessary• Service Composability

– Services are effective composition participants as well as effective composition containers, regardless of the size and complexity of the composition

• Service Discoverability– Services are supplemented with communicative meta data by

which they can be effectively discovered and interpreted


© A. Samarin 2012


• Service Execution Context– Services perform in surrounding business and technical runtime

environment that constitutes service execution context. The service execution context can affect reachability, behavior and results (Real World Effect) of the services

• Service Separation of Concerns– Business services have to own and provide only their own

functionality being independent from the information sources and original information structures as much as possible


© A. Samarin 2012


• Business-specific– unique business-managed processes and non-reusable IT-

managed services• Business-generic

– reusable business-managed processes and reusable IT-managed services

• Technology-generic– advanced utilities available as IT-managed services (these

services act like an insulation layer)• Technology-specific

– typical basic utilities available as IT-managed services

Categories of services (1)

© A. Samarin 2012


• Service design -> access to BPM artefacts• Service implementation –> wrapping BPM artefacts• Transitioning beyond Basic Services -> processes• Execution and deployment -> messaging over ESB• Governance -> architecting flexible BPM systems

Some SOA topics and BPM

© A. Samarin 2012


• From the book Enterprise Integration Patterns (Addison-Wesley) by Gregor Hohpe and Bobby Woolf.

© A. Samarin 2012

Good resource www.eaipatterns.com


• Pierre and Aline are in the situation of divorce. Their son – Laurent.

• Pierre moves to an address. Aline and Laurent move to anotehr address. New addresses are announced to OCP (population department) or AFC ( fiscal department) or, probably, DIP (education department).

• All these departments exchange addresses.

Example: Moving of a family

© A. Samarin 2012


Moving a family (2)

OCP


…AFC DIP

Aline (mother)

Laurent (son)

AFC_1 DIP_1

Passer auprès des juristes

Click for animation

1

2

3

4

Délai_1

5

7 6

© A. Samarin 2012


Instantiation of change: implicit vs. explicit (e.g. by e-gov portal)

OCP


…AFC DIP

Explicit

Implicit

OCP


…AFC DIP

Click for animation

© A. Samarin 2012