Service-Oriented Architecture Impact for Student Systems

Session Overview Many schools face having to replace aging Student Information Systems (SIS) over the next few years. Traditional in-house development or vendor SIS packages both present formidable challenge and risk to implement Services-Oriented Architectures (SOA) is a relatively new architectural style that will change how systems are developed SOA capabilities will eventually impact the build versus buy decisions process SOA can help schools transition from traditional information system paradigm to a self-service system paradigm.

Many schools face having to replace aging Student Information Systems (SIS) over the next few years.

Traditional in-house development or vendor SIS packages both present formidable challenge and risk to implement

Services-Oriented Architectures (SOA) is a relatively new architectural style that will change how systems are developed

SOA capabilities will eventually impact the build versus buy decisions process

SOA can help schools transition from traditional information system paradigm to a self-service system paradigm.

Making System Choices Tough choices to replace a legacy system Vendor Package Cost, fit-gap, business process, customization, usability, historic outcomes Best of Breed Most of same with maybe better fit-gap, but add integration issues In House Development Resources, schedule duration, scope control, software engineering capability and maturity, architecture, technology choices Evolve Most of issues with in-house, but architecture and technology is huge Stay the Course Rearrange the deck chairs on the Titanic Hybrid Approach (any combo of the above) More agile, but have to deal with all the issues Many schools choosing the vendor package route

Tough choices to replace a legacy system

Vendor Package

Cost, fit-gap, business process, customization, usability, historic outcomes

Best of Breed

Most of same with maybe better fit-gap, but add integration issues

In House Development

Resources, schedule duration, scope control, software engineering capability and maturity, architecture, technology choices

Evolve

Most of issues with in-house, but architecture and technology is huge

Stay the Course

Rearrange the deck chairs on the Titanic

Hybrid Approach (any combo of the above)

More agile, but have to deal with all the issues

Many schools choosing the vendor package route

Traditional Systems Model clash between business process and system (ERP) Force customers to adapt business processes to system limitations Customers adopt vanilla implementations because of this Customization through configuration may not cut it Monolithic and Tightly Coupled Complex to understand due to coupling Often are an unplanned accretion of functionality and data over time Difficult and expensive to customize and extend Difficult or impossible to replace or evolve part of the system

Model clash between business process and system (ERP)

Force customers to adapt business processes to system limitations

Customers adopt vanilla implementations because of this

Customization through configuration may not cut it

Monolithic and Tightly Coupled

Complex to understand due to coupling

Often are an unplanned accretion of functionality and data over time

Difficult and expensive to customize and extend

Difficult or impossible to replace or evolve part of the system

Traditional Systems Closed Architectures Getting information in or out is difficult Interfaces have significant technical challenges data representation schema Interfaces tend to be batch loads, not real time time sensitivity fragmented workflows Discourages best of breed solutions

Closed Architectures

Getting information in or out is difficult

Interfaces have significant technical challenges

data representation

schema

Interfaces tend to be batch loads, not real time

time sensitivity

fragmented workflows

Discourages best of breed solutions

Traditional Systems Fragment the Enterprise (non-ERP) Business processes do not honor organizational boundaries! Truncated workflows Data consistency and integrity Platform and Technology Dependent Commits organization to long term technology decisions that may have negative consequences.

Fragment the Enterprise (non-ERP)

Business processes do not honor organizational boundaries!

Truncated workflows

Data consistency and integrity

Platform and Technology Dependent

Commits organization to long term technology decisions that may have negative consequences.

The Solution Services! The silver bullet… The panacea… 42… They do dishes and windows! Wrong!

Services!

The silver bullet…

The panacea…

42…

They do dishes and windows!

But Services Can Help How? Align to business processes Enable businesses to adapt to rapidly changing customer and stakeholder needs Emphasize system interoperability Enable planned evolution of systems

How?

Align to business processes

Enable businesses to adapt to rapidly changing customer and stakeholder needs

Emphasize system interoperability

