2. Session Description
• The central notion of integration is to create an enterprise that can
effectively exchange information and behavior to drive core business
processes. While integration is a known science, the business value of
integration is something that most have not yet defined, but is critical to the
success of any ongoing SOA or integration effort. Indeed, most will find that
the value of integration is very high, as is the strategic ability for IT to align
effectively with the business.
• In this keynote presentation we’ll understand the core concepts around
integration, including how it meshes with SOA and enterprise architecture.
Moreover, we’ll provide an approach to defining the value of integration,
step-by-step. From the alignment with business, to the ongoing efficiencies
that integration provides.
4. So, Why Integration and SOA?
• Improved Adaptability and Agility
– Respond to business needs in near real-time
• Functional Reusability
– Eliminate the need for large scale rip and replace
• Independent Change Management
– Focus on configuration rather than programming
• Interoperability instead of point-to-point integration
– Loosely-coupled framework, services in network
• Orchestrate rather than integrate
– Configuration rather than development to deliver business
needs
5. The Value Proposition of a SOA
• We implement SOA for two major reasons.
– First is the ability to save development dollars
through reuse of services.
– Second is the ability to change the IT
infrastructure faster to adapt to changing
needs of the business, or agility.
– Enhance, not replace, existing EA.
(More on this later)
6. SOA Meta Model
Monitoring/Event Management
Process/Orchestration
Governance
Security
Services
Data Services/Messaging
Data Abstraction
Data Data Rep
Legacy Legacy
New Services
Copyright 2007 The Linthicum Group, LLC
7. The Economics of Integration
The Relative Costs of Different Integration Approaches
Custom Integration
Relative Costs
Initial Costs Customization Maintenance Changes
Copyright (C) 2002 ZapThink, LLC
7
8. The Economics of Integration
The Relative Costs of Different Integration Approaches
Custom Integration
Traditional EAI, B2Bi
Relative Costs
Initial Costs Customization Maintenance Changes
Copyright (C) 2002 ZapThink, LLC
8
9. The Economics of Integration
The Relative Costs of Different Integration Approaches
Custom Integration
Traditional EAI, B2Bi
Web Services quot;Adaptersquot;
Relative Costs
Initial Costs Customization Maintenance Changes
Copyright (C) 2002 ZapThink, LLC
9
10. The Economics of Integration
The Relative Costs of Different Integration Approaches
Custom Integration
Traditional EAI, B2Bi
Web Services quot;Adaptersquot;
Service-Oriented Integration
Relative Costs
Initial Costs Customization Maintenance Changes
Copyright (C) 2002 ZapThink, LLC
10
11. The Economics of Integration
The Relative Costs of Different Integration Approaches
Custom Integration
Traditional EAI, B2Bi
Web Services quot;Adaptersquot;
Service-Oriented Integration
Relative Costs
Initial Costs Customization Maintenance Changes
Copyright (C) 2002 ZapThink, LLC
11
13. Reuse…Yes Again
• Under the concept of service reuse, we have a
few things we need to determine to better define
the value. These include:
– The number of services that are reusable.
Complexity of the services. The degree of reuse
from system to system.
• The number of reusable services is the actual number of new
services created, or, existing services abstracted, that are
potentially reusable from system to system.
• The complexity of the services is the number of functions or
object points that make up the service.
• Finally, the degree of reuse from system to system is the
number of times you actually reuse the services. We look at
this number as a percentage.
Copyright 2007 The Linthicum Group, LLC
14. So, What do you Do?
• In order to determine their value we must first determine
the Number of Services that are available for Reuse
(NSR), the Degree of Reuse (DR) from system to
system, as well as the Complexity (C) of each service.
• The formula to determine value looks much like this:
Value = (NSR*DR) * C
Copyright 2007 The Linthicum Group, LLC
15. SOA=Agility
• Agility is a strategic advantage that is difficult to
measure in hard dollars, but not impossible. We first
need to determine a few things about the business,
including:
• The degree of change over time is really the number
of times over a particular period that the business reinvents itself to
adapt to a market.
• The ability to adapt to change is a number that states
the company’s ability to react to the need for change over time.
• Finally, the relative value of change is the amount of
money made as a direct result of changing the business.
16. Case Study: ABC Corp
• Description: Very simple trading system supporting trade clearing for a private
exchange.
• (NSR)The number of services that are reusable = 10 (low number relative to
industry) (C)Complexity of the services = 50 (object points, low number relative to
industry) (DR)The degree of reuse from system to system = 20% (low number
relative to industry)
• So, considering our formula for reuse:
Value = (NSR*DR) * C
Value = (10*.2) * 50
Or
Value = 100
• When considering best practices, any number over 100 is considered in the zone
where reuse will clearly bring at least some ROI, so considering that the assumptions
are correct, the value of reuse for this project is right on the border. However, keep
in mind that’s but a single metric.
16
17. Case Study: ABC Corp
• However, considering the formula for agility:
– The degree of change over time = 7. Change is moderate to high, based on the industry
and the state of the business.
– The ability to adapt to change = 8. The ability for the staff to adapt to change is moderate to
high.
– Relative value of change = 8. The value to align the architecture with emerging business
opportunities is moderate to high.
Thus, the average number (7+8+8)/3 = 7.66
• It’s considered that a score of over 5 in this analysis indicates that the
company will benefit from an agile IT architecture…the higher the score
above 5, the more the benefit. Clearly, agility is a key value for ABC Corp,
and thus the company will befit greatly from an architecture that supports it.
17
19. How Do you Build A SOA?
Test and evaluate SOA solution.
Deploy SOA technology.
Select your technology set.
Define new processes.
Define new services.
Understand all processes.
Understand all services.
Understand all application
semantics.
Define your problem domain.
Understand your business
objectives and
define success.
20. Understand your business
objectives and
define success.
ROI
Define ROI
Business
Case
Create Business Case
Copyright 2007 The Linthicum Group, LLC
21. Domain
Descriptions
Define your problem domain
System
Descriptions
System Complexity Analysis
POC
Results
SOA POC
Vendors
22. Understand all application
semantics in your domain.
SOA
Legacy Metadata
Metadata Meta data analysis
Data
Abstraction
External Data abstraction Layer
Metadata layer definition
(B2B)
Data
Services
Data services definition
23. SOA
Metadata
Understand all services
in your domain.
Candidate
Legacy Services
Services Service analysis
Services
And
External Metadata and Information
Services services analysis
(B2B)
Services
And
Performance
Performance analysis
24. Understand all processes
in your domain.
SOA
Metadata Candidate
Processes
Process analysis.
Candidate
Services Processes,
Services,
Define metadata, services, And
and processes Information
External
Process
Processes Integration
(B2B) Process integration Diagrams
analysis.
25. Processes,
Services,
And
Information
Candidate
Services
Define new services.
Service
Definition
SOA Service definition.
Metadata
Service
Candidate Design
Processes Service design.
Service
Implementation
Process
Integration
Service implementation.
Diagrams
26. Processes,
Services,
And
Information
Candidate
Services
Define new processes.
Process
Definition
Metadata Process definition.
Process
Candidate Design
Processes Process design.
Process
Implementation
Process
Integration
Process implementation.
Diagrams
28. Finding Value in Cloud-to-
Enterprise Integration
Copyright 2007 The Linthicum Group, LLC
29. Understand Outside Interfaces
SOA
Finance/
Operations
Sales Order
Update
New
Accounts
Commission
Calculation
Data
Cleaning
Sales
Best Practices as
Shared Processes
Copyright 2007 The Linthicum Group, LLC
30. Understanding the Problem
• Cloud services must integrate with existing
enterprise systems to become more valuable.
• However, existing internal integration needs to
exist to ensure:
– Production and consumption of structured information
– Semantic mediation
– Security mediation
– Service enablement
– Firewall management
– Transactional integrity
– Holistic management of complete integration chain
31. Getting Ready
• So, how do you prepare yourself? I have a few
suggestions:
– First, accept the notion that it's okay to leverage services
that are hosted on the Internet as part of your SOA. Normal
security management needs to apply, of course.
– Second, create a strategy for the consumption and
management of outside-in services, including how you'll deal
with semantic management, security, transactions, etc.
– Finally, create a proof of concept now. This does a few things
including getting you through the initial learning process and
providing proof points as to the feasibility of leveraging outside-in
services.
32. Remember, there are a few technical issues
that you must address…
• Semantic and metadata management, or, the management of the different
information representations amount the external services and internal systems.
• Transformation and routing, or, accounting for those data differences during
run time.
• Governance across all systems, meaning, not giving up the notion of security
and control when extending your SOA to the global SOA.
• Discovery and service management, meaning, how to find and leverage
services inside or outside of your enterprise, and how to keep track of those
services through their maturation.
• Information consumption, processing, and delivery, or, how to effectively
move information to and from all interested systems.
• Connectivity and adapter management, or, how to externalize and internalize
information and services from very old and proprietary systems.
• Process orchestration and service, and process abstraction, or, the ability
to abstract the services and information flows into bound processes, thus
creating a solution
Copyright 2007 The Linthicum Group, LLC
33. Final Thoughts
• EA is an evolving discipline. New notions and business events
will drive EA activities going forward.
• EA=SOA and SOA=EA. We have a tendency to forget that. The
“A” in SOA is architecture.
• Learn how to see beyond the SOA hype, and make sure to
understand your own business issues.
• Accept the emerging Web (cloud computing) as a resource that
is to be leveraged for the good of the company. There will be much
change here.
• The enterprise architect should drive change for the good of
the company. However, never “manage by magazine.”
• It is the most exciting time for enterprise architects.
Opportunities are plentiful, but so are pitfalls.
• The lines are blurring between enterprise applications and the
emerging cloud computing platforms. There is a fundamental
shift in how we deploy and manage enterprise applications and
services going forward.
Copyright 2007 The Linthicum Group, LLC
34. Thanks!
david@davidlinthicum.com
• Blogs:
– InfoWorld “Real World SOA”
– Intelligent Enterprise
– eBizq.net
• Weekly Podcasts
– InfoWorld SOA Report
– Cloud Computing Podcast
• Columns
– SOA Journal
– Cloud Computing Journal
– eBizq.net
– Align Journal
– Government Computer News
• Follow me on Twitter (DavidLinthicum)
