SOA Impact for Student Systems

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.

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

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

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

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.

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

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

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)

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 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 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 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 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?!?

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

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

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)

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

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

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

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

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

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

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)

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.

SOA Impact for Student Systems

by Adomas Svirskas on Feb 27, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 8

Statistics

SOA Impact for Student Systems — Presentation Transcript

http://www.nursoa.blogspot.com	3
http://www.techgig.com	3
http://nursoa.blogspot.com	2