Enable planned evolution of systems

What are Services? A service is Autonomous unit of automated business logic Accessible to other systems A service represents Business process Sub process Activity (process step) (or multiple)

A service is

Autonomous unit of automated business logic

Accessible to other systems

A service represents

Business process

Sub process

Activity (process step)

(or multiple)

Service Relationships uses has help users achieve participates in invokes supported by are realized by (partially) exposes orchestrate / are composed of

Warning! Danger!

Service Architecture Composition Service architectures are composed of Services Units of processing logic Example: Award Service Messages Units of communications between services Needed for services to do their job Example: ISIR (abstraction) + relevant instructions Operations Units of Work Example: Determine Cost of Attendance Processes Composed / orchestrated groups of services Example: Financial Aid Disbursement

Service architectures are composed of

Services

Units of processing logic

Example: Award Service

Messages

Units of communications between services

Needed for services to do their job

Example: ISIR (abstraction) + relevant instructions

Operations

Units of Work

Example: Determine Cost of Attendance

Processes

Composed / orchestrated groups of services

Example: Financial Aid Disbursement

Service Detail Award Service Calculate EFC Package Student Determine COA Get Aid Package Unpackage Student Package Student Population Operations Exposed in Service Logical Unit of Business Logic

Service Design Principles Services are autonomous Control over encapsulated business logic Other system processes and services should not affect a given service Implication: Services can evolve independently of each other Example: The functionality to load and process new ISIRs should not impact the process to package a student.

Services are autonomous

Control over encapsulated business logic

Other system processes and services should not affect a given service

Implication: Services can evolve independently of each other

Example:

The functionality to load and process new ISIRs should not impact the process to package a student.

Service Design Principles Services are contract-based A service contract is the set of conditions that allows a consumer to utilize the service. Implication: No knowledge of the underlying platform, technologies, or implementation is required Example: Real-World: Checking aid status over the phone. I provide my name, student ID number, other credentials. FA worker tells me if my app is received, what documents are needed, etc. I don’t know if info was looked up in the computer, paper file, or fabricated. SOA: Debit Student Account Consumer only knows the information it must provide. How the service accomplishes its task is completely opaque.

Services are contract-based

A service contract is the set of conditions that allows a consumer to utilize the service.

Implication: No knowledge of the underlying platform, technologies, or implementation is required

Example:

Real-World: Checking aid status over the phone. I provide my name, student ID number, other credentials. FA worker tells me if my app is received, what documents are needed, etc. I don’t know if info was looked up in the computer, paper file, or fabricated.

SOA: Debit Student Account

Consumer only knows the information it must provide. How the service accomplishes its task is completely opaque.

Service Design Principles Services are reusable Design with reuse in mind even when no immediate reuse is planned Implication: Reduce redundant or conflicting logic Enhance ability to develop new apps based upon existing logic Example: Registration Service – Get Term Registration Info Purchasing – Submit Purchase Order Registration Service Get Term Registration Info FinAid System Academic System Grad Div System

Services are reusable

Design with reuse in mind even when no immediate reuse is planned

Implication:

Reduce redundant or conflicting logic

Enhance ability to develop new apps based upon existing logic

Example:

Registration Service – Get Term Registration Info

Purchasing – Submit Purchase Order

Service Design Principles Services are composable At the operations level, a service can be built from multiple other services Implication: a service can orchestrate many services across multiple organizations in order to execute a business process Example: Loan Borrower Separation (next page)

Services are composable

At the operations level, a service can be built from multiple other services

Implication: a service can orchestrate many services across multiple organizations in order to execute a business process

Example:

Loan Borrower Separation (next page)

Service Composition Example Aid Disbursement Process FA Award Service Registration Service Loan Service Bursar Service FA System Microsoft .NET Registrar System Mainframe Dept of Ed ??? Bursar Java on Linux Aid Disburse Service Is Realized By Are Executed In / Controlled By Orchestrates account info Debit Account Service Interface Layer App Logic Not Physical

