pooya darugar architect, microsoft gulf. what is soa, what isn’t soa the important a in soa ...
TRANSCRIPT
SERVICE ORIENTEDARCHITECTURE
Pooya DarugarArchitect, Microsoft Gulf
Agenda
What is SOA, What isn’t SOA The important A in SOA Business Modeling How to get started The forgotten aspects of SOA
SOA is simply….
What about all those buzz words and complicated
specs I keep hearing about??
A design philosophythat leverages existing investmentsin the creation of flexible solutions that are more responsive to your
business needs
1. SOA is a design philosophy independent of any product, technology or industry trend
2. SOAs may be realized via web services but using web services will not necessarily result in a SOA
3. EDI and CORBA were early examples of SO
4. SOA is not a methodology
5. SOA should be incremental and build on your current investments
6. SOA can be done in house
7. SOA is a means, not an end
1. SOA is a technology
2. SOA requires Web Services
3. SOA is new and revolutionary
4. SOA ensures the alignment of IT and business
5. SOA requires a complete technology and business processes overhaul
6. SOA requires an army of consultants
7. We need to build a SOA
FactsMyths
Common Myths about SOA
Deliver a solution, not a SOA
Traditional model
UserAssign ID
Check Knowledgeb
ase
Solve Proble
m
Bill Customer
Assign ID
Check Catalo
g
Check Invent
ory
Bill Customer
Data Entities LoB Systems SecuritySecurityLoB Systems Data Entities
AdapterAdapter BP Platform
LoB Systems
SOA Applied
User
LoB Systems
Billing Service
IDService
DataServices
CustomerService
ProductService
Security Service
Service Agent
How do you get there?
User
Data Entities LoB Systems SecuritySecurityLoB Systems Data Entities
Billing Service
IDService
SOA Applied
Step 1: Ignore Solution Boundaries
Step 2: Group Similar Functions, Expose as a Service
LoB Systems
Billing Service
SOA Applied
User
Data Entities LoB Systems SecuritySecurityData Entities
Step 3: Hide data source behind services
IDService
DataServices
LoB Systems
Billing Service
SOA Applied
User
Entities LoB Systems SecuritySecurity Entities
Step 4: Expose Entities as Services for “Single View” of Customer, Product, others…
IDService
DataServices
CustomerService Product
Service
LoB Systems
Billing Service
SOA Applied
User
LoB Systems Security Security
Step 5: Hide security behind reusable services
IDService
DataServices
CustomerService Product
Service
Security Service
LoB Systems
Billing Service
SOA Applied
User
LoB Systems
IDService
DataServices
CustomerService
ProductService
Security Service
Service Agent
Step 6: Use service agents for dynamic assembly of rich user experiences across multiple devices
AdapterAdapter BP Platform
LoB Systems
Billing Service
SOA Applied
User
LoB Systems
IDService
DataServices
CustomerService
ProductService
Security Service
Service Agent
Step 7: Use a BP Platform for aggregating services into workflows and integration with legacy systems
AdapterAdapter BP Platform
LoB Systems
SOA Applied
User
LoB Systems
Billing Service
IDService
DataServices
CustomerService
ProductService
Security Service
Service Agent
Step 8: Optimize infrastructure to take advantage of the services-based environment
SOA – what will it deliver?
What have we really created: Modeling the business Re-usable components
Agility
16
Modeling Systems - The Classic Way
Business Model
TechnologyModel
System Model (Classic Client-Server Based)
17
Why Do Business and IT Miscommunicate?
Business people are not good at explaining what they do Often fail to distinguish between what they do and how
they do it Use jargon and assume a level of basic knowledge
IT people are not good at explaining what they do Often fail to express strategies in terms of business
value Use jargon and assume a level of basic knowledge
Important to finally fix this because the role of IT is changing: Used to be cost reduction Now it is a major business differentiator
18
Modeling Systems - The Modern Way
Business Model
ServiceModel
TechnologyModel
System Model (Modern Service Based)
The service model is the common ground between business and IT
19
Modeling Systems
Business Model
What Capabilities
How Business Processes
Technology ModelService
Interface
Orchestration Engine
Service ImplementationService
Host
Service Model
Service Contract
Orchestration
Service Management
SLA
SLE
20
Modeling Systems
Business Model
What Capabilities
Technology ModelService
Interface
Orchestration Engine
Service ImplementationService
Host
Service Model
Service Contract
Orchestration
Service Management
SLA
How Business Processes
SLE
21
Microsoft Motion Business Architecture Modeling
Has two major constituents: A capability map describing business capabilities A simple, short, prescriptive process of analysis
Exploits insights: Business capabilities are relatively stable and enduring
Helps address two fundamental problems: IT projects constantly repeat themselves… … and only rarely introduce true business innovation
22
Motion Overview Motion is
Patent-pending business architecture model with tools Set of heat mapping tools Training classes for using the model and the tools endorsed by the creators of Six Sigma and Business Process
Reengineering Motion delivers
Business architecture map (with properties) Project recommendations – what to change in terms of
people, process, and IT, in the context of cost, benefit, and risk
Several forms are available 2-4 week business architecture training projects Motion Methodology – one or all four phases, usually two
weeks per phase Not strategy consulting – it is business consulting Proven Mature
23
Capability Maps
DevelopProducts &Services
Plan andManage theEnterprise
GenerateDemand
DeliverProducts &Services
CustomersCustomer-
FacingChannel Partners
Financial Providers
Governments(regulation and infrastructure)
Sup
plie
rs
Log
isti
cs
Pro
vid
ers
Collaborate
24
Capability Maps
DevelopProducts &Services
Plan andManage theEnterprise
GenerateDemand
DeliverProducts &Services
CustomersCustomer-
FacingChannel Partners
Financial Providers
Governments(regulation and infrastructure)
Sup
plie
rs
Log
isti
cs
Pro
vid
ers
Collaborate
3. Deliver Products and Services1. Provide Service2. Advanced
Planning3. Procurement4. Produce Product5. Logistics
3.3 Procurement1. Sourcing and
Supplier Contract Management
2. Purchasing3. Receiving of
Indirect/ Capital Goods
3.3.2 Purchasing1. Request
Resources2. Acquire/Purchase
Resources3. Manage
Suppliers3.3.2.1 Request Resources1. Create Purchase
Requisitions2. Manage Requisition
Approval Process3. Perform Encumbrance
Check4. Create Auction Bids
25
Anatomy of a Capability
StartStart
People
Procedures
Technology
26
DevelopProducts &
Services
Plan andManage the
Enterprise
GenerateDemand
DeliverProducts &Services
Customers
Customer-Facing
Channel Partners
Financial Providers
Governments
(regulation and infrastructure)
Supp
liers
Logi
stic
s Pr
ovid
ers
Collaborate
What Use is a Business Architecture Model?
Value proposition Operating model
Capabilities
MetricsIT project portfolio
IT projects
SOA
Outsourcing
Partnerships
Offshoring
Self-service
Ways to approach SOA
Top Down – eg. Motion Bottom Up
Moving to SOA: The Top-Down Approach
How it works: Define a business architecture
Using, for example, Microsoft’s Motion methodology Discover what services are required Create service-oriented apps based on this
Pros: It’s elegant, clean, and sensible
Cons: It’s very difficult in most organizations
Getting the up-front funding and business buy-in is tough Keeping up with business change is also tough
Moving to SOA: The Bottom-Up Approach
How it works: Build a service-oriented app Then build another one Next, work on central SOA issues, e.g., security
and management Then build another service-oriented app . . .
Pros: It’s the only approach that has worked in most
organizations Cons:
It’s an inelegant, piecemeal way to address the problem
SOA ApproachMiddle-out (Real World SOA)
SOA is about Agility Agile principles
Requirements will change Feedback, feedback, feedback! Measurement and Adjustments Get good people to work together effectively
SOA center of excellence Holistic view but choose part of the
business Start small then scale-up
Pragmatism Oscillate top down/bottom up
Things to Consider
Entity Services
Process Services
Infrastru
cture
Serv
ices
Clients and Agents
TechnologyArchitecture
InformationArchitecture
Activity Services
Service-Oriented Analysis Issues
Entity Identification
Entity Factoring Service
Identification Service Factoring Process
Specification Endpoint
(Touchpoint) identification
Role Mapping SLAs …
Service-Oriented Design Issues Schema definition Message
definition Contract definition Message handling Process
management Transaction model Operational
compliance Exception
handling Message to Object
mapping Refinement of
Analysis …
Contracts
Service
Service
Process
DocumentA
DocumentC-1
DocumentC-2
DocumentB
EitherC-1 or C-2
Process
Service Operations Issues Security Access control Monitoring Management QoS and SLA
enforcement Versioning Scalability Dealing with
unreliability Exception routing Caching
Service
Service
Message Processing Infrastructure
Message Processing Infrastructure
Serialize
Encrypt
Sign
Deserialize
Authenticate
Authorize Audi
t
Log
Reliablemessagin
g
Deciding Which Services to Expose
This is the hardest aspect of building a service-oriented application And almost nobody has much experience
The goal: define the right use cases for future apps that will use these services
Some suggestions: Expose business logic via a services wrapper
Don’t expose objects directly Expect to make mistakes
And be supportive when your customers screw up Don’t let developers decide which services to
expose Start with the Contract and Schema
Use industry standards if available
What About Business Analysts?
Some organizations have people in a business analyst role In a service-oriented world, they’ll matter
more Where BAs can potentially help:
Defining services Creating and updating process logic
(orchestrations) Defining and modifying business rules
SOA – Organizational Commitment
SOA and Web Service Advantages are Not Automatic
Reality is, benefits are often only realised when combined with
Change in culture Investment in future needs, not just today’s short term
issues Proper understanding of business requirements (today
and tomorrow) Careful analysis and system design Flexible and agile implementations using appropriate
technology and componentization Business Process Re-engineering Business commitment and involvement Adequate funding recognising changes in ownership and
responsibility
Summary
SOA is about Architecture
Service Oriented Infrastructure make the plumbing for SOA easier This is the part you can buy from a vendor
SOA - business modeling, service modeling Motion
Real World SOA – middle out approach
It doesn’t end there Developing services is the easy part Managing and governing them in a loosely coupled world is much
more complex
