Enterprise SOA

1
Enterprise SOA

• Chapter 1
• An Enterprise IT Renovation Roadmap

2
Enterprise IT Renovation

• Try to strike a balance between immediate gains
  and long-range improvements
• Increase the ability of an enterprise to address
  new business requirements
• Should reuse existing business logic and data
  models
• Provide benefits through agility

3
Agony Versus Agility

• Enterprise software suffers from a lack of
  agility and is often inefficient
• Difficult to quickly match business requirements
  to underlying IT structure
• Software systems become less agile over time

4
Ability to Deliver
Change Requests
Paralysis
t
Green Field
Change Requests reduce the agility of a system
over time
5
Why Stagnation?

• Difficult technical changes in the code
• Key domain experts move on to other projects
• Tight budgets
• Loss of political clout
• No time to do refactoring
• Business systems have complex cross-dependencies
  that grow over time

6
Enterprise Software is a Different Animal

• Enterprise software is tightly coupled with the
  internal organization, processes, and business
  model
• Underlies cross-departmental dependencies and
  external business relationships
• An Enterprise architecture must handle large
  numbers of different requirements

7
A Different Animal

• Many requirements are conflicting
• Many requirements are unclear
• Requirements are a moving target due to business
  change
• Business logic is usually simple!

8
A Different Animal

• Consider an insurance claims system
• Stakeholders include many different business
  units
• Heterogeneous teams of people and political
  environments
• Technology landscape is highly heterogeneous
  many application and middleware platforms
• Cross dependencies in functional environments

9
Consider Building a Word Processor

• Homogenous technical team
• Problem space is well-defined
• Application logic is self-contained
• Few cross-dependencies
• No roll-out user self installs

10
Importance of Enterprise SOAs

• Second law of thermodynamics Any closed system
  cannot increase its internal order by itself
• In enterprise software, the architect acts as the
  outside influence
• Balances different requirements while trying to
  create an enduring order
• Confronted with changes that increase complexity
• Refactoring reduces complexity

11
Requirements for an Enterprise SOA

• Simplicity
• Many people involved with different skills
• IT Coordinators with detailed business knowledge
  but little technical skill
• Technical architects with little vertical
  business knowledge

12
Requirements for an Enterprise SOA

• Flexibility and Maintainability
• Every enterprise must change or die
• The architecture must define distinct components
  that can be rearranged and reconfigured
• Local changes cant have a global impact
• If an external API is stable, internal change
  should not affect operations outside the
  component
• Carefully design the interfaces to be stable and
  general!

13
Requirements for an Enterprise SOA

• Reusability
• Reusability is softwares Holy Grail
• We need an inventory of building blocks
• Code and data can be reused
• Reuse may not always be the most efficient

14
Requirements for an Enterprise SOA

• Decoupling of Functionality and Technology
• The architecture must make the enterprise
  independent of technology
• The architecture must weather techological
  innovation cycles and the lifecycles of installed
  technologies
• Development of business functionality must be
  decoupled from the underlying technology

15
Enterprise Architecture and Standards

• 1980s Enterprise Data Model (EDM) projects
  tried to define one global data model for an
  entire enterprise (generally unsuccessful)
• 1990s Enterprise Software Bus an attempt to
  standardize middleware agree on a ubiquitous,
  technology-independent, enterprise-wide standard
  for communication between software modules. (We
  now have middleware heterogeneity)

16
Enterprise Architecture and Standards

• Enterprise standardization efforts in IT have
  failed to produce homgenization and easy
  application integration
• Why is SOA any different?
• SOA is not a technology or a technology standard
• SOA represents a technology-independent,
  high-level concept that provides architectural
  blueprints

17
Enterprise Architecture and Standards

• SOA slices and dices the enterprise application
  layer in a way that components are created and
  exposed as services
• Services are technically independent
• Services have a direct relationship to business
  functionality
• SOA does not impose adherence to technical
  standards like SOAP

18
Organizational Aspects

• Many problems associated with enterprise IT are
  not technical but are found on the organizational
  level
• Development and maintenance is closely tied to
  the end customer. (A financial reporting system
  will involve the finance department, other
  stakeholder, the CEO)
• Many decisions are driven by business strategy
  and political agendas rather than technical
  arguments
• This book will provide a technical and
  organizational roadmap to SOA

19
Lifelong Learning

• Many attempts have been made to find a common
  denominator between business and technical
  concepts
• SQL Can be used by business analysts to analyze
  data directly
• Still most entities in a relational database are
  too fine-grained to have meaning on a business
  level
• A key goal of SOA is to provide services that
  have a concrete meaning on the business level

20
Lifelong Learning

• SOA provides a unique chance to create artifacts
  that have an enduring value for both the business
  and technology side
• SOA provides a way for an organization to learn
  and preserve knowledge over time in a way that is
  reusable