SOA Consortium Podcasts on SOA Centers: Accelerating Behavior, Demand and Value

I so enjoyed these talks, I'm ripping my post from the SOA Consortium Insights blog to spread the word.  I even bought Mel's book.

"Have you listened to the SOA Consortium's SOA Center of Excellence Centers podcasts yet?  Day two of the March member meeting was focused on SOA Centers.  Specifically, we set out to explore the mission, structure, skills, funding strategies and lifecycles of successful SOA Centers. On lifecycle, we were looking to answer the question of how long a center should exist and if/how it morphs over time. “Build to last, or build to blast?”

The SOA Center morning started with individual talks by Melvin Greer of Lockheed Martin and Rich Reba of CSC discussing their SOA Centers.  Following those talks, David Butler of HP and Bruce Henderson of Savant joined Melvin and Rich for a roundtable discussion on SOA Center skills.

Before I go further, I should explain my edit of 'Center of Excellence' to 'SOA Center'.  Often, the connotation of a 'center of excellence' is a small, expert team that acts as a single source service provider.  This was especially true in the early days of data warehousing and enterprise integration.  However, SOA is a pervasive strategy (PDF warning) spanning/bonding business and IT.   As such, our presenters made it clear that the ultimate mission of the SOA Center is to develop SOA competency (excellence) throughout the organization. In the case of CSC, that competency development directive extended to CSC's customers. 

So, think of the SOA Center as an incubator, rather than a manufacturer.  What then is the SOA Center incubating, or as the blog post title suggests, accelerating? 

Melvin Greer states his SOA Center is responsible for altering the behavior of IT professionals in order to be successful with SOA.  In his presentation, Mel builds on the metaphor of Lucy Van Pelt's 5-cent advice stand, speaking to common SOA disorders and listing the symptoms that indicate a competency center is needed.  To hear Mel's entertaining and insightful talk, go here.

Rich Reba shared that key to his SOA Center is the generation, and then fulfillment, of SOA demand.  In his presentation, Rich describes the build out of CSC's SOA Center in the context of building CSC's SOA Business. Rich's step-by-step story from vision to implementation is full of lessons applicable to enterprises, government agencies and service providers.  The concept of SOA Center as demand generator recurred throughout our day.  To hear Rich's information packed talk, go here.

During the roundtable, our panelists spoke of a variety of skills required to build a SOA Center (political awareness, evangelism, communication, business discipline, vision, organizational design) as well as another list of skills required to operate a SOA Center (project/portfolio management, service design, business knowledge, technical aptitude, communication, teaching, governance).  While the panelists had different points of view on specific skill needs, they agreed that a given organization's SOA Center should be comprised of the skills most likely to accelerate value delivery.  And, that the SOA Center's contribution should be measured in financial terms.  To hear the roundtable conversation, go here."

If you'd like to share insights on your SOA Centers, have comments on the podcasts, or would like to engage in a SOA Center leader peer discussion, please leave a comment/trackback here or on the SOA-C blog post, or drop an email to bmichelson at elementallinks dot com.

[Disclosure: The SOA Consortium is a client of my company, Elemental Links]

Comments

[Mark Griffin]

Hey Brenda,
For me it gets back to one size doesn’t fit all. It’s no different in my mind than a distributed computing model versus a centralized computing model. Some organizations are very successful with the distributed model and they are usually better at governance too. Other organizations need a bit more centralization in order to be successful.

I tend to like the centralized CC model that kind expands and contracts as needed. There is a core team but additional resources are added in as needed or taken away. Most organizations that tried EAI without the core center did not fair well. I don't believe that SOA would be any different. I do agree though that ultimately with SOA the skill sets need to be propagated out to the entire organization/enterprise. I just don't see the CC going away when that happens.

I do find it amusing that the past tense reference to Enterprise Application Integration is used. I've seen that crop up in that manner on several sites lately. Not only is EAI not dead, if it was implemented correctly it can and does at some organizations serve as core foundation to an effective SOA strategy. Solid EAI patterns are nothing more than services. I think a lot folks tend to see EAI as just moving data around but that just isn't the case.

markg
http://www.thegreylines.net

[brenda]

Hey Mark,

Nice to hear from you! And yes, I agree that enterprise integration is far from dead and that it does provide a foundation for SOA and information sharing strategies. What is MDM after all? It's enterprise integration.

My intent in calling out the 'early days' of EAI and data warehousing was to differentiate the call to create those COEs -- single source provider always -- from the current call to create SOA Centers -- initially single source provider but with an inherent mission to delegate that responsibility throughout the organization.

I know of many mature enterprise integration and data warehouse COE's that provide on-going value to their businesses and critical building blocks for architecture strategies at the next level(s) of abstraction.

-brenda

[Mark Griffin]

Brenda,
I definitely agree with you on the single source versus delegation. SOA is just to big to scale with a single source mindset. I wonder though how many ad-hoc CCs are in place even when the knowledge is trying to be pushed out. In other words there is an informal CC by nature of the same resources being used over and over because they get it. The reason I say that is that folks tend to choose the path of least resistance. I still see a significant number of developers that don't get or want to get service development. So the tendency might be to choose the ones that do for a given project.

markg
http://www.thegreylines.net