“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 . . ?

Value Facet

Value Metric Manifestation

Utilization To get a higher return from existing Information Technology resources

Degree of Use Utilizing existing Data Utilizing existing Functionality

Agility To easily answer tomorrow’s questions and implement tomorrow’s ideas with today’s technology

Ease of Change Ease of assimilating new or differing types of Data

Ease of assimilating new or differing types of Functionality

Ease of changing Process

Efficiency Greater long term return with limited investment and maintenance

Overall Cost Less resources required to develop or change

Reuse

Visibility To easily look into the enterprise, see its shape, understand its dynamics, and comprehend and measure its behavior

Ease of access Ease of access to Data Ease of access to Functionality Ease of access to Process

Resiliency The ease with which today’s solutions can be maintained in tomorrows technology and approaches

Ease of Maintaining

Ease of assimilating new or differing types of Data

Ease of assimilating new or differing types of Functionality

Ease of changing Process

Specialization

To use external resources for that which is not core to the value the business adds and to externally offer that which the business does best

Use of what is best Ease of discretely accessing differing types of Data

Ease of discretely defining process participation by Data or Functionality

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:1. Values, Qualities, and Practices – What are the benefits

which merit its pursuit? What are the qualities that define it? And how are they achieved?

2. On going evolution of IT – How and why it has come to pass?

3. Key enablers – How has it become widely available?

4. Drivers – Why now and what will be directing its future progression?

5. Generations – What is its likely path of progression?

6. 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 . . ?

Monolithic LegacyApplication

SOA EnabledApplication

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?