Your SlideShare is downloading. ×
Enterprise SOA Chapter 1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Enterprise SOA Chapter 1

138

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
138
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 Paralysis t Change Requests 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 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!
  • 13. 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
  • 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
    • 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)
  • 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

×