SOA Impact for Student Systems

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    8 Favorites

    SOA Impact for Student Systems - Presentation Transcript

    1. Service-Oriented Architecture Impact for Student Systems
    2. 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.
    3. 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
    4. 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
    5. 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
    6. 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.
    7. The Solution
      • Services!
        • The silver bullet…
        • The panacea…
        • 42…
        • They do dishes and windows!
      Wrong!
    8. 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
    9. 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)
    10. Service Relationships uses has help users achieve participates in invokes supported by are realized by (partially) exposes orchestrate / are composed of
    11. Warning! Danger!
    12. 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
    13. 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
    14. 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.
    15. 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.
    16. 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
    17. 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)
    18. 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
    19. 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?!?
    20. 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).
    21. Service Interoperability
      • Key to success is interoperability
      • The standards and specification are really about promoting standards and interoperability.
    22. 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.
    23. 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)
    24. 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
    25. 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
    26. 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
    27. 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
    28. 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
    29. 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
    30. 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)
    31. 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.

    + asvirskasasvirskas, 3 years ago

    custom

    5374 views, 8 favs, 2 embeds more stats

    SOA can help schools transition from traditional in more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 5374
      • 5369 on SlideShare
      • 5 from embeds
    • Comments 0
    • Favorites 8
    • Downloads 0
    Most viewed embeds
    • 3 views on http://www.nursoa.blogspot.com
    • 2 views on http://nursoa.blogspot.com

    more

    All embeds
    • 3 views on http://www.nursoa.blogspot.com
    • 2 views on http://nursoa.blogspot.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories