enterprise soa chapter 13

SOA-Driven Project

Management

ESOA Chapter 13

Shannon Wells

Introduction

Project Management is the discipline of

organizing and managing resources (i.e.

people) in such a way that the project is

completed within defined scope, quality, time

and cost constraints. (Wikipedia)

Manhattan Project in the 1940s

http://en.wikipedia.org/wiki/Image:Trinity_shot_color.jpg

Introduction

1970s – IT and Construction industries began to adopt methodologies

1990s – migration towards process reengineering, risk management and project offices

Generic project management tools and practices directly related to software development Gantt charts

Network diagrams

PRINCE 2

Waterfall Method

Rational Unified Process

Catalyst

http://en.wikipedia.org/wiki/Image:Waterfall_model.png

Established Project Management

Methodologies

A Software project must deal with the

conflicting requirements of time, resources and

functionality, much like project management

in other industries


Methodologies There are problems that exist in software project management

that are not necessarily present in other industries

Enterprise software is tightly coupled with internal organization, processes, and the business model of the enterprise

Example: A sports car – sophisticated engine, anti-sliding system, and exhaust reduction system, but at the end of the day the user interface is simple: brake, gas pedal and steering wheel

Enterprise software on the other hand involves a complex user interface that, at the end of the day, models the business and corresponding details, operational process and special cases in a one-to-one fashion.

http://en.wikipedia.org/wiki/Image:MclarenF1.JPG


Methodologies Software processes suffer from the I can’t tell you

what I want, but I will recognize it when I see if

phenomenon

Waterfall Method does not address this problem because it

assumes the customer requirements are fixed at the

beginning of the process and they will rarely be changed.

Because of this lack of flexibility more evolved models

have been emerging that are better suited to deal with

unstable functional requirements by using earlier customer

feedback, and short iterations


Methodologies RAD – Rapid Application Development

Developed by James Martin

Based on Incremental stages which represent a short duration waterfall

Spiral Model Developed by Barry Boehm

Bases on a full set of development cycles that continually refine knowledge of the final project and manages risk.

Rational Unified Process (RUP) Owned by IBM

Iterative, depends on visualization based on UML and uses component-based architectures

Other heavyweight iterative models Dynamic Systems Development Method (DSDM)

Microsoft Solution Framework (MSF)

Catalyst

During the Internet Revolution more lightweight approaches were adopted often called agile development Extreme Programming (XP) – uses peer programming, one focusing on coding the other

on design and testing.

dX – Developed by Robert Martin, is the middle ground between heavyweight methodologies and more lightweight agile methodologies


MethodologiesA new methodology is not needed when introducing

SOA. The best one to choose will depend on the

context of the project

XpAgile SD dX

RAD

V-Model

DSDM, MSF

Model-based

Processes;

RUP, Catalyst

Waterfall

Interactive

Linear

LightweightHeavyweight

SOA-Driven Project Management

The level to which SOA elements should be

used in project management will depend on the

expansion phase that the enterprise is currently

in


When looking at SOA-driven project

management, it is important to remember that

SOA introduction happens on many different

levels within an enterprise


IT program versus IT project management

Program management involves the management of

multiple IT projects.

SOA artifacts can be used to control individual projects

and sub-projects within them as well as to coordinate

multiple projects on the program level.


Business services versus SOA infrastructure

SOA introduction has 2 architectural levels: business

services and the required service bus infrastructure.

The level to which SOA can be leveraged for project

management purposes will depend on expansion stage.

Early stages need to start small and avoid being over

technical, while later stages can add more functionality

to the initial platform.


Use SOA Artifacts as Project Control Elements

A key issue in software development is the mapping of key

project control elements (tasks, work breakdown

structures, etc.) and software artifacts (program code, data

models, specifications, and the relationships between

these).

The main challenge with managing SOA projects is not the

management of individual tasks, but the coordination of

multiple concurrently executed projects and sub-projects.

Services in SOA represent an ideal tool for decomposing

complex systems into manageable sub-systems.

GranularityEnterprise IT

landscape

Application

instance

Program

Management

Project

Management

Task

ServiceService

instance

Class

Table/Transaction

Function

LOC

Development Runtime

Different levels of

granularity of software

artifacts at development

and runtime


Another important factor is the fact that most Enterprise-

level software has to be synchronized during development

time and also during the lifetime in a production

environment – SOA is perfect for this

Services have the ideal level of granularity and business

orientation for driving many aspects of a project including:

Project cost and estimation

Project iteration and development planning

Project synchronization

Project test and rollout planning


Include Service Designs in the Project Definition

It is logical that each project definition should contain a

high-level service design

The project definition phase should answer the questions:

What is the Scope of the project?

What are the priorities?

Services are the perfect granularity for use as a

communication tool in this phase of development

In an SOA-driven project, the project definition should

contain a first draft of the architecture, including critical

services.


Leverage SOA to Decompose Complex Systems A key problem in the early phases of development is the

need to find a good way of decomposing systems into manageable parts – SOA is well suited for this

Vertical Versus Horizontal Slicing Horizontal Slicing – usually represents a particular technical tier

such as an interface, presentation layer, business logic, middleware, data management, and so forth

Vertical Slicing – Represents specific business use cases such as open account.

When using horizontal slicing, developers with different skills work together to complete end-to-end slices. This approach minimizes the integration overhead between components of the horizontal slices

User Interface

Presentation Layer

Business Logic

Integration Middleware

Data Access Layer

Data Management

Technical

layers:

“Horizontal

Slices”

Business use Cases: “Vertical Slices”


Thin Thread Model The “thin thread” development and project management model is

an application of the Iterative Application Development (IAD) approach and is a vertical slicing approach.

The “thin thread” approach is specifically suited for IAD in the context of SOA.

The basic principal is to start with a very thin thread, or vertical slice, in the next phase the thread is thickened by adding more end-to-end functionality, as the project continues more and more thread can be added and thickened.

The initial thread is often an individual operation of a more complex service, while the final iteration would be the full blown service.

The first thread is often slow moving, while as more threads are added, a more aggressive rollout of threads can start

The number of concurrently active threads

varies over time

Month Number of Threads Description

1 Start up and set up

2 First implementation of end-to-end

thread, including scalability test and

feedback from end user/customer

3 Ramp up of thread development and rollout

4 Implementation and unit test

phase, including nightly builds and test runs

5 Horizontal integration fine tuning

6 Hand-over/rollout


Leverage SOA to Drive Development Iterations

Because SOA is aimed primarily towards Enterprise-level

development projects, there are often situations where

many projects are running in parallel over a long period of

time

The main problem with these situations is the stabilization of the

development process, to shield each project from the dynamics of

the others.

Service contracts are the ideal tool for stabilizing the development

process for distributed architectures. Projects and subprojects

should evolve in parallel along with the service contracts they

share.


Use SOA as the Basis for Divide and Conquer Strategies

Often the vertical threads need to be divided into development tasks

or horizontal slices. This should be the next step after the initial

vertical slicing.

The problem with horizontal slicing is the integration between the

individual slices. To solve this problem, the service contracts

should be used as a sync point between the slices.

Use SOA to Manage Parallel Iterations

Service contracts can serve as the basis for multiple service

implementations that are developed in parallel. First you can

analysis multiple applications, plan iterations

simultaneously, define the services together, then develop the

application and services together and finally integrate and test.


Take a Step-By-Step Approach Toward

Process Integrity

One key idea is the trade-off between process

integrity and related costs. We can achieve

optimal process integrity if we are willing to pay

for it. However, most “normal” budgets cannot do

this. Therefore, failures must be planned for


There are guidelines for introducing process consistency, which will minimize the cost and complexity of development

Build the system based on lightweight tracing and recovery mechanisms

As long as the problem can be traced, it can be manually fixed

When frequent failures in a service occur, analyze common or likely failure situations and provide recovery mechanisms.

The number of services or processes that require specific transaction or recovery mechanisms will be low because only a small amount of the functionality deals with modification of data, the rest of the functionality generally has a read-only or administrative purpose.


Using these guidelines should allow you to analyze risk and focus on them from a process integrity prospective

Decompose your system

Create the first service design in the project definition phase

Decouple development teams by service contracts

Apply a thin thread approach