Services Technologies Myriad service frameworks exist Microsoft WCF – New! Microsoft ASMX Sun Java EE Countless open source Java Perl, PHP, Ruby Many traditional closed architecture systems Okay, but how does a Microsoft service talk to a Java service?!?

Myriad service frameworks exist

Microsoft WCF – New!

Microsoft ASMX

Sun Java EE

Countless open source Java

Perl, PHP, Ruby

Many traditional closed architecture systems

Okay, but how does a Microsoft service talk to a Java service?!?

By Using Standards Three main standards organizations that define the rules W3C OASIS WS-I Standards include XML – platform independent data representations SOAP – message exchanges between systems WS-* = specifications for every conceivable need (e.g. security, transactions, metadata exchange, etc).

Three main standards organizations that define the rules

W3C

OASIS

WS-I

Standards include

XML – platform independent data representations

SOAP – message exchanges between systems

WS-* = specifications for every conceivable need (e.g. security, transactions, metadata exchange, etc).

Service Interoperability Key to success is interoperability The standards and specification are really about promoting standards and interoperability.

Key to success is interoperability

The standards and specification are really about promoting standards and interoperability.

Applying Services to the Problem Model clash between system design and business process SOA enables a process-centric design approach If selecting a vendor, evaluate them on their service model.

Model clash between system design and business process

SOA enables a process-centric design approach

If selecting a vendor, evaluate them on their service model.

Applying Services to the Problem Monolithic Before The System After S1 S2 S4 S3 System replacement is a total process System modules are tightly interdependent making change difficult System composed of many logical service units (decomposition) Underlying business logic decoupled as much as possible from other services (autonomy and loose coupling)

Monolithic

System replacement is a total process

System modules are tightly interdependent making change difficult

System composed of many logical service units (decomposition)

Underlying business logic decoupled as much as possible from other services (autonomy and loose coupling)

Applying Services to the Problem Closed Architecture Systems integrate through batch exports and imports Utilize proprietary formats and schemas Reg System FA System Extract [proprietary Format] Batch export Translate Batch import Reg System FA System Bursar System Real-time Disbursement Process Disb Batch Batch export Bursar System Batch import Before After Granular message-oriented communication Format is standardized XML (interoperability) Services specify contract and schema for clients

Closed Architecture

Systems integrate through batch exports and imports

Utilize proprietary formats and schemas

Granular message-oriented communication

Format is standardized XML (interoperability)

Services specify contract and schema for clients

Applying Services to the Problem Fragmented Enterprise No Workflow Integration is Complex Require excessive human intervention Error prone Delay completion of business objectives Reg System FA System Extract [proprietary Format] Batch export Translate Batch import Reg System FA System Bursar System Real-time Disbursement Process Disb Batch Batch export Bursar System Batch import Before After Orchestrated, transactional communication

Fragmented Enterprise

No Workflow

Integration is

Complex

Require excessive human intervention

Error prone

Delay completion of business objectives

Orchestrated, transactional communication

Applying Services to the Problem Platform / Technology Dependence Before The System After 1970 2011 S1 S2 S4 S3 .NET .NET 2 Java 6 Java 6 S1 S2 S4 S3 .NET 5 Java 8 .NET 5 Ruby Today 2007 2011 S5 S5 S6 Ruby X .NET 5 S1 S2 S4 S3 .NET VB6 Java Java

Platform / Technology Dependence

Interoperability versus Integration The traditional model for communication between separate systems is integration General implication for communication Not real time Not transactional Not granular In the services world, interoperability supports these aspects

The traditional model for communication between separate systems is integration

General implication for communication

Not real time

Not transactional

Not granular

In the services world, interoperability supports these aspects

SOA Benefits Summary Allow us to execute complex business processes by composing systems from small, less complex building blocks Fosters collaborative business and technical environment through sharing and coordination of services Create outward facing self-service applications not constrained by organizational boundaries Enables creating adaptive, agile systems that are resilient to changes in the business environment

