Soa Driven Project Management
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Soa Driven Project Management



Project management know how in SOA project

Project management know how in SOA project



Total Views
Views on SlideShare
Embed Views



2 Embeds 14 12 2



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Soa Driven Project Management Presentation Transcript

  • 1. SOA-Driven Project Management Byungwook Cho K. 2006-06-21
  • 2. Overview
    • In this chapter, we will learn about SOA Project Management Methodology
    • There are no project management methodologies specialized only for SOA but there are a lot of considerable things that SOA helps project management. This chapter will introduce the way how to leverage project management by SOA
  • 3. Agenda
    • Established Project Management Methodologies
    • SOA-Driven Project Management
    • Configuration Management
    • Testing
  • 4. Established Project Management Methodologies(1)
    • “ I can’t tell you what I want, but I will recognize it when I see it phenomenon”
    • The popular waterfall model assumes that the customer requirements are fixed at the beginning of the projects
      • Every phase must be finished before the next phase is entered
      • Cannot cope with unstable requirements
    • More incremental or iterative models are emerged
      • To cope with unstable requirements
      • Rapid Application Development (RAD) by James Martin, Spiral Model by Barry Boehm, Rational Unified Process based on UML,DSDM,MSF and Catalysis
    • More lightweight approach to iterative development
      • From late 1990, in the wake of the fast-moving Internet revolution
      • Agile development
      • Manifesto for Agile Software Development, Extreme Programming (XP)
  • 5. Established Project Management Methodologies(2)
    • Add Service Orientation to your favorite project management methodology
      • SOA-driven project management does not require new methodology
      • Chosen methodology should support iterative development for coping with complexity and unstable requirement
  • 6. SOA-Driven Project Management (1)
    • SOA introduction happens on different levels
      • Business projects versus IT projects
        • SOA project management have to be closely aligned with concurrently ongoing business projects , which are the source for requirement
        • Services are 1:1 mapping of business entity . Services are ideal tool for coordinating business projects and IT projects, giving project managers from both sides a perfect mean for communicating business requirements and technical implementation .
      • IT program versus IT project management
        • SOA board as a key tool for coordinating multiple projects
      • Business services versus SOA infrastructure
        • SOA introduction has two architecture level  business service and service bus infra.
        • Start small and avoid a technical focus
    SOA can help cut project into more manageable pieces, which helps program and project managers to coordinate concurrently ongoing business projects, IT application projects, IT infrastructure projects
  • 7. SOA-Driven Project Management (2)
    • Use SOA artifacts as project control elements
      • The challenge of SOA-driven project management is not the management of individual tasks, but the coordination of multiple concurrently executed projects and sub-project
      • Service represent an ideal tool for decomposing complex system into manageable sub-system
        • Powerful tools for controlling state, integration, quality and business readiness of individual components and sub-systems
        • Well designed service provided the ideal level of granularity
        • Well designed service tend to be relatively business-oriented, it makes ideal communication tool not only between IT-people but also between non-technical people
  • 8. SOA-Driven Project Management (3)
    • Use SOA artifacts as project control elements
      • Services are ideally suited for managing runtime synchronization of sub-system.
      • Service contracts support SOA boards
        • It enables ‘Project costs and time estimation’
        • It enables ‘Project iteration and development planning’
        • It enables ‘Project test and roll-out’ planning
    < Synchronization between Development and Runtime>
  • 9. SOA-Driven Project Management (4)
    • Include service design in the project definition
      • Project definition phase contains
        • Scope, priorities, vision, major objectives, constraints and enable different stakeholder to develop and articulate a shared vision
        • Initial project plan
      • Project definition should contain a first draft of architecture, including critical service that has to be developed and included.
        • This service is distinguished by following (basic service)
          • New services build from scratch
          • New services based on existing services
          • Extensions and modifications of existing services
          • * Process and intermediary service can be designed later.
  • 10. SOA-Driven Project Management (5)
    • Leverage SOA to decompose complex system - Vertical Slicing versus Horizontal Slicing
      • Horizontal slicing makes large integration overhead.
      • In horizontal slicing ,problem is discovered only very late development cycle.
      • In vertical slicing, developers with very different skills work hand-in-hand to deliver complete end-to-end slices from application front-end to business-logic to middleware and data layer  minimize integration overhead
    * Horizontal Slicing – Layered by technical level * Vertical Slicing – Sliced by business meaning
  • 11. SOA-Driven Project Management (5)
    • Leverage SOA to decompose complex system - Thin Threaded Model
      • This is essential for “Iterative Application Development (IAD)”
      • Basic idea of the “thin tread” is “ start with very thin thread  thicken the thread  add new thread”
      • Often, initial version of thread might match an individual operation of a more complex thread, and the final iteration of thread represents the full-blown service .
      • The iteration of first thread in project will be slow
        • almost problem will be arise (session mgmt, transaction mgmt etc.)
        • The iteration of next thread will be faster (almost problem will be addressed in first iteration)
      • Combination with Vertical slicing
    업무 단위로 Vertical Slicing 을 한후 , Vertical Slice 를 Horizental Slice 로 나눠서 Layered 모델을 취하며 Horizontal Slice 의 경계는 Service Contract 를 사용한다 .
  • 12. SOA-Driven Project Management (5)
    • Leverage SOA to drive development iterations
      • In SOA project, many projects are running in parallel often over long time period .
        • Key problem is stabilization
        • Stabilization is required to decouple projects from each other , shielding each project from the dynamics of the other projects
        • Service contracts are the ideal tool for stabilizing the development processes in distributed architecture
      • Use SOA as Basis for Divide & Conquer Strategy
        • Decompose thread from vertical-slicing into horizontal-slicing .
        • Service contracts should be leveraged as the key sync point between the individual slice Each side of horizontal slice independently start development and testing of their respective pairs
        • Service contracts is boundary of horizontal slicing
  • 13. SOA-Driven Project Management (5)
    • Leverage SOA to drive development iterations
      • Use SOA to Manage Parallel Iterations
        • Service contracts enables parallel development also. It provides sync point
        • Services is developed in parallel
  • 14. SOA-Driven Project Management (6)
    • Take a step-by-step approach toward process integrity
      • Guidelines for introducing high level transactionality and process integrity to minimize cost and complexity.
        • Avoid entire system transaction.
        • Use distributed transaction in every single service.
        • Use lightweight tracing and recovery mechanism
        • Provide more details on infrastructure for distributed logging and tracing
        • Throughout Initial testing period and in early launch phase, you can find vulnerable to failure.
        • ( 이 과정에서 발생된 문제중 , 해결 가능한 문제는 원인을 찾아서 해결하고 , 복잡하고 해결이 어려운 문제의 경우 방어 아키텍쳐를 삽입한다 .)
        • Only 5-15% of system deals with modifications of mission-critical data.
        • Use high-level tracing in order to ensure that you are not missing any critical information.  It can make overload so, you can limit tracing those part that you have identified as mission-critical by using “Technical Risk Analysis”
    Technical Risk Analysis Table
  • 15. Configuration Management (1)
    • CM in SOA different from usual practice
      • Service often don not belong to a single project
      • Service infrastructure is used across all participants
      • The SOA should enable the independent development of individual services.
      • The access to source code of individual services must be controlled independently
    • Challenges for an SOA configuration management
      • In SOA not all artifacts generated by a project will ultimately be owned by this project. Instead, the services that are intended to be reused in other project .
  • 16. Configuration Management (2)
    • Recommendations for the SOA integration team
      • Create a standalone project in Configuration management for every reusable project  makes it enable to develop,maintain and deployed in independent manner
      • Create dependency matrix to keep track of dependency between services.
    Dependency matrix
  • 17. Testing
    • Testing refers to sysmetic, automated,reproducible testing rather than the ad-hoc testing approach that is still dominant in many software development
    • The service component itself is the prime candidate for functional, integration and load testing
    • Type of test
      • Load Test
      • Functional Test
    • Testing Environment
      • By human Interface
      • By test driver
      • By test robot
    • Test definition should be maintained with the actual application and service source code in configuration management.
    • Functional tests should be an integral part of any build process
  • 18. Questions?