1/31/2008
Hard Problems in SOA Workshop
January 30, 2008
Pittsburgh, PA
Terry Balven, USAF
Don Beynon, SEI
Charise Bittner, IBM
Michael Bridge, UPMC
Glen Colby, USN
Kevin Cooly, US Navy
Alan Danziger, MITRE
Brian Dahl, UVA
Sudha Durairaj, CMU
Michael Hogan, Boeing
Terrill Frantz, CMU
Rick Kotermanski, Summa
Ken Kunkel, IBM
Steve Lambourne, IRS
Grace Lewis, SEI
Dan Makanoff, CSC
Sugandh Mehta, IBM
Eric Meredith, PNC
Austin Montgomery, SEI
Tricia Oberndorf, SEI
Mark Olson, IBM
Steve Palmquist, SEI
Robert Petty, Northrop
Grumman
Hans Polzer, Lockheed Martin
Kimberly Rabe, IRS
Bob Rosenstein, SEI
John Sautter, Northrop
Grumman
David Scherb, SEI
Paul Schoen, Boeing
Jeannine Siviy, SEI
Ken Trzaska, USSOCOM
Ananth Vasishta, Boeing
Brian Weston, DDFI
Carol Woody, SEI
Joanne Wright, UPMC
1
1/31/2008
SOA strategy definition
◦ Strategy definition—business, technical, organizational,
communication changes
◦ Scope of services—specialized vs. generic, granularity,
consumer community
◦ Incremental organizational transformation
Applicability of SOA
◦ When does it reach its limits? e.g. scalability.
Operational effectiveness
◦ ROI on SOA adoption
◦ Metrics—how to define and how to share metrics
◦ VOI
More guidance for acquisition of services and
service-oriented systems
◦ Better acquisition and requirements language
◦ How to translate business language into DoD and
government language
Incentive models for SOA adoption
◦ Build vs. buy—How do you fund shared services?
Lessons learned from the service industry
◦ Reuse of service industry patterns, e.g. industrial
engineering practices
Open strategies
◦ How to solve the “unanticipated user” problem?
◦ How do you measure openness?
◦ How to avoid vendor lock-in?
2
1/31/2008
SOA covers so many areas that it is impossible to
take a “big bang approach”
◦
◦
◦
◦
◦
◦
Business changes
Organizational changes
Scope of services; granularity
Communication changes
SOA representation
Technical changes
Requires an incremental organizational
transformation that should be reflected in the
strategy
◦ All aspects will not be in place at once
◦ The whole premise of SOA is incremental deployment and
agility
◦ Risk mitigation
◦ It cannot take 20 years to deploy systems
There is not one strategy
◦ Will depend on drivers for adoption
There are lots of efforts relying on SOA
◦ From a DoD perspective we can lose the next war
◦ From an industry perspective we can go out of
business
We need to do it right!
3
1/31/2008
Practical Guide to Federal SOA
AFEI effort to provide acquisition guidance for services
The next evolution of HL7 will be looking at Web Services
NCOIC is defining framework for describing the operational extent,
degree of accessibility over a network and feasibility for services
Unified Battle Command is looking at how SOA gets addressed across
the Army
Open Architecture initiative in Navy is addressing SOA
CANES is another initiative in the Navy to deal with consolidation of float
networks
Organizations basing strategies on use of Google services
Federal CIO Council is defining a services and component based
architecture
Department of Education—Office of Student Financial Assistance
Collaborative Warfare Environment
NCES
NCIDS
Hard to find real cases with real numbers on ROI
◦
◦
◦
◦
How do
How do
How do
How do
you measure agility, flexibility and reliability?
you compare against data that you do not have?
you balance against other tradeoffs?
you validate?
Now we buy systems one at a time, not with a
capability or enterprise perspective
Funding models are incompatible with the SOA
paradigm
◦ ”Tight systems” are preferred
◦ Initial ROI is low because there is a lot of investment in
architecture and design
◦ No mechanism for incentivizing or enforcing crossorganizational agreements
◦ Funding is allocated top-down
4
1/31/2008
Resistance to giving up control
◦ Organizations do not want to be dependent on others
◦ Too much risk
◦ Localization
Resistance to having control
◦ Organizations do not want to take responsibility for
being on someone else’s critical path
◦ No incentive for being a service owner
Different agendas for a service
◦ Stakeholder priorities—not everyone is interested in
optimization, for example
Organizations do not bring in the right expertise
Education for sponsors and management
◦ Done in business terms and not technology terms
Define models to express ROI in terms that
decision makers can understand
Specific lessons learned and case studies—
both the good and the bad
5
1/31/2008
SOA is not “one size fits all”
◦ Result could be failure
◦ Tight coupling has benefits
If the organization is not willing to change, it is
going to be a “force fit”
There need to be ways to express cases in which
SOA is applicable and cases in which it is not
◦ Patterns and anti-patterns
◦ Probably involves domain, organization, environment
and size
There should also be guidance on where to start
◦ For what areas of your organization is SOA most
applicable—to drive incremental strategy
CMU is putting together a solution outline
assessment for applicability of SOA for their
student information system
Navy is working on scalability limitations
The Kuali student system is an effort to
develop services for student systems
Evaluating SOA report from the SEI—looks at
quality attribute tradeoffs
AFEI is working on characterization of
services from a business model perspective—
service attributes
6
1/31/2008
Hype around SOA—everybody wants to be “on
the bandwagon”
Lack of agreement on what SOA is
Decision makers not educated on the business
implications of SOA
Awareness of commonality
◦ Goal is not breaking up stovepipes—it is making
stovepipes aware of each other
Not many demonstrated successes that show
where it is applicable
Business model for services is not well defined or
understood
People have a hard time understanding how
distributed development and deployment is
Technologies and best practices are still not
mature
Lack of industry patterns and templates for
SOA-based systems and elements
7
1/31/2008
More studies
Define attributes of the problem space that
tell you where SOA is applicable
Core motivation for any organization to
invest in SOA
Creates the justification for investment in the
future
Shows alignment between business objectives
and technology
Better decision making and communication of
rationale for decisions
“You can’t manage what you don’t measure”
Provides accountability and transparency
8
1/31/2008
Capability-based planning and analysis
efforts—not specific to SOA
Multiple case studies: HP, IBM, banks, etc.
Effect-based operations
Michael Mann (USC) research on technology
value using asset management terms
TMAP (from University of Cambridge)—
Technology Management Assessment
Procedure
Hard to define cost for things that are outside of
organizational boundaries, such as shared
services
In case studies, it is difficult to separate what is
BPR vs. SOA adoption
Difficult to define non-financial value, e.g. value
of agility
Changing the environment
Quantifying value is difficult in DoD
environments
How do you use metrics to influence decisions—
cycle times are long in current acquisition models
9
1/31/2008
Engage business leadership in the definition of SOA
strategy
Get technology input upfront to increase operational
effectiveness, e.g. feasibility or maturity of
technology to accomplish X
Get service providers in contact with service
consumers—not common in current acquisition
models
Make scope assumptions explicit in services
Create a baseline of what you really have and what
you are really doing to do real analyses
◦ Focus measurement on what matters to them
◦ Make role of business process analyst more visible
Outreach to Ops analysts and MBA types
10