Your SlideShare is downloading. ×
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Presentation Slides
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Presentation Slides


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Mark has over 20 years experience in IT in the public sector, with a focus on the higher education sector.  His major areas of experience are in enterprise applications, IT infrastructure and project management.  He has worked for Land Victoria with a highlight being the Victorian On-line Titles System and with the Department of Human Services on the Integrated Client and Case Management System, based on EAI architecture.  He has worked for Holmesglen TAFE, University of Melbourne, Swinburne University of Technology and currently at Monash University.  At Monash he is the Project Manager for the Application Integration project.  This is a strategic project to introduce SOA to convert the current enterprise application integrations to a flexible web service based architecture. Presentation focus on why and how of what Monash is doing, not on technical issues.
  • Monash is: Large, multi-campus, international university. Offers a very large range of courses Has a strong research base Continues to grow 
  • Large enterprise applications servicing a large client base with very specific and time critical requirements. Diversified applications across central corporate services and faculty based applications Typical university information environment Focus on issues with application to application integrations – 170 core interfaces
  • Simplified schema from information architecture analysis done in 2005 Highlighted a number of issues and challenges for the future Complexity, lack of control, unreliability, limit to growth
  • Applications have developed traditionally, on a best of breed basis – silo architecture. University organisation structure is complex and large. Legacy of mergers, rapid growth and investment in legacy information assets. Increasing requirement for data sharing, support for business processes across applications. Requirement for a more agile approach to development of new business services
  • varied standards, styles and different administration and management arrangements. with a high level of duplication Batch run time windows: pressure of multi country time zones of our expanding overseas campuses. No overall picture exists within a single application – the current point to point design was essentially created independently from each end. In the middle, ITS tech support create directories and shell scripts for the transfers to work reuse was not a high priority All our Disaster Recovery Plans are application based Huge investment in information systems. Large replacement and upgrade costs
  • Political, educational and market demands continually creating new business requirements. In most cases, the data already exists, but new business processes are required that use data from different applications. Workflow management is a major feature of new requirements Automation of business processes We want to build on existing information assets rather than replace Risks of customisation – creating a maintenance problem Low cost and high quality
  • Target was to clean up the interface jungle Originally an EAI solution was considered, but BPEL based approach showed great potential Strategy was to standardise and improve central management of interfaces Quality, governance and performance issues were important
  • Main immediate objectives were tactical. The option of simply managing existing interfaces in a better way still left us with a legacy of old technology and lack of standards. Minimum impact on enterprise applications was a major objective. In many cases, our analysis showed that conversion of legacy integrations to a SOA architecture would have no impact on participating applications. Web service capability for applications was not a mandatory requirement.
  • To take advantage of new technology to enable new interfaces to reflect business processes rather than data requirements. Our vision is a single view/definition of a student, a student enrolment, a student’s status a staff member an organisational unit This is tied in with our BI strategy: a consolidated data repository that will feed multiple data warehouses and cubes. The web services we provide will be aligned with the views/ETL routines that extract data to the repository. Design Features Web services – the ability to reuse Transformation of one extract multiple times Interfaces can include workflow components Asynchronous designs Multiple interfaces in the one business transaction Multiple error trapping points Ability to incorporate rollbacks in the interface design
  • Integration Architecture Assessment in 2005 identified our core problem In 2006 we planned and delivered a pilot project – proof of concept It has taken 4 months solid work to look at 170 of our interfaces and document them to a level where we can feel confident talking to our business owners. There were in fact 4 interfaces that were running every night that were no longer required as the processes had changed at the other end! We want to incorporate all our documentation into the SOA Suite this time around. Monash is decentralised to the point that there are mini IT shops in each business area, faculty and even individual schools and admin units. Each mini IT section has the capacity to create systems and request interfaces, sometimes without any knowledge of the central IT division.
  • Planning included a business model, governance structure, standards as well as technology architecture Partnered with Red Rock Consulting with assistance from Oracle. Approach was to carefully specify, design, build and document as we went. – project library The end product was to be a definitive path forward: design options, best practice statements, architecture. Core component was the establishment of an Integration Competency Centre: utilise existing staff resources heavy commitment to training partnering with Red Rock for external support Challenge was lack of skills and expertise – cutting edge
  • An Integration Competency Centre has been established to: Lead the development of conversion of current interfaces to the new web services based standard Manage and administer the central BPEL integration system Lead and foster the development of skills required to implement the new technology ICC as a business unit providing integration services Existing staff resources will be progressively taken up by the ICC as needed. Support and maintenance – increasing role of ICC Provide a fully costed and transparent service Use Service Agreements Steering Committee structure above it, making the policy and priority decisions Project Sponsor ICC Manager Business Process Reps – from participating enterprise applications Faculty/Department Reps
  • ICC is place within IAS and draws on IAS resources Good Governance Principles – Sponsor, Advisory groups Business and Technical Business Advisory Group - Faculty/Department Reps as well as Monash information system owners BPEL knowledgeable developers as and when required Other development expertise as and when required: Web services, Application Express, java etc Borrow support from technical support area as and when required . Our structure ICC Manager – full time Integration matters 3 programmers as and when required Other development expertise as and when required: Web services, Application Express, java, Technical Architect etc 1 BA interface design as and when required Business Process reps depending on interfaces being worked on at time. Technical support from our Application Administration unit as and when required.
  • ICC Wiki Web is a web site that allows interaction and collaboration. The Wiki web approach is being used successfully by a number of groups in Monash. It provides all the features of a normal web site, but has the ability to allow participants to add and modify the content. It works very well for supporting communication in medium to large teams. A good example is the Wikipedia Emphasis on researching the technology and the market Learning from our experience Project documentation has been comprehensive Expose project library to stakeholders Organisational and procedural structures are documented and can be easily accessed and critically reviewed Provide interaction and collaboration Open learning approach – exposure to university community
  • Horizontal, scalable architecture. Additional servers can be added as load increases High availability design 2 geographical locations Load balancer for 2 production application servers Dataguard synchronisation between databases DR and C plan Based on Monash standards for Sun systems
  • Oracle SOA is open standards and designed to talk to many other applications It does not require us to move data and processes through unnecessary steps and can support a multitude of adaptors. The Gartners, Ovums etc of this world place Oracle BPEL/SOA Suite in the top right quadrant consistently. It’s a complete solution, we don’t have to interface multiple products from multiple vendors to do our interfacing! We are an Oracle shop, and the product fits our architecture strategy. Requirement for security management meant that additional components need to be added, eg OWSM, OID Ability to partner with Red Rock Each component does not represent any real difficulties, but interaction between components and management of components revealed complexity and some issues with compatibility between components
  • High level view of setup of our production environment. Load balancing for performance and availability requirements. SOA software placed demand on our Application Administration team – additional training and new skills needed.
  • A high level picture of how the various SOA components relate to each other. We developed our own template and standard for exception handling, which can be applied to most implementations.
  • An existing scenario showing complex workflows and transactions Same scenario but simplified Our target is a Business Process Model: Process that now runs real time in conjunction with remaining overnight interfaces End to end design of business processes Maximise re-use through design of XSDs, templates, common data model
  • We intend to move from our point to point architecture a centralised integration service based on SOA Consistent Well documented Comply with ITIL governance High potential for re-use Source of enterprise wide standards
  • Provide a complete end to end business process solution Each interface then becomes a potential spiders web of interactions that are of varying levels of dependency. Especially if it has a role to play in other systems, processes or interfaces. The chain of events that relate to a full process flow can then be modeled, KPIs developed, simulated, connections made between people and systems, managed in terms of process exceptions measured, monitored and optimised as time goes by.
  • Immediate target is conversion of eligible interfaces between enterprise applications Picking up opportunities for new development as priorities and capability change – eg new developments in research information management Workflow and BPM on radar We have another year of development before a full integration service is available to the university
  • Thank you!
  • Transcript

    • 1. Enterprise Architecture Symposium September 2007 University of Canberra Building a Service Oriented Architecture at Monash University - A Pragmatic Approach Mark Kasprzyk Project Manager ICC Manager, Integrated Administrative Systems
    • 2. Topics
      • Monash information systems
      • Our current interface related problems
      • Why we chose SOA @ Monash
      • What are we doing?
      • The SOA Framework
      • Our next steps
    • 3. Monash Background
      • Established 1958
      • F irst student intake 1961 (youngest Go8 university)
      • 13,000+ staff
      • 52,000+ students (30% international, from over 100 countries)
      • 4 continents
      • 8 campuses
      • 10 Faculties
      • 75 Research centres
      • 17 Cooperative research centres
      • 5,000+ published research works p.a.
    • 4. Enterprise Information Systems at Monash
      • SAP HR and Finance
      • Student System, Alumni System
      • Timetabling and Class Allocation Systems
      • Library Catalogue and Ordering System
      • Enterprise Web Portal: Student/Staff
      • Authentication/Directory Services
      • Various online Student Teaching Systems
      • Research Administration systems
      • TRIM Records Management
      • Correspondence Trackers
      • Space/Facilities
      • Host of faculty/department based systems
      • Over 280 interfaces.
      • About 170 core system interfaces
    • 5. Our Existing Spaghetti Plate
    • 6. Where Have We Come From?
      • ‘ Best of breed’ approach
      • Autonomy of divisions and faculties
      • Limited funds
      • Budget restrictions
      • Specific and specialised business needs
      • Restricted technology
    • 7. Current Problems
      • Complexity
        • Over 170 interfaces between enterprise applications
      • Many are a large batch extracts.
      • Tracking and monitoring of data transfers is un-coordinated.
      • No clear DRP plans or error tracking protocols for interfaced data.
      • Authorative sources of data are not clear.
      • Increased business need for better quality information
      • Need for better value from existing enterprise information systems.
    • 8. Where Do We Want to Go?
      • Be more responsive to business needs
      • Connect the ‘silos’
      • Get more value from current investments
      • Reduce our costs
      • Improve quality of service
      • Provide scalable, low cost, low risk solutions
    • 9. Target: Spaghetti to Hub
    • 10. SOA @ Monash - Tactical
      • Fix Things
        • ‘ Clean up’ tangle of interfaces
        • Near ‘real time’ transactions
        • Adaptable designs that have easy maintenance
        • Reliable message delivery
        • Reduce the large maintenance cost and timeframes of application integration
        • Risk reduction
        • Applications are ‘cocooned’, or ‘loosely coupled’ so they can be upgraded/replaced more easily.
    • 11. SOA @ Monash – Strategic
      • Monash Information Technology Architecture Strategy
        • Better governance
        • Consistent standards
        • Central coordination point
        • Strategic architecture [Extensible, Scalable]
        • Platform for new business processes (BPM)
        • Enterprise Web Services Registry: XSD definitions and WSDL Web Services listings for faculties and business owners –.
    • 12. SOA @ Monash – Untangling!
      • Integration Architecture Assessment -> Pilot Project
      • Database of existing interfaces has been developed
      • Priority of conversion of interfaces has been ‘triaged’
      • Opportunities for new applications have been identified
      • Redevelopment Strategies include:
        • Better error capturing and notification
        • Handshaking control between systems
        • Web services, XML transfer, direct database updates
        • XSD files containing definitions of key data to the university
        • Single extract, multiple transformations where possible
        • Security arrangements
    • 13. SOA Framework -> Documentation
      • Business model
      • Integration Competency Centre
      • Integration Governance
      • Technology Architecture
      • Integration Methodology and Standards
      • Project Management
      • Best Practices and Guidelines
      • Design, Build, Test
      SOA Development Framework SOA Suite Implementation ICC Operations SOA Operations Manual
    • 14. SOA @ Monash - Integration Competency Centre
      • Small team: skill and knowledge base
      • Develop and implement integrations and business processes across enterprise applications.
      • Manage and maintain the Enterprise Integration Framework, including standards, methodologies, and technologies.
      • Manage and maintain cross-application business processes
      • Provide strategic and tactical advice to business owners on information integration requirements and solutions.
      • Administer the integration systems and technologies to support the Enterprise Integration Framework.
    • 15. ICC Structure Manager Application Integration Lead Integration Developer Developers as needed Technical Support DBA Support Tech. Architect Reference Group A [Business] Reference Group B [Technical] External contractors (as required)
    • 16. ICC Wiki Web
      • A Wiki Web has been set up for the ICC.
      • information resource for ICC stakeholders
      • ICC Document Repository
      • Collaborative workspace for ICC Projects
      • Register proposals for new development
      • Track project progress
      • Reference Group Page
    • 17. Hardware Configuration - Integration Services - Database Servers Load Balancer Prod 1 Sun V240 – Development QA/Test Production Oracle Application Servers Oracle DataGuard Prod 2 Sun V240 QA 1 Sun V890 Dev 1 Sun V240 DB Prod Sun V890 DB QA Sun V890 DB Dev Sun V490
    • 18. Oracle SOA Suite
      • BPEL Process Manager
        • Process Designer
        • Process Manager Console
        • Process Manager Server
        • Integration Services
        • Human Workflow
      • Business Activity Monitoring
        • Web Browser Dashboard
        • Business User Authoring
        • Embedded Actions
        • Real-Time Analytics
      • Business Rules
        • Business User Authoring
        • Small Footprint Engine
        • Seamless Integration
        • Rules SDK
      • Enterprise Service Bus
        • Multi-protocol bus
        • Data enrichment
        • Content based routing
        • Content filtering
      • Web Services Management
        • Policy authoring
        • Policy enforcement
        • .NET and Java support
      • Web Services Registry
        • Publish services
        • Categorize services
        • SOA System of Record
      • Connectivity
        • 300+ Application adapters
        • Legacy adapters
        • Technology adapters
        • B2B protocols
        • WSIF bindings
      • JDeveloper
        • Develop Web services
        • WS-* standards support
      • Oracle Internet Directory
    • 19. Production Schema
    • 20. SOA Services Framework
    • 21. Untangling Interfaces into Business Processes 1. 2. 3. BPEL
    • 22. Target Architecture (staged)
    • 23. It’s not just technology though
      • We are providing a service and methodology that will support a shift in the basic concept of what is an interface and how data interacts between the different systems.
      • We are providing a standard and a toolset for the wider university community to use.
      • Shifting the focus to ‘Business Process’
    • 24. Next Steps ? ? ? ? Enterprise wide implementation of BPM and SOA ? ? ? ? Workflow across the organisation  Enterprise Web Services Registry  New developments  Analysis and re-design of existing interfaces  Hardware and system build  Architecture Specification
    • 25. Questions