We welcome your feedbak on how to improve the event and I welcome Jeff as the new Conference Chair.

Thank you and Happy Holidays, Anthony Bradley

SOA is indeed a journey and in the keynote I used a personification analogy of building a strong relationship between SOA and IT. Therefore, sticking to the analogy, I asked the audience to think of the conference as a three day relationship building retreat with the keynote as the initial counseling session to kick off the retreat. I played the role of SOA and asked Sue Landry to play the role of my relationship partner IT. I also asked Roy Schulte to join us as our relationship counselor. We then put on a little “play” addressing the major relationship challenges between SOA and IT. We talked about the following IT/SOA relationship challenges:

1. I Don’t See What I Get Out of This Relationship with SOA
2. IT Isn’t Ready for This Relationship
3. SOA Does Whatever It Wants (I Can’t Control It)
4. IT Has Too Much Baggage
5. IT Won’t Change
6. I Don’t See a Future in a SOA Relationship
7. IT Is Trying to Move Too Fast in This Relationship

The Bottom Line takeaways that goes with each of these challenges are:

1. Build SOA business cases and measure success
2. Actively mature your organizational SOA competency; don’t simply deploy SOA technologies
3. Use governance as the guardian of SOA success
4. Capitalize on SOA as a reason for and path toward IT modernization
5. Instill new application development thinking and behaviors to realize SOA agility and shareability benefits
6. Explore SOA’s evolution to augment your road map and derive deeper value from SOA
7. Employ an SOA road map to grow SOA incrementally as a key part of your applications strategy

I’m reiterating these because they are the major messages of the conference and the 70+ presentations, workshops, and round tables were all about working on improving these competencies.

I hope the conference was a productive and enjoyable experience. See you in June at the next ADI summit!

Thank you, Anthony Bradley

• IT Procuments – IT Leaders and their vendors own the decision rights
• IT Cost Optimization – IT Leaders own the decisions rights
• Joint IT/Business Cost Optimization – the decision is made jointly between IT and business leader
• Business Restructuing and Innovation – the decision is usually made by business leaders and IT leaders have little influence

The idea is to work on cost optimization opportunities at all layers, but to pay particular attention to the areas where you call the shots and can act fairly quickly rather than fixating on things that you have little control over.

This leads to the second framework that we brought up, which helps prioritize any cost optimizaiton idea within the above structure.  The idea is to focus on cost optimzation opportunities based on:

• Size of potential savings
• Time-to-Savings
• Cost-of-Savings
• Risk-of-Savings

This is the tip of the iceberg on an number of ideas.  You can see much more content on this at our site on IT and the Economy.

The first story he told was about the first boxing match broadcast over radio.  Malcolm also highlighted the dramatic drop in crime in New York City in the 1990s as well as the fall of the Berlin Wall.  The point in all three cases was that dramatic change occurred in a very short period of time and with very little cost.  In other words, even in times when budgets are very tight and business leaders only want to hear about business cases that return value in a matter of months, there is the potential to help drive dramatic change.  In fact, this is likely the time when dramatic change will occur in various industries.

Next Malcolm highlighted the importance of re-framing context when striving to drive change.  He mentioned that safety laws did not drive many people to wear seatbelts.  However, when children who grew up in car seats asked why their parents were not wearing seatbelts, many parents started wearing seatbelts.  The same dynamic applies to how Apple changed the context of mp3 players from techy devices that required a decent amount of geeky knowledge to fashion statements that anyone could figure out.  All of us hoping to help our organizations by leveraging IT, should stop and think about how we can change the context away fixating on devices, software, and things like viruses.  Rather, we need get people focused on how technology can help business and government change in meaningful ways.

The third point that Malcolm made was around the importance of social power that comes from people in a position to rally people to a cause.  Interestingly, the individuals who can rally critical masses of people are often not executives or other obvious leaders.  Referring back to The Tipping Point, Malcolm pointed out that people that can drive mass behaviors are often either:

• “Mavens” – experts that we all turn to
• “Connectors” – people that no many other people across social circles

Finally, Malcolm told a story around the U.S. Navy’s struggles circa the beginning of World War II.  The path to solving the challenges turned out not to be the normal options: changing leadership, throwing money/resources at the problem, finding a better expert.  Rather, it was about aggregating a wide variety of information as well as a wide variety of ‘mavens’.  This led to the identification of key pieces of information that were rapidly disseminated through ‘connectors’ to ship captains.  I’m sure there is much more to the story and that I didn’t get it all right, but the main point leads to the power of combining many different information types with a wide variety of experts and the ability to quickly disseminate actionable advice.