Allow us to execute complex business processes by composing systems from small, less complex building blocks

Fosters collaborative business and technical environment through sharing and coordination of services

Create outward facing self-service applications not constrained by organizational boundaries

Enables creating adaptive, agile systems that are resilient to changes in the business environment

How to Fail with SOA SOA-tize everything Start with the largest and most complex aspects of the enterprise Don’t include key stakeholders and users Focus on technology, forget the business Don’t build the right team Don’t evangelize and train Don’t plan for sufficient resources

SOA-tize everything

Start with the largest and most complex aspects of the enterprise

Don’t include key stakeholders and users

Focus on technology, forget the business

Don’t build the right team

Don’t evangelize and train

Don’t plan for sufficient resources

Conclusions SOA represents a fundamental change to the way information systems will designed in the future Long term impact on IT portfolio management is dramatic Adds a significant dimension to student system evaluation process Undertaking SOA requires commitment from all levels of the organization and significant investments (people, process, tools, and climate)

SOA represents a fundamental change to the way information systems will designed in the future

Long term impact on IT portfolio management is dramatic

Adds a significant dimension to student system evaluation process

Undertaking SOA requires commitment from all levels of the organization and significant investments (people, process, tools, and climate)

Some Additional Notes Other complementing architectures and technologies to complement SOA Message Queuing Software – Can help scalability and load management of systems by offloading long running tasks so they can be executed out of band of a client request. The way it works is a software app or service drops a message on to the queue. Other software is monitoring the queue for specific messages, pulls the message off the queue and follows the instructions in the message. Important capability for enterprise integration. AJAX (Asynchronous Javascript and XML) – Presentation layer architectural pattern that allows a web page to partially update itself without reposting the entire page. Enables a more rich client experience. Can directly invoke services BPMN – Business Process Modeling Notation ( www.bpmn.org ). This is flowcharts on steroids. Actually a syntatic language for expressing business processes, but has familiar constructs of flowcharts. Good news is that this is a developing standard, not a proprietary notation and integrates nicely with the services paradigm. Managed by same group that manages UML (OMG – Object Modeling Group). Major vendors of modeling tools are implementing this standard. A good one that is very affordable is Sparx Enterprise Architect BPEL – XML based language for expressing business processes. BPMN has some mapping to this. BPEL can be used in orchestration engines (e.g. Microsoft BizTalk Server and IBM Websphere Business Integration Server) Enterprise Service Bus – Architectural pattern for message-based enterprise integration. Is not SOA based, but can help an organization realize one by decoupling services from underlying systems and instead only communicate with the service bus.

Other complementing architectures and technologies to complement SOA

Message Queuing Software – Can help scalability and load management of systems by offloading long running tasks so they can be executed out of band of a client request. The way it works is a software app or service drops a message on to the queue. Other software is monitoring the queue for specific messages, pulls the message off the queue and follows the instructions in the message. Important capability for enterprise integration.

AJAX (Asynchronous Javascript and XML) – Presentation layer architectural pattern that allows a web page to partially update itself without reposting the entire page. Enables a more rich client experience. Can directly invoke services

BPMN – Business Process Modeling Notation ( www.bpmn.org ). This is flowcharts on steroids. Actually a syntatic language for expressing business processes, but has familiar constructs of flowcharts. Good news is that this is a developing standard, not a proprietary notation and integrates nicely with the services paradigm. Managed by same group that manages UML (OMG – Object Modeling Group). Major vendors of modeling tools are implementing this standard. A good one that is very affordable is Sparx Enterprise Architect

BPEL – XML based language for expressing business processes. BPMN has some mapping to this. BPEL can be used in orchestration engines (e.g. Microsoft BizTalk Server and IBM Websphere Business Integration Server)

Enterprise Service Bus – Architectural pattern for message-based enterprise integration. Is not SOA based, but can help an organization realize one by decoupling services from underlying systems and instead only communicate with the service bus.