This historical presentation, circa 2009, describes issues in moving and understanding SOA architecture, and moving from tactical 'just connect it together' towards an enterprise strategy for Service Oriented Architecture and a 'build it once' approach - and how many are struggling with moving from a connect-it to an 'oh no - integration spaghetti'. Did SOA die by 2009? (answer - no, it just became part of the underlying structure.)

2. • This is one of my older presentations, from
2009. It’s certainly not as polished as some of
my later ones, but works hard to get across
the concepts of enterprise integration.
• Over years as a corporate enterprise architect,
director of enterprise architecture, and as an
enterprise IT architecture + IT management
consultant, I prepared many presentations
about the leading technologies at the time…
how to use, where to value, what to avoid.

3. • As most concepts and technologies in
software build upon older tech sets, you may
find these of value to understand some of the
foundations upon which your tech stack is
built…and perhaps identify ideas that still
apply or offer value.
• If you’d like to contact me to discuss further, I
can be contacted via akivam@gmail.com
or via Linkedin
https://www.linkedin.com/in/akivam/

4.  The Industry Pundit says,
“SOA is …a method of conceptualizing, designing,
and implementing business software applications and
infrastructure. It incorporates centralized assembly
and management of reusable autonomous business
functions (“services”) in a loosely coupled manner,
with heavy emphasis on accepted industry standards.
Service-oriented architecture helps align your
business goals and IT.
 WHAT ????

5.  Architecture = a style of design,
how we design software systems / modules / processes.
 Service-oriented
› Discrete elements of functionality – business process –
are modeled as “services”
› They are accessed via well defined interfaces
 An approach to designing systems
› Design principles
 Processes as modules
 Modules as independent integrated components
 Integration layers creating process workflows
 Application layers presenting user interfaces
 In other words, SOA is a software design pattern, a way of thinking
about a problem. It is not a particular
technology, tool, or protocol.

6.  Most organizations are using some web
services without problems.
 Many have started bottom-up SOA projects
as “better EAI”.
 2-3 Years into SOA, many organizations are
hitting an ROI barrier and acceptance
barrier.

7. SOA for Integration
 Targets “Integration
Spaghetti”
 Moves integration logic
out of the applications
into the central
integration space.
 Creates integration
reuse.
 Allows for composite
functionality – composite
services.
Enterprise SOA
 Changes the Application
Design Pattern
 Targets Narrow Business
Functions with matching
IT System Functions
 Decomposes traditional
systems into their
business processes.

8.  Problem: Integration Spaghetti

9.  Solution : ESB to Organize The Chaos

10.  Solves many integration problems, but
doesn’t provide major SOA benefits.
Benefits
 Easier & Faster
Integrations
 “Real Time” Processing
 Real Time Data
Accessibility
 System Interconnection
Flexibility
 Reduced Point-to-Point
Connections.
Not Gained
 Single Service for Single
Business Process
 Application Assembly
 Business Flexibility
 Easy BPM
 Reduction in Application
Redundancy & Business
Process Redundancy

11.  Vendors do OK, but we must layer the tools
carefully to maximize reliability.
 We must architect the services and
interfaces carefully to achieve reliability
within a distributed/service (SOA)
environment.
 Why…

12. Traditional System
Server
Operating System
Application
Container
The Application
Traditional System
Database Server
Operating System
Database Software
The Database
Network
The traditional
mid-tier system
is dependent
upon 9 primary
components
being
operational to
deliver it’s
functionality.

13. Server
Operating System
App Container
The Application
The dependencies
are now 9 x 5,
45 dependencies to
deliver the
functionality.
Provider Server
Operating System
App Container
The Application
Provider Server
Operating System
App Container
The Application
Provider Server
Operating System
App Container
The Application
GATEWAY Server
Operating System
App Container
The Application
3 services,
one which requires
a gateway

