Architecting modern informaiton systems M3 application architecture

Architecting modern
information systems
Module 3
Application architecture
A. Samarin

Business context

• 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 Architecting modern information systems - Module 3 2

Applications need to be adaptive

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

maintenance 40 %

development 80 %
95 %

1 – Estimated by an IT staff member 60 %
2 – Estimated average in the IT
industry
20 %
3 – A real scenario (governmental 5%
client) 1 2 3


Complexity

• 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


Main architecting principles

• 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


Improvement of artefacts

• Digital – available in electronic form
• Externalized – available as separate entities with proper
definition, naming, versioning, storage, security, traceabili
ty, 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


Relationships between 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


Business processes are complex
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


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

• SOA provides
recommendations
for the implementation,
execution and governance
of services


Synergy between BPM and SOA (2) –
• 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

service process


Feedback improvement loop

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

3

4 1


Process-oriented view of an enterprise
(before BPM)


Process-oriented view of an enterprise
(with BPM)


BPM suite components


Process designer / modeller

• A graphical environment to manipulate with diagrams and
other artefacts


Execution engine console (1)

• Management of process templates and instances by a
system administrator


Execution engine console (2)

• Access to audit trail of a process instance


Worklist (1)

• Access to BPM for a « normal user »


BPM suite components (optional)

• 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


BPM suite components (extended list)


Business Event Management (BEM)

• 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


Business rules engine (BRE) and
decision management
• 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


Business Activity Monitoring (BAM)

• 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


Business Intelligence (BI)

• 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


Process monitoring, BAM and BI


Dashboard

• Access to BPM for a « manager »


Enterprise Content Management (ECM)

• 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)


Enterprise Service Bus (ESB)

• An environment for facilitating inter-service
communication


Improving a core business application

• Situation ESB-centric view: only flow of data

– some “pieces of work” are
being lost in a chain of
applications
– ESB is not enough
• Task
Process-centric view: both
– coach how to apply new flow of control and flow of data
technologies
• Action
– make the business process
explicit Primary importance: the result of
working together, but not individual
– mix BPM, BAM, BEM, CEP exchanges


Convergenceg of BPM suites

Source: The Forrester Wave, Q4 2006


Comparison of BPM suites

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


Some BPM suites

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


Standards in BPM suites
XPDL
BPMN

BPEL
GUI

WSDL,
XSD


Human activities

• 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


Graphical User Interface

• xForms is an XML application that represents the next
generation of forms for the Web
• xForms 1.1 is a candidate recommendation in W3C


Rich User Interface

• AJAX
• DHTML
• JavaScript


Transportation of data

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


Definition of services

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


Homework 3-1

• Do you use any BPMS?

• Is BPM vendor-centric or customer-centric?


BPM:
vendor-centric or customer-centric
• 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


BPM artifacts

• Events
• Roles Human
“workflow”
• Data structures Data structures
• Documents Roles

Documents
• Rules Events
Rules
Processes
• Audit trails Services

• KPIs Audit trails

• Processes KPIs

• Services


Knowledge about artefacts

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


Hidden complexity

• Any artefact can be versionable

• Compound artefacts, e.g. process templates

• Templates vs. instances


Example process

• 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


Event (1)

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

• Categories
– temporal
– external
– internal
– spontaneous


Event (2)

• 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)


Capture artefacts – events

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

Activity complete
Case ID Activity Activity start time time Employee Case type
Register
BZ-06-0501-001 appeal 24-10-2006 21-11-2006 Person A Schoolbus
Confirm
BZ-06-0501-001 reception 21-11-2006 09-01-2007 Person A Schoolbus
Register
receipt of
BZ-06-0501-001 documents 09-01-2007 09-01-2007 Person C Schoolbus
Result
hearing /
BZ-06-0501-001 Write advice 09-01-2007 09-01-2007 Person C Schoolbus


Event (3)

• 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


Roles (1)

• A construct that represents the relevant skills and
responsibilities required to perform certain operations
• Follow the Role-Based Access Control (RBAC)


Roles (2)

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


Roles (3)

• 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


Roles (4)

• 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”


Roles (5)

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


Roles vs activities (6)

Model Automate Execute Control Measure Optimise

Process
owner A A A A A

Super-user
R 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

Responsible – Position working on the activity
Accountable – Position with yes/no authority
Consulted – Position involved prior to decision or action
Informed – Position that needs to know of the decision or action


Objects (1)

• 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


Objects – data structures (2)

• Derived from existing databases

• To be provided in the XSD (responsibility
of the IT)

• Examples - RoleDefinition, Employee, Absence, and
AbsenceRequest

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


Objects – data structures (3)


Objects – documents (4)

• 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)


Rules (1)

• 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


Rules (2)


KPIs (1)

• 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


KPIs (2)


Metrics for BPM from Gartner (1)


Human activities (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



• 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)



• 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


Human activities – reactive (4)


Human activities – form-based (5)


Audit trails

• 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


Processes (1)

• The same process can be modelled in different ways


Processes (2)

• 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


Dependencies between artefacts


Homework 3-3

• 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


Services

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


Service-Oriented Architecture (SOA)

• Definition
– architectural approach for constructing
software-intensive systems from a set
of universally interconnected and
interdependent services

• Advantages
– use of standard and pre-fabricated
building blocks
– high level of system flexibility
– reducing complexity


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

• SOA provides
recommendations
for the implementation,
execution and governance
of services


Service-oriented architectures

• 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


Benefits of SOA

• 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


Examples of interfaces (1)

• CRUD pattern
– Create
– Read
– Update
– Delete


Examples of interfaces (2)

• CALIFE pattern
– Construct
– Add
– Locate
– Inspect
– Fetch
– Edit


Principles of Service Orientation, version
2008 (1)
– 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 (2)

• 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



• 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



• 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



• 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



• 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


Services are externalised artefacts


Categories of services (1)

• 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 (2)


Some SOA topics and BPM

• 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


Good resource
www.eaipatterns.com
• From the book Enterprise Integration Patterns (Addison-
Wesley) by Gregor Hohpe and Bobby Woolf.


Example: Moving of a family

• 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.


Exchange between N sources - problem

• Complexity N*(N-1)/2

…

…
DIP

OCP AFC


Exchange between N sources - solution

• Complexity N

Coordination process

OCP AFC … DIP


Comparison in 3D


Coordination process (between three
departments – OCP, AFC and DIP)

Click for animation


Click for animation
Execute a request for change (in each source)


Big picture in 3D


Click for animation
Moving a family (1)


OCP AFC … DIP

Pierre
(father)


Click for animation
Moving a family (2)


OCP AFC … DIP
Passer auprès
des juristes

Aline
(mother)

AFC_1 DIP_1
Laurent
(son) Délai_1


Big picture in 3D


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


OCP AFC … DIP

Explicit


OCP AFC … DIP


Architecting modern informaiton systems M3 application architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Architecting modern informaiton systems M3 application architecture

Similar to Architecting modern informaiton systems M3 application architecture (20)

More from Alexander SAMARIN

More from Alexander SAMARIN (20)

Recently uploaded

Recently uploaded (20)

Architecting modern informaiton systems M3 application architecture