top of page

SOA Governance and enablement strategies / Organization

  • Writer: Mark Skilton
    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


Featured Posts
Recent Posts
Archive
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

Mark Skilton    Copyright 2019  ©

  • White Twitter Icon
  • White Facebook Icon
  • White LinkedIn Icon
  • White YouTube Icon
  • White LinkedIn Icon
bottom of page