I recently attended a conference, and was happy that I wasn't speaking so I could sit back and enjoy being an attendee only. The conference was focused at and attended mostly by technologists, lots of developers in the house! The conference also had an entire track dedicated to SOA over the 3 day event. I was so excited to see that a conference that wasn't dedicated to SOA or BPM had an entire track over the 3 days on SOA.
I started off the conference by attending the SOA sessions. Logic would tell me to go to other sessions-- ones that I was unfamiliar with, so I could learn more about areas I wasn't as entrenched in. But, I threw logic out the window, and had to start where my heart is and see what other practitioners have to say about their SOA experiences.
The SOA sessions were interesting to sit through, but I was really surprised and disappointed that these SOA sessions were poorly attended. At a conference that had over 1,000 attendees, the SOA sessions struggled to get 10 attendees per session, while other sessions were "standing room only". The few folks who did attend, were trying to learn SOA 101 and how to get started with SOA at their respective organizations.
Despite the low attendance and interest at the SOA sessions, I still took it upon myself to preach SOA to attendees I networked with throughout the entire conference-- whether it was lunch, booth conversation, breaks, or even evening social hour, I spoke the SOA gospel. I quickly realized that most folks I encountered, struggled with the fundamentals of SOA and the value proposition it brings to their architecture. The 2 main excuses I heard from attendees about not embarking on SOA were 1) SOA is overkill for their organization (they don't think they need it) 2) SOA adds more complexity to the architecture and environment and the last thing they need is more complexity. Through questioning and examples, I tried to prove that both these "excuses" were incorrect. However, when your at a conference and only have a few minutes to get your point across to someone you just met for the first time, it's difficult to fundamentally change people's minds. At a minimum, I am confident I planted a few deep seeds for folks to think about or read more about SOA when they return back to their organizations.
It seems SOA evangelism is an uphill battle. Most folks I meet are non-believers when I meet them and they need to be converted to SOA. They say IT beliefs are like a religion, so we know conversion can be a difficult endeavor. I am ok with this responsibility and wholehearteldy accept it. My preferred approach towards gaining SOA acceptance is to engage and prove value through a Proof of Concept. I feel this is the best way to show SOA benefits. It's also important to understand that SOA truly is a paradigm shift-- a new way of thinking in organizations. With SOA, applications and systems aren't managed as the primary asset; rather, the service is. A lot of folks struggle with this concept, especially since they have been working in a single paradigm and only understand systems and applications throughout their careers.
What's the solution to overcoming this uphill battle? Continuous education, evangelism, and making sure demonstratable value can be achieved through proof of concepts and prototypes. Show your colleagues the money! IT needs to accept SOA before you can bring it to the business teams, so make sure you don't ignore the developers in your organization-- they are important stakeholders that need to be part of the SOA Journey from the beginning stages. Show them the light, and live by the motto "If you build it, they will come"!
