1 / 16

“The Power of an SOA Demo?”

“The Power of an SOA Demo?”. An Open Dialogue. In the spirit of the social learning. In the spirit of the social learning true of a community of practice, an open dialogue to get beyond the rhetoric. Dig into the aspects of SOA.

ctant
Download Presentation

“The Power of an SOA Demo?”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. “The Power of an SOA Demo?” An Open Dialogue

  2. In the spirit of the social learning . . . • In the spirit of the social learning true of a community of practice, an open dialogue to get beyond the rhetoric

  3. Dig into the aspects of SOA . . . • Dig into the following aspects of SOA and what a public “demo” could offer agencies within the federal government: • Interests • Desires • Challenges

  4. Context • SOA is Analogous to Splitting an Atom - The concept is remarkably simple, yet how to go about doing so and the consequences of having done so, are exceedingly complex. • A number of new issues • Governance, Granularity of Service, Semantic Parity, Quality of Service, Service Level Agreements, etc . . . • A mountain of rhetoric • ESB, EDA, BPM, BAM, etc . . . • A sea of standards • Some overlapping, some conflicting, some missing • A universe of new products • Some free, others expensive, and many complicated . . . All with some level of proprietary lock-in hidden behind a façade of standard compliance

  5. Where to start . . ? • Who are you? • Name • Role • Agency • What is your interest? • Technical • ROI • Other?

  6. What is the interest . . . ? • What would you want to see as . . ? • A CFO? • A CIO? • An Enterprise Architect? • A Technical Architect? • A Business Stakeholder?

  7. What is the reference point . . ? • What background experience can be assumed? • What concepts are known? • What vocabulary is common? • How do you start the conversation?

  8. Value Proposition . . ?

  9. Significance of History . . ?

  10. Putting it in Context • To understand SOA it is important to not only define it, but to put it in context. There are several pertinent contexts to be considered: • Values, Qualities, and Practices – What are the benefits which merit its pursuit? What are the qualities that define it? And how are they achieved? • On going evolution of IT – How and why it has come to pass? • Key enablers – How has it become widely available? • Drivers – Why now and what will be directing its future progression? • Generations – What is its likely path of progression? • Implications – What are the likely consequences?

  11. How could a demo contend with? • The challenges of getting support for SOA? • Demonstrating the value and the potential of something non-visual? • Illustrating key concepts? • . . ?

  12. Other Dimensions . . . ? • Practices, Qualities, and Impediments of SOA • Fundamental Practices • Qualities of SOA • Best Practices of SOA • Impediments to SOA • Practices arising from and necessitated by SOA • Reference Model • Common Misconceptions

  13. Using Analogies . . ?

  14. Next Steps?

  15. Successful . . ? • Take the conversation offline and extended

  16. Significance of History . . ? • An examination of integration for what it is: • What if integration were not an after thought of systems development? • What if systems were architected for integration? • What if integration was not a one time effort, limited by the functionality and data it dealt with, but accepted as an on going and continual process? • What if integration was not a technical challenge requiring specialized skill but rather a fundamental competency of an enterprise and intuitive to non-technical resources? • What if integration was not a technological or business impedance, but rather a fundamental enterprise capability and readily accessible to wide audience? • Leads to a reexamination of a system for what it is: • What if the enterprise were comprised of discrete units of readily accessible functionality instead of separate systems? • What if application development were merely connecting and orchestrating those units of functionality? • What if the enterprise was the system and integration was a common practice?

More Related