Enterprise SOA Chapter 13
Transcript of 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
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
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
Established Project Management
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.
Established Project Management
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
Established Project Management
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
Established Project Management
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
SOA-Driven Project Management
When looking at SOA-driven project
management, it is important to remember that
SOA introduction happens on many different
levels within an enterprise
SOA-Driven Project Management
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.
SOA-Driven Project Management
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.
SOA-Driven Project Management
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
SOA-Driven Project Management
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
SOA-Driven Project Management
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.
SOA-Driven Project Management
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”
SOA-Driven Project Management
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
SOA-Driven Project Management
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.
SOA-Driven Project Management
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.
SOA-Driven Project Management
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
SOA-Driven Project Management
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.
SOA-Driven Project Management
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
Configuration Management
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.
Configuration Management
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.
Configuration Management
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
Configuration Management
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.