14. Uptime Percent OUTAGE per YEAR
99.999% 5 minutes
99.99% 52 minutes
99.9% 8 hours, 46 minutes
99% 3 days, 15 hours, 40
min
• 45 components with
99.999% availability.
• equals 99.954% uptime
• changes the system from
5 minutes downtime per
year
• to 5 hours downtime per
year
* We must compensate in the SOA – service – integration
design for the increased outage potential.

15.  SOA for Integration
› Starts as “Just a better middleware”
› Moves to An Improved Integration Pattern
 Enterprise SOA
› An Application Design Pattern
› A Business-IT Interaction Pattern
› Business Functions as Services

16. BILLING
Receive
Charges
Calculate
Bills
Manage
Customer Bills
Billing Cycle
Processing
Send Bill
Interface with
Accounting
System
Interface with
Customer
System
Print
Email
Transmit

17.  Decompose the Big Box
Application into it’s
Business Processes.
 Assemble or Orchestrate
the Department
Functionality from the
composite processes.

18. BILLING
Receive
Charges
Calculate
Bills
Manage
Customer Bills
Billing Cycle
Processing
Send Bill
Interface with
Accounting
System
Interface with
Customer
System
Print
Email
Transmit

19.  Fine Grained Business Functions are Services
 Business Processes are Composite Services
 Applications are
Combinations
of Business Processes
Presented via
Various Presentation Methods

20. • Function oriented
• Build to last
• long development cycles
• Process oriented
• Build to change
• Incrementally built
and deployed
• Application silos
• Tightly coupled
• Object oriented
• Known implementation
• Orchestrated solutions
• Loosely coupled
• Message oriented
• Abstraction
Service5 Service6 Service9
Service1 Service2 Service3
Bus
Credit: Ciber – Dr. Mansour

21.  Single Business Function – Single INSTANCE
 Single Process – Single Connection Set
 Single Data Set – Single Access Point
 NOT Reuse – Rather not repeating the same
work – data – process – connections.
 Application Assembly & BPM –
Build only the NEW business functions.

22. Losing ROI
Departmental Acceptance

23.  Most IT organizations implement an ESB –
complete with ESB team - but don’t change
project team structure or motivation.
 Project managers are incented – their success
– is defined as delivering their project on
time and on budget.
 Building Services works AGAINST their goal.
Using Services works FOR their goal.

24.  My Project is funded to deliver My
Departmental Business Function(s), not to
expose them.
 Business has been trained to think of
departmental applications – and to fund IT
on an Application Basis.

25.  Go Wide – When
Exposing a Service
expose ALL it’s
elements.
 Go Deep – Expose all
the BUSINESS steps
of a function.
 Non-Core Functions
should be separate
from application core.
 Services should always
be generic, never “for a
specific connection”.
 Think of applications as
transaction engines you
manipulate externally.
 Narrow your applications
to their core business
function – then expose
those functions.

26.  Set interface data
standards, transform
as a temporary
measure.
 Design Services for
Degraded Service and
Failure.
 Deal early with issues
of responsibility,
maintenance, support,
funding.
 ESB’s are great at
transformations, but each
must be maintained
forever.
 Synchronous, Messaging,
and proper error handling
EARLY.
 Consumer/Provider
contracts/SLA’s,
Governance, Monitoring,
and Security can’t be
ignored.

27.  No planning and coordination of service projects
 Single-use services and point-to-point connections
 Proliferation of redundant services and data types
 No metrics for measuring success
 Inconsistent implementation of non-functional
capabilities (security, reliability, transactions,
logging, auditing, routing, filtering, etc)
 Runtime service-level issues related to performance,
scalability, reliability, availability, etc.
 Inability to isolate problems
 Change management issues
 Increased complexity

28.  Sharing and reuse of services
 Sharing and reuse of data types
 Reduction in point-to-point connections
 Reduction in redundant systems
 Ability to recognize and resolve issues before
they become incidents
 Well-coordinated management of service
consumers, enabling consistent service-level
delivery and well-transitioned enhancements
and upgrades