Microsoft SOABPM UK Conference

1
Microsoft SOA/BPM UK Conference

• British Energy Power Energy Trading
• Case Study Developing an Agile Business through
  the adoption of SOA driven architecture and a
  federated ESB model
• 14th November 2007

2
Introductions
3
BE and BE Power Energy Trading

• British Energy
• the lowest carbon electricity generator in the UK
  supplying a sixth of the nation's power
• we help UK business reduce energy related carbon
  emissions by up to 98
• 8 nuclear and 1 coal fired power station
• BEPET manages all routes to market
• Wholesale
• predominantly power but also coal, gas,
  emissions, renewable energy
• structured increasingly with financial
  institutions
• Retail (BE Direct)
• large industrial commercial sector
• over 50 of generation is backed by retail sales
• over past 7 years consistently voted No1 for
  customer satisfaction by UK industrial and
  commercial energy users
• 250 staff, 250 metres of office, 2.5bn
  turnover

4
Our IT Landscape

• Large ,complex application landscape lacking
  strategic business alignment
• Industry mandatory processes to interact with the
  market
• Unique added value bespoke application
  development
• Combination of financial market commodity
  trading type systems and traditional retail
  end-to-end bid to bank processes
• Combination of real time and batch processing
• Critical high availability systems to support 24
  by 7 trading operation
• High level of ongoing change and business
  development
• Flexibility and agility are key

5
Capability vision Controlled Agility

• Increased competition
• The Energy Review
• Ageing nuclear fleet but knowledge is a key asset
• Positioning to be the partner of choice for
  investment in new nuclear build
• To become First in UK Power
• In summary..
• We need to demonstrate our business capability
• We need to re-factor, renew and adjust our
  processes, people and technology
• We will demonstrate technology leadership

6
Hmmmthat sounds like
7
Why SOA?

• Re-balance the factory to value ratio
• what we refer to as the hands versus heads
  strategy
• re-channel our energy into things that add real
  value
• Automation of low value-add activity
• Agile business model
• able to adapt quickly to change process and add
  business capability
• need a business and IT architecture to match
• business capabilities and process management are
  a key focus
• But, we want to adopt a pragmatic approach to the
  application of SOA

8
The application of SOA in BEPET

• Close collaboration between Business Design and
  IT within the same organisation, use of an
  Enterprise Model to capture the architecture
• We have defined business capabilities with a
  structured hierarchy (top down)
• We map processes and relate them to capabilities
• We then establish business service catalogues and
  service realisation and service decomposition
  maps
• Services are categorised as
• value services i.e. ones that can be executed by
  knowledge workers
• factory services i.e. ones that can be automated
• a business service may be human, information or
  functional
• Business services are business processes
  decomposed to a level when they can be considered
  self contained independent (the outsource
  test)
• Technical services are the technology components
  that support a business service (bottom up) -
  bespoke or application components
• Service portfolio planning forum to bring the top
  down and bottom up analysis together

9
The Need for an ESB

• Provide support for design through governance and
  patterns
• Ensure simplified project delivery in the
  integration and service space
• Provide a consistent support method for all
  message flows in the enterprise
• Allow monitoring of all integration points in a
  consistent manner
• logging
• auditing
• KPI measurement
• Support a common scalable platform for
  integration that can grow with the business
• Free BEPET to select the most appropriate product
  delivery regardless of integration strategy
  supported by candidate products
• Provide a platform that enables agility in terms
  of swapping out product sets whilst minimising
  impact on other systems in the enterprise

10
ESB Key Capabilities

• Brokered communications
• Decoupling
• Transformation, validation and adaptation
• Metadata driven service contracts, policy,
  bindings
• Based upon standard based web services
• Strong security (transport and message)
• Centralised operational management and control

11
ESB Implementation Overview

• WCF-based
• Simple consumer-side component
• Channel constructed from information in UDDI
  (cached)
• Logging and tracing via Enterprise Library
• Trace based on WCF for correlation
• ASMX interop and retro-fit to non web service
  capabilities (BizTalk)
• Management interface

12
Unified Programming Model
.NET Remoting
Extensibility Location transparency
13
Address, Binding, Contract
14
Management and Service Registry capability

• SCOM and UDDI provide main infrastructure
  capability
• All services and consumers managed in a
  consistent manner in SCOM
• .Net 2.0 / WCF services surfaced identically in
  SCOM for management
• desire to extend this out to cover other
  platforms in our environment.
• key driver for BEPET ESB is this consistent
  support approach
• All service endpoint details stored in UDDI
• all service contracts and policies are published
  to UDDI to make the service ESB addressable.
• desire to make further service type capabilities
  available in UDDI
• Desire to extend UDDI Service Registry to store
  more complex routing / transformation rules
• still in the design phase
• likely to bring custom canonical mapping to
  clients and consumers via configuration
• possibility of bringing publish subscribe
  capability to core ESB capability rather than
  depending on BTS in simple cases.

15
Logical Architecture
Contract PolicyRepository
AD KDC
Service Registry
Central Logging Service
Consumer
Service
BizTalk
Management (SCOM)
16
Logical Service Registry Structure
Contract Guid -gt Contract WSDL
Binding Binding WSDL (Policy) Address
Binding Binding WSDL (Policy) Address
17
Physical Registry Structure
18
Centralised Logging Service

• Enterprise Library (out of the box)

19
ESB Consumer
Service Registry
ESB Channel Factory
Create Channel
Contract tModel Cache
Channel Factory Builder
Instance List
Register with SCOM
UDDI Interface
Factory ProxyCache
Binding tModel Cache
Abort
WSDLCache
Close
Service Cache
Channel Stack
Other Protocols
Logging
Contract PolicyRepository
Encoding
Transport
20
Management Interface

• WCF channel
• Hosted in any ESB node
• Node must start and stop it
• Publish-Subscribe model (initially publish only)
• Distribution nodes to avoid multicast, implement
  same management interface contract.
• Two-way operations
• status inquiry
• One-way events
• clear cache, change tracing levels
• ASMX implementation (SOAP Extension)

21
Mapping to ESB Capabilities

• Brokered communications
• ESB consumer component
• Decoupling
• WCF
• Transformation, validation and adaptation
• BizTalk
• Metadata driven service contracts, policy,
  bindings
• WSDL, UDDI, consumer component and WCF
• Based upon standard based web services
• WCF
• Strong security (transport and message)
• WCF
• Centralised operational management and control
• SCOM, management interface

22
Backlog Items

• BizTalk on and off ramps in SCOM
• and others such as SSIS
• Self registering capability
• consumers and services
• leads to publish subscribe capability
• Enhanced governance and development tooling
• Enhance governance around test and security
  guidance
• Push some configuration out into XML files for
  improved platform support
• Implement mapping capability in ESB consumer /
  service extension

23
Lessons Learned 1

• WCF is great for abstracting details away from
  consumers, and easy to add custom policies
• Quick developer ramp up time on WCF leads to high
  productivity
• UDDI can be a bit slow, need to cache metadata,
  but that then needs management
• Management is hard to even define
• When does it become governance, and what exactly
  is governance?

24
Lessons Learned 2

• Must keep it really simple for the developer
• Requires guidance automation
• Must not add unnecessary overhead, especially
  latency
• Particularly for synchronous scenarios

25
Microsoft SOA/BPM UK Conference

• British Energy Power Energy Trading
• Case Study Developing an Agile Business through
  the adoption of SOA driven architecture and a
  federated ESB model
• 14th November 2007

Questions ?