Leverage reuse whenever technically and economically feasible

Renovate and simplify your architecture step by step

Involve the business department

Utilize improved documentation provided by service contracts

Create a regression test environment for services

Configuration Management

Software Configuration Management is the discipline whose objective is to identify the configuration of software at discrete points in time and to systematically control the changes to configuration for the points of maintaining software integrity, traceability, and accountability throught the software cycle. –Bersoff, Henderson and Siegel 1997

SOA Configuration management is sometimes different from the usual practice Usually Configuration Management systems create a single repository,

however this is not practical for SOA because: Services often do not belong to one project

Service infrastructure is used across all participants of SOA

The SOA should enable the independent deployment of individual services

The access to the source code of individual services must be controlled independently


Challenges for an SOA Configuration Management

Often services will not be owned by one project; instead they are owned by the organization and can be used for multiple projects.

SOA focuses on reuse in runtime environments, not just the sharing of libraries

It seems beneficial to be able to maintain, build, release and deploy all shared services and the supporting code independently from each other.


There is no real need for one enterprise-wide CM

management system to manage all of the

containers.

This can actually be a good thing, as certain CM

environments might be better suited for creating Java-

based Unix service systems, while other are better

suited to support C++ based Windows services, etc.

While it is not always possible to throw away the

existing CM infrastructure, it can be revamped to

become more suitable for use with SOA.


Runtime reuse, as it is used in SOA, requires a dedicated version of management. It requires a tight tracking of the dependencies of individual software artifacts. This includes: information about which application frontend or service versions

are compatible with other service’s versions

The dependency on versions of libraries and runtime environments

CM of SOA does not require the creation of a complex interoperability matrix, it just requires a few important decisions to be made A documentation of dependencies between runtime components is

required

This documentation belongs to a central and easily accessible place

The information provided by such a documentation is particularly required for multi-project management

An SOA leverages a scenario in which multiple

projects typically share common services

Project

Project

Project

Project

Project

Project

Project

Project

Service


Recommendations for SOA Integration Team Although the creation of a structure for configuration

management is a difficult problem, it is actually a benefit of an SOA in that it highlights the parts of a project that should be grouped together in their own CM containers.

Division of SOA into different CM projects happens naturally from the bottom up. All basic services are placed in their own CM container

Some intermediary services that are closely related together should be put in the same container

Where appropriate, the application frontend and related project specific services can be grouped together - often based on the functionality that they offer

Start with a CM container for each reusable service and work upwards

Testing

Testing is the major quality control tool in any

software development

Testing refers to the

systematic, automated, reproducible

testing, rather than the ad-hoc testing approach

that is still dominant in many software

development efforts.

Testing

Testing can be broken into two defined different categories

Load Testing means testing a component under a specific load for a defined time. It is crucial to judge whether the software can meet any required SLAs. Load testing requires that the testing be conducted in an environment where all backend systems of the component are available and perform and scale as they were meant to in the environment

Functional Testing means ensuring that the operational results of the software component are consistent with expectations. Functional tests execute a single call with a given set of parameters and that then compare with the expected result of this call.

End-to-end functional testing consists of testing the individual service and verifying that the application functions as it is supposed to.

Testing

Some overlap exists between functional testing and

load testing

Test Design is by no means easy because any

functional test must be reproducible and must achieve

as much coverage as possible. Building tests is

development in its own right and might require

building dedicated software components.

To perform testing in a more meaningful manner, the

test should be automated using a test driver.

Testing

Regression testing – testing that ensures that a new

software component is “backward-compatible” by

setting previously used parameters in a new service

and receiving the expected output. Regression load

testing can also be performed.

Some popular testing tools include Mercury

Interactive LoadRunner, the Grinder, and Jmeter.

Testing can also ensure the confident reuse of the

service

Conclusion

SOA does not require a new project

management methodology

SOA-driven project management does require

adopting a set of useful, SOA-specific

practices that can be used with existing

methodologies

Conclusion

The core of SOA-driven project management

are SOA artifacts: services, and service

contracts

SOA enables enterprises to put an efficient

configuration management in place

Service-driven regression testing is a key

factor to SOA success.

enterprise soa chapter 13

Documents