SOA Governance and enablement strategies / Organization
- Mark Skilton
- Nov 1, 2007
- 7 min read
SOA Governance and enablement strategies
SOA governance involves the planning, discovery, design , build, deployment and ongoing operation and change management processes.
The nature of SOA means that the design and run time artefacts are not just existing in the project life cycle but become part of the organisation collateral and organisation capabilities. Manage of these becomes more that a project task but an organisational one.
Key governance processes
Business value (not academic..)
Business drivers and imperatives
Return on investment
Investment planning
Investment program (pipeline to actual programs)
Investment leakage
Enterprise Architecture
Define a EA Cube at the beginning and stick to it
Governance design authority review process
Service support process
Governance styles
Full blown SOA governance
Co-existence strategies for SOA governance (migration)
Governance in mature 2 , 3 rd generation IT landscapes (brown field)
Governance in new technology investments (green field )
Small scale governance
What is “solutions”
Define the next level down by Product e.g. WebSphere
Enable a check list of specific Vendor / Product context into the process
E.g. ERP, ESB, DoCMgT, DW, ECM, Portal, BPM, Infrastructure etc are all distinctly different in pattern design.
Financial Analysis
Bid phase
Define the Business case in business and technology terms
Often see the requirement defined in “ilities” format e.g.. I want flexibility, I want agility….
Be specific
Seek specific KPI measures to define critical success factors
Define requirements as capabilities e.g. A capability is defined by processes, technology, data, people, organisation etc , not just process or technology alone.
Building capabilities is a whole of life cycle approach:
Innovation
Procurement
Program
People / skills
Performance
Seek commercial partner strategies
Enterprise licences
CSC positioning for strategic solutions
Identify all financial variable first (before) before estimating model development input to Bid dialogue / response
Conduct pre-feasibility verifications (seek SMEs)
Seek bid verification conversations with customer
Conduct a realistic skills assessment of the bid and delivery and the customer
Don’t underestimate the
Do develop a physical volume and performance model that is linked to PD (not separate)
Use EA Sol Dir to Chair Solution Discovery Workshop (In SOA this is called a Service Discovery Workshop)
Develop the Solution Architecture as an EA Framework (POLDATS)
Use a Template WBS
Currently underestimate
Currently hap hazard approach
John Horsman (?) has a set of generic steps and a gate process
But no quality management process in place – Thye current approach confuses the generic steps and gate process for the quality process when they are two distinctly different processes and different skill sets
New generation projects need to meld process and technology together much smarter (See Gartner etc on top 10 issues in IT 2008) Currently the approach is far too PM oriented with no Solution , change or organisational transformation included
Assumes one size fits all approach which is fundamentally flawed
Wrong manage skill set involved in this process – needs to be managed by qualified Sol Directors (Not just program Manager background)
Pricing model
Is currently seriously flawed – missing huge chucks of tasks to ensure quality costs
Need to define direction of cost spend
WBS and EVM
Currently PMs using EVM approach with no control over WBS framework – assume that “spending £500,000 the result of the project must have been completed...” This makes the entire EVM process ridiculous and irrelevant
Define subprocess threads and cost these
Define releases by thread sub-components and cost these
Define SOA elements – these should be the same for all projects ??
Service discovery
Service Model
Service release model
Service design & build
Service Infrastructure
Service performance
Service run – maintain
Service Governance
Do define the scope use cases (Business and System UCs) for the Bid (Not after)
Transition from Bid to project
Use a Template WBS
Currently underestimate
Currently hap hazard approach
Success
Put in financial contingencies explicitly not overtly
Define requirements IDs to specific project PDs
Define Cross Project interfaces as separate PD
Use if possible a two phase program approach that uses all major module spends and enables POT and POC feasibility assessments before committing to detailed estimates
Define sub projects as end to end process threads NOT as technology infrastructure projects (Even GIS projects will have a process component to verify the capability)
Define financial model costs to use cases to define scope costs by UC before project kick off – Not after.
Separate the data and migration costs from the project
Separate the technology infrastructure costs from the project execution costs
Include test strategy and budget for testing including up-to and including UAT
Include EA into Project
The project needs this to define solutions to problems they uncover
Include Solution Discovery Workshop
Include performance model
Include security solution costs
Include data cleaning and preparation costs
Include training and transition to production and steady state costs (DO NOT just stand up the solution as the end point for handover).
Include BAU training and Apps support training and performance maintenance
Failure
Post bid AAR
Establish post solution and case study gap
Risk management (from adopting SOA)
From not doing SOA – increasing complexity and risk to IT estate
Commercials , level of risk/reward; penalties
Pre-completion tasks
Post-completion tasks
Visibility of what we do and what we get
Use to define contracting model
Company maturity (readiness assessment)
Mature nth generation IT
New company investment
Federated governance (matrix organisations) AMO
Local project AMO versus global central shared AMO
Procurement and technology roadmap
Development approach
RAD , JAD , Portlets
Learning & Training
Learning & Training of Operations support staff (how to run SOA platforms)
Time scale expectations
Pre-built templates and accelerators (front-end of lifecycle)
Configuration processes – (expectation that its faster) (build and change lifecycle)
3 to 4 month cycles
Collaboration
Security issues
Governance of access controls
Security standards
Link to business strategy goals and targets
Supply & demand management
Performance
Service design methods
How to design services that can be added to and developed
How to manage multiple services
How to do service version management and configuration control
Sourcing model
Shared services
Near, on and off shore services
Support model
Run / maintain
scale , change
co-existence strategy
Factory Model
Template WBS
For Bid
For transition from Bid to Delivery
For Deliver
Incremental versus larger scale effects
The city plan versus the
Enterprise architecture versus SOA technique and methods
editeur.org
publishers.asn.au
SOA Roadmap Readiness Assessment
Needs analysis
Identify key dimensions for readiness
Built in a modular way such that each dimension check list can be referenced individually to other areas.
Strategy & Culture
Enterprise Architecture Vision
Strategy alignment
Charter & services scope
Business stakeholder participation
Organisation & capability
Leadership structure & positioning
Decision structures and budget , policy, operational owners
Accountability & responsibility structures
Raci
Competency & partner model
Perception, attitudes & behaviours
Process & methodology
Architecture development
Migration & transition planning
Governance model
Escalation & exception management
Performance management
Investment justification
Performance measurement & metrics
Employee reward structures
Cost & benefit allocation model
Architecture development
Scope and bias
Deliverable & artefact creation & management
Modelling & visualisation tools
Supporting infrastructure
Imperatives for sustainability
Need to align investment with business strategies and goals, remit/scope and performance metrics in a way that is clearly understood by the customers and the business organisation
Goals and metrics process
Need to align the dimensions of change to drive sustainable change. Typically organisations focusing efforts on specific enterprise activities without having the full emit and authority over achieving complete alignment and effective change.
Alignment of domains of change process
Need a consistent way of coordinating the business and technology planning and modelling end of the enterprise architecture lifecycle span.
SOA Quickscan
Feature needs
Needs to contain the methodology for high level discovery and more rigorous service discovery.
The balance here is in using quickscan in the vendor selection and pre-project stage and then using Catalyst-SOA to do the rigorous Service discovery and design stage. (This should reference the Catalyst Systems Techniques Design document to describe this.) Catalyst-SOA would be used in the project life cycle stages.
The critical difference is that Catalyst Service model would be at the level of detail required by vendors and sufficiently detailed for practitioners to use the models and templates.
Needs to reference the service patterns library – quickscan pattern library
Needs to combine all dimensions and
Needs to be sold as an accelerator technique by providing fastrack
Need a paper on what is fasttrack characteristics
Shorter time
Simpler
Low cost , high results – 20:80
Uses pre-built templates
Leverages knowledge
Leverages prebuilt assets
Could be automated screen tools (investigate how easy it is to build a Java typetool – PCWorld or Open source coding tool ? Visual Basic)
Reliable and repeatable
Uses factory style repeatability
Focuses on key things rather then min
Builds communication and awareness fast
Is commercially compelling – easy to buy and use
Drives follow-on quickstarts
Quickscan à Quickstarts
Suppliments the early learning curve effects with
Outline Quickscan methodology
Note: this is a methodology as it combines a number of techniques and models
Business process to service identification mapping – quickscan
Business goals and metrics à Value chain à major business processes à major data and application sources à major interfaces and interactions à service candidates (using simple service pattern review)
Done for AS-IS
Identification of potential SOA candidates
Done for TO-BE
Uses service discovery matrix and service patterns library
Link to Business case and opportunity profiling to Executive
Measurement and KPI
Link to roadmaps and reference architecture models
Transition plan
Technology reference architecture
Link to e4 à e5 reference model here
Link to business change and readiness
Leadership, skills and governance readiness
Mobilisation plan – 6 to 12 months
Catalyst-SOA
Has developed Service model
Has developed definitions of service orientation and techniques description
Need to define catalyst-SOA work products to Service Discovery and design process.
Purpose is to establish how specific project deliverables are developed in this area ensuring seamless service discovery, service design and service build and delivery is contained.
Use of the service discovery Methodology in specific terms
How to relate specific WPs to a service model lifecycle necessary to support SOA
Explain how the methodology works with the context of the strategy and the
How business architecture and technology architecture are decouples through a services architecture.
How the services are managed through the wider enterprise and industry perspective
Comments