• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Enterprise SOA Chapter 1

Enterprise SOA Chapter 1






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Enterprise SOA Chapter 1 Enterprise SOA Chapter 1 Presentation Transcript

    • Enterprise SOA Chapter 1 An Enterprise IT Renovation Roadmap
    • 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
    • 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
    • Ability to Deliver Paralysis t Change Requests Green Field Change Requests reduce the agility of a system over time
    • 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
    • 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
    • …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!
    • … 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
    • 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
    • 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
    • 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
    • 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 can’t 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!
    • Requirements for an Enterprise SOA
      • Reusability
      • Reusability is software’s Holy Grail
      • We need an inventory of building blocks
      • Code and data can be reused
      • Reuse may not always be the most efficient
    • 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
    • Enterprise Architecture and Standards
      • 1980’s – Enterprise Data Model (EDM) projects tried to define one global data model for an entire enterprise (generally unsuccessful)
      • 1990’s – 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)
    • 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
    • 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
    • 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
    • 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
    • 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