This makes me think about the ‘information’ part of ‘information techology’.  We shoud all spend a bit of time thinking about what information within and outside of organizations would be most valuable to help business leaders make better decisions in these challenging times.  Imagine if IT could not only help with that part of the puzzle, but analytic and collaboration technologies could help experts compare thoughts on the information, and social networks could help rapidly rally people around key actions…

In other words, we should not simply fixate on the money/budget side of things, but we should realize that dramatic changes often happen with very little money/time and we have a lot of the relevant knowledge, skills, and cheap tools that can be key to making the change happen!

Malcolm was also kind enough to sign copies of his latest book Outliers, which I am already about 1/3 through reading.  It has me thinking about what being born in May of 1968 has made possible (or not)…

Thank you very much for your participation in the discussion about B2B / SOA today. I really appreciate that everyone actively participated, and was pleased that we were able to reach the three interesting (and at least in one case non-intuitive) Findings, which I’ve pasted below (with a few edits for readability, but hopefully without changing the meaning).

Finding 1: Companies immediately (rather than in the near or far future) need to deal with B2B SOA in their B2B projects. 

Finding 2: Some external business partners are beginning to demand SOA, regardless of existing industry standards.  [or, as one of you said another interesting way, “you might need to put SOA lipstick on your existing industry standard pig”]  J

Finding 3: Within industry standards, the payload specifications are more valuable than the protocol / delivery specifications – given that alternative protocol / delivery specifications provide sufficient security and quality of service.

I’d also like to acknowledge Suresh’s insightful observation that (and I paraphrase from memory – please post a correction if I got it wrong) that “a portfolio approach of about ½ dozen ways of doing B2B works best”. I couldn’t agree more, and you’ll see that I discuss this in much of my research. 

In my opinion these are pretty interesting Findings, and have a material bearing, for example, on each of your B2B strategies. For example, because of these Findings you might conclude that you’ll both leverage existing content industry standards, e.g., ACCORD, and deliver the payload using both whatever protocols are pre-approved for ACCORD but also using other techniques, e.g., Web services, once you ensure you’ve got enough security & QoS.

Because you’re all Gartner clients as well I’ve also pasted below links to my B2B research index and a few pieces of research that are related to our discussion, although I also recommend that you all check out research from my colleague Frank Kenney, particularly related to SOA governance, and SOA testing – topics that came up but that we didn’t have time to cover in detail. To make it easier to find relevant research on multi-enterprise (B2B) integration please review my research abstracts online at http://www.geocities.com/benoit_2001/B2B_Research_Index.htm or by simply double-clicking on the attached HTM file. In particular, the following research notes should be relevant to our discussion today:

·         Hot Questions About SOA From Asia – November 19, 2008 (G00161363) à Answers to frequent questions on SOA that I was asked on a recent trip to Asia

·         SaaS Integration: How to Choose the Best Approach – October, 1, 2008 (G00161672) à A decision framework to help SaaS customer choose the best approach to SaaS integration

·         Toolkit: Request for Proposal for B2B Gateway Software – August 26, 2008 (G00154852) à An Excel-based tool (with graphics!) to facilitate your B2B Gateway Software RFP process

·         Magic Quadrant for B2B Gateway Providers – June 3, 2008 (G00157460) à Our rating of 14 B2B Gateway Software (think: evolving EDI software) vendors

·         Magic Quadrant for Integration Service Providers – May 28, 2008 (G00157093) à Our rating of 14 Integration Service Provider (think: evolving EDI VAN) vendors

·         Key Issues for Multienterprise B2B Integration, 2008 – March 11, 2008 (G00155781) à The definition and scope of Gartner’s B2B Multienterprise Integration research agenda

I also welcome Gartner research inquiry on this and related B2B topics anytime – just contact the Gartner quickpath at the number below to schedule that.

Cheers,

-          bjl

P.S. Please contact me directly @ Benoit.lheureux@gartner.com if you have any trouble using my research index. I also welcome knowing whether (or not) it was useful to you!

I vividly remember the annual exercise, which many of you still go through, where the business folks show up at the beginning of the project approval process with a huge ”wish list” of projects they would like done.  I was always convinced that if I looked hard enough at the list, I would literally see the “kitchen sink” somewhere in the list.  Of course, there was no way that the development organization could tackle even half the list, so people would go through a prioritization exercise.  Then it would take months and months – if not years – to deliver the things the business folks had so desperately wanted.  All too often, when things were delivered, the business folks said that this wasn’t what they really wanted.  This would lead to people pulling up the requirements docs and debating whether what was delivered was what the business had asked for…

The point of David’s slide is that agile methods change this dynamic dramatically.  A few years ago, I talked with a client who gathered up the annual business ‘wish list’ just as they were switching to an agile method.  Interestingly, the kept the list.  As they deliverd incremental pieces of what the business wanted, conversations where held where the business said “ok, now that I see this piece of the puzzle…here is what we need to see next and these are changes that should be made to what you prototyped…”  After delivering in this way for 18 months, the development folks looked back at the business wish list.  Less than 20% of what was on the list turned out to be things that the business asked for over all the itrerations that had been done over the last 18 months.  There were also a number of things that business asked for over the iterations that were NOT on the original list.

What does this tell us?  As many of us already knew, the business often doesn’t REALLY KNOW what they want.  David just used the term “crystel ball gazing” as a way to think of how traditional project wish lists work.  Unless you have business people that are really good furtune tellers, you should seriously consider at least shortening waterfall cycles if not moving to a real agile method.  The big caveat is that whatever you choose has to be something that the business is willing to engage in, or it will all be for naught…

This is a great example of a mash-up.  I’m not sure about all the details, but I heard that it took less than three hours to create this.  It just goes to show that if you follow basic WOA principles, the ability to compose new capabilities is amazingly quick for a very broad potential audience!  Nick Gall happens to have just post a related set of thoughts in Generic Identifiers aka Web Scale Identifiers.

Dan Sholler’s

1. Modular
2. Distributable
3. Swappable
4. Discoverable
5. Shareable

From there he highlighted that the primary benefits of SOA are agility and shareability.  To that at end, he made some very clear recommendations:

• Design the interaction layers of your applications according to the five SOA principles
• Focus on reducing dependencies between volatile implementations
• Share capabilities across system boundaries

Later in the presentation, Dan made a point I really liked: “services are agreements”.  In my view, understanding this is key to SOA success.  Thinking of a service as a piece of code that you throw over the wall to a production/operations group is totally missing the point.  Rather, we need to think of a service as a promise the service creation/delivery party makes to all of the parties consuming the service. 

Looking at advanced implementations, such as the work Amazon.com has done, leads to some interesting implications to application organizational structures and work processes.  The Amazon folks have clearly stated that the same team that builds a service is also responsible for running the service.  This team also figures out how the service should evolve, prioritizing new features and functions.  With only a small hop, skip, and jump, this conversation gets to development methodologies.  Personally, I think agile methods are another key consideration to keep in mind when thinking about how to go about doing SOA.  Check out David Norton’s sessions, particularly the one “How To Make Agile Waterfall“

• People question the “value of SOA” all the time.  Just as there being good and bad relationships between people in regular life, it turns out that there are a large number of both SOA Successes and SOA Horror Stories.  The key is taking the time on the “softer issues” such as SOA Governance and How to Organize for SOA.  It is also critical to hit the “value cynicism” head on by really nailing SOA Business Cases.
• Individuals in a relationship often need to work on being more mature in general.  Application organizations need to mature in general, not just specifically for SOA.  Make sure to check out the sessions on Application Governance and Maturity
• My favorite moment was when Sue mentioned that SOA had been around for quite some time and was still having issues – just like a boyfriend that had been hanging around for too long.  Roy made a great point about how SOA has significantly evolved from the early days of basic reuse and request/reply concepts.  On that note, check out the Delivering on Advanced SOA Track and particularly the sessions on Event Processing and Context Delivery Architectures.

As a final point, the notion that every IT organization’s journey with SOA is as unique, rewarding, and challenging as any serious relationship between people is a great thing to keep in mind.  There is tremendous value here, but we do all have to work on it.  We need to make sure we are focusing our time on the right things…every day – just as therapists are want to say!

He then goes on to highlight that lack of effective governance is the number one reason that SOA initiatives are perceived as failing.  This led to a discussion on a SOA Center of Excellence as well as the importance of managing your SOA Assets and Artifacts.  Personally, I believe these latter points are absolutely critical.  It’s all too easy to focus on the enabling technologies at the expense of focusing on the enabling management disciplines, skills, and behaviors that are required for SOA success.

To see more on these subjects, check out the following sessions:

• Selecting Backplane Infrastructure Technologies to Support Your SOA and BPM Initiatives
• Case Study: Transitioning to SOA
• Riding the SOA Tiger: Practical Governance for SOA
• SOA Horror Stories