Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Jean-Jacques Dubray on Jun 13, 2008
Last week, the SOA Consortium released the audio of a panel that discussed the skills, role and relevancy of SOA Centers of Excellence (CoEs)
Bruce Henderson (Savant), David Butler (HP), Rich Reba (CSC) and Melvin Greer (Lockheed Martin) participated in the panel.
Bruce argues that
Vision, Politically Savvy and Communication are the critically important skills... CoEs fail because these skills are rare. It's easy to find technologists and academics type of people.
David first thought that
CoE meant "Center of Evangelism".
He argues that the first step is to look at the level of maturity of the organization. There are generally multiple transformations which are taking place: Process, Culture and Architecture. When application modernization is on the agenda,
It is part of the CoE's job to figure out which asset can be modernized, they are the one that define valuable business services. In many ways, they are responsible for automating Governance... It is very important to understand that Service Lifecycle is very different from Code Lifecycle or Solution Lifecycle.
Dave recommends to have a management track, a technical track and a financial track. He argues:
If you can't see your CoE, you can't see SOA. The SOA CoE is the "product" [1] in SOA.
Rich talked about his three 3s
Three skills: Business, Technology and Management this is essential
Three Abilities: Foresight, Innovation, Leadership
Three elements of character: Passion, People's People, Tenacity
He argues that a SOA CoE is a business, it is there to make money.
He notes that Culture is the biggest inhibitor to SOA adoption. You need to staff your CoE with people familiar with the culture and the way the organization works. They need to understand the constraints that the organization will be facing.
Melvin explains that there are several models that will work. You also have to recognize that:
Building a Competency Center is different from working in a COE
When you build a CoE you need: Tenacity, Political skills, and be Business savvy. Practitioners are a good fit. At Lockheed Martin, CoE members are focused on their mission, they don't need the same skills are the people who built it.
On the other end the critical skill for the members of the CoE is be able to:
Design for Reuse, this skill is very difficult to get,
Other members of the panel argued that one has to be careful with the words we use, because SOA can get "too big" and "too large". Reuse has to be balanced with interoperability. Being able to deliver interoperability is in itself a skill set difficult to acquire.
The group agreed that SOA Governance is key to reuse but it is also a new process for the enterprise.
SOA Governance manages the way services are being developed and described so that somebody would be incented to reuse them.
For instance:
There is a new lifecycle that needs to be created for governance, geared towards the consumer ... collaboration between consumers and providers need to be installed in the IT organization.... [ultimately] business lifecycle is a tricky thing.
The panel spent also some time discussing "semantic interoperability".
People forget about semantics, interoperability at that level is moving in the design space.
The panel also noted that a new generation of consumers starts combining information from unrelated "silos": Enterprise Mashups quickly run into semantics interoperability problems.
One of the key skill set that we see emerging is to understand the semantic tree and be able to use the different tools. This is critical for composite applications.
The panel concluded that a COE is an accelerator.
It is not essential to have one, however if you are talking about transformational and modernization, you need one.
A CoE concentrates the skills that are required to deliver a successful SOA. In many ways, it is a corollary to a PMO or an Architecture practice.
You need to make sure that all the moving parts are moving the same direction.
Ultimately, people understand scale, and are capable of enterprise thinking.
Do you know many companies that have a different telephone system for each business unit? They just need to be pointed out to this kind of thinking. This is the role of the CoE.
SOA is introducing new and complex processes and technologies while aiming at achieving sophisticated enterprise-wide goals. The panel hints the importance of establishing a CoE with a broad set of skills as a key success factor. What's your opinion? did you have a SOA CoE? did it play a critical role in the success of your projects? What was the degree of reuse of the services it produced?
[1] it is often said that no "product" can give you SOA, Dave is using "product" in this sense in the quote above
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
"SOA is introducing new and complex processes and technologies while aiming at achieving sophisticated enterprise-wide goals."
Well, there's your problem them. The technologies are neither new nor complex. It's called "the architecture of the web" and it's been used to achieve something more sophisticated than most enterprise goals. SOA is not a meaningful concept any more (people use it to mean just about anything).
-MattMc
Matt: a Service Oriented Architecture is an architecture that allows you to construct solutions from reusable assets. Our society is at large "Service Oriented", things like currency/banking, standards, transportation infrastructure (with different quality of services), addressing (zip codes,...), property rights... are key elements of the "architecture" of our society. Pretty much everything in our society is governed otherwise the degree of reuse will constantly miss the mark and lead to a lot of inefficiencies. I don't see how something accessible via "HTTP" guarantees reusability. Do you equate accessibility with reusability? If this is the case, this is quite naive. This would be the equivalent of saying, we only need a "transportation facility" in our society to guarantee reuse. We don't need currency/banking or any other capability. Do you think also that when a bridge or an airport is built, it has not been governed? Now as a technology , I don't know of any information system (such as ERP, CRM, PLM...) build in 100% RESTful way. Do you really think that the Web as an information system includes the capabilities that are necessary to build data and process centric information systems? If you have some examples, I'd love to have some pointers to them.
A reply to the last comment in my blog.
blogs.ittoolbox.com/eai/business/archives/soa-w...
Short quote:
It is interesting that in practice, real SOA projects, we find that WSDL is in fact an incomplete service contract. WSDL lacks semantic information (e.g. metadata about schemas). Starting with an annotated schema for example will give you more metadata than just the WSDL. And for very complex data domains we often start with a UML model then generate schemas by constraining the model. The domain model has still more metadata and formal definition.
Yet REST and now the WOA crowd continue to argue that SOA, contracts and governance are just unnecessary complexities. The whole web works off REST so why not every-one's IT shop? Just mash everything up without any contracts (stuff like security, transactions and service levels) and let it evolve.
"a Service Oriented Architecture is an architecture that allows you to construct solutions from reusable assets."
So is a component based architecture, or an object oriented design. That's not SOA- how is a service different from a component? A service is a running instance(s) of a component. So, by using SOA, I build a dependency on a running instance instead of a static component.
"Our society is at large "Service Oriented""
You are confusing the terms here. Just because the word "service" has some other meaning in other contexts has little impact on the actual bits and bytes flying around our networks. However, the business people like it when IT "serves" the business. I prefer IT to be part of the business.
People don't need governance to re-use a service- they need documentation and sample code.
"Yet REST and now the WOA crowd continue to argue that SOA, contracts and governance are just unnecessary complexities. The whole web works off REST so why not every-one's IT shop? Just mash everything up without any contracts (stuff like security, transactions and service levels) and let it evolve."
I agree- how do OpenID and GoogleMaps work without all of that? Oh wait, I don't agree.
Why not drop the whole SOA nonsense and just call it architecture? It's got nothing to do with the "services" concept. A WSDL doesn't tell me much semantically, it's true. That's why they invented documentation a few years ago. Not everything has to be done spewed out in XML.
Matt: more comments here.
thanks, I think you provided an outstanding summary of what REST is about. I could not have done that better myself.
Matt I don't care if you drop service and call it architecture. In fact I think modern applications are more than just services and SOA gets too much hype. The name is actually a bit unfortunate.
But I do think you need a contract for complex distributed systems. WSDL, XML and UML are useful in defining contracts. Much better than a Word doc. The WSDL and XSD can be interpreted programmatically. But, if everyone started using a new contract structure I would happily change but I suspect that WSDL will evolve and is here to stay.
I don't think utilities like Google Maps are OpenID are good examples of the need or lack of need for contracts. They are utilities and not business applications. Utilities have a singular function(s) and are much easier to define and reuse than business service and processes. We (IT) have always been good at reusing utilities, not so good at reusing business processes. Even a utility as complex as a relational database has a simple and consistent set of interactions - SQL. But a business performs many more complex functions - how do you describe them all? I don't think REST is the answer.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply