No, Anne, I did not miss your point (Phoenix of Service Orientation, 
http://www.ebizq.net/blogs/service_oriented/author/michael_poulin_1/2009/01/), 
I very much agree with your point.

Let me elaborate a bit more on how SOA appeared in the conference, IMO. I
think, Stefan Tilkov (who hosted the SOA Track) will be able to correct me or
add more.

1. I did not hear that people claimed SOA failure in the conversations and in
the presentations but this does not mean they disagreed with death of SOA-in
-IT

2. Those who mentioned Web Services with regard to SOA always commented that
they modified as the service-oriented middleware as the Web Service usability
style to make them work. Nobody talked about the use of ESB as a vendor product
but rather used it as a concept rearranging 'features' and stripping ESB from
almost all of them except for the core network.

3. I have found (with a surprise) that many criticised Web Services/WSDL for
inflexibility. 

4. I also found that people talked about the Services in the context of
adopting business changes instead of integration. This leitmotiv sounded in
almost every second presentation even if it was not dedicated to SOA. I also
talked about it in my presentation and was quite nervous about it. It was a
great pleasure to me to find the real understanding and support in the
audience. 
 
5. I can confirm your conclusion – those who
were satisfied with their SOA experience did not use Web Services for
integration calling this ‘SOA’. The overall impression I’ve got is that SOA
Architects started looking more and more into Business for SOA tasks than into 
Technology.
 
6. As I mentioned, a lot of presentations
that did not put ‘SOA’ in to the title talked about SOA as of regular thing. I
think, this is the sign of SOA, more accurately – Service Orientation, maturity
and commoditisation in the form of concept and approach to solving business
problems. 


-Michael




________________________________
From: Anne Thomas Manes <[email protected]>
To: [email protected]
Sent: Friday, March 13, 2009 2:52:33 PM
Subject: Re: [service-orientated-architecture] Roch on SOA Failures


Mike,

But how do they measure success/failure?
Individual projects might be successful, but does that mean that the
initiative as a whole is a success?

Most organizations that I've spoken to are using service-oriented
middleware to do integration (SOI rather than SOA). Very few companies
are actually rearchitecting their systems, i.e., simplifying their
applications and data architectures in order to increase agility.
Instead they are using WS-* or something similar to implement open
interfaces to their existing applications (i.e., JABOWS). Over time,
JABOWS typically results in increased architectural complexity and
systems that are more fragile and more expensive than ever before.
Although initially the initiative appears to be successful, the long
term effect is actually a failure.

The best way to measure success is to measure it from the bottom line.

If an organization invests $15 million in infrastructure, education,
new hires, consultants, project costs, etc, over the course of 5
years, how long will it take the organization to recoup that
investment and start realizing benefits that can be quantitatively
measured? Can they now actually deliver new solutions in less time and
for less money than they could 5 years ago? Are their savings
sufficient to offset the 5 year investment? If so, then I would agree
that the initiative has been successful. If not, then you need to
reassess the initiative and figure out why it has not delivered its
promised benefits.

I have seen a small number of spectacular success stories. These
companies have realized huge savings, they are able to deliver new
solutions in significantly less time than before. All of these
companies adopted SOA as part of a much larger IT transformation
effort, and they really focused on the architectural aspects of SOA.

I have also seen a number of companies that are starting to realize
small cost savings and increased agility, but it's taken them 6+ years
to get there, and they have not yet recouped their initial $15 million
investment. It will probably take them another 3-4 years to break
even. These companies will eventually be successful, but I suspect the
business would think twice before making this type of long-term
investment again.

And just in case you miss my point, I still strongly encourage
organizations to invest in SOA. But my primary recommendation is to
focus on architecture rather than technology. The goal of the program
should focus on reducing the complexity and redundancy of the
applications and data architecture.

Anne

On Fri, Mar 13, 2009 at 3:46 AM, Michael Poulin <m3pou...@yahoo. com> wrote:
> I am at QCon conference in London for last few days.  As you can guess, I am
> spending my time around SOA in here. I have seen a full auditorium of
> representatives of different companies that who do NOT claim SOA failure...
> - Michael
>
> ____________ _________ _________ __
> From: Gervas Douglas <gervas.douglas@ gmail.com>
> To: service-orientated- architecture@ yahoogroups. com
> Sent: Friday, March 13, 2009 1:19:32 AM
> Subject: [service-orientated -architecture] Roch on SOA Failures
>
> <<There are wide views on what SOA is and its benefits. Many companies have
> claimed success and many pundits point to a high volume of failures. But if
> we cannot agree on what SOA is then how can we declare success?
>
> We can think of SOA as a set of valuable business services that have
> positive ROI then in financial terms it should be considered a success. We
> know that building services, from a technical perspective is very easy
> (trivial really); building the right services is harder but not rocket
> science so where are so many projects going wrong?
>
> After working on many SOA projects and talking with companies and architects
> all over the world I firmly believe that most SOA failures are by far due to
> overspending or mistimed spending. If you don't spend a lot of money it's
> hard to get the failure label slapped on your efforts. If you build a few
> .NET web services and no one but you uses them I don't think people will run
> around calling you a failure. But, many companies have spent millions of
> dollars on SOA software, infrastructure and consulting dollars with no idea
> how to justify the costs. That's bound to get noticed.
>
> They might have promised executive management reuse or agility or some other
> intangible benefit to get the big bucks and then looking back over a couple
> of years cannot qualify the benefits of the spend.
>
> I said long ago, "Show me actual projects with tangible benefits and ROI and
> prove how SOA will benefit these projects. Intangible benefits, like
> agility, can and must be quantified." Maturing SOA processes like governance
> should be a goal but many have placed things like platform architecture and
> governance ahead of the projects with tangible ROI.
>
> As a good example, I recently talked to a company that spend millions of
> dollars on SOA software and are now spending the next 18 months on their
> architecture frameworks and governance model. I have to wonder, given the
> time value of money, how that company will ever get to positive ROI.
> Especially since no one is actually talking about business related projects
> yet or even in the near future! All of this money was spent on toys for
> architects.
>
> But I have seen improvements in cost justification this year. With the
> recession many companies are questioning every dollar spent. Everywhere I go
> I am asked out to start SOA with low costs or with open source. I tell
> people to start slow and spend little money early and improve processes over
> time as benefits arrive to pay for them.
>
> Find that great first project with a solid SOA entry point like integration
> or process improvement and don't spend a ton of money early. Once you start
> getting some project successes start investing more money on tools and
> process. Then you will have a better idea on what you really need based on
> real experiences and business driven project requirements.
>
> What do you think? Why have so many failed with SOA?>>
>
> You can read this at: http://it.toolbox. com/blogs/ the-soa-blog/
> what-constitutes -a-soa-failure- 30498
>
> Gervas
>
> 

   


      

Reply via email to