--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > The question I've got though is where are the references for a Data > first approach that lead to a "good" SOA.
That's a fair request, we'd all love to see real proof. I think one of the problems is how to judge the "goodness" of an SOA. It should be judged by how well it accomplishes its goals. But we as a community don't have consensus on what the goals of SOA are. This is obviously a huge, multi-layered question, but I think it starts at the top with something like, "the goal of SOA is business agility and IT cost savings". I think (or maybe just hope) there is consensus this is a major part of the goal. Next, I'd say you need an organization of services. But the definition of a service has no consensus. Things just get messier as you get deeper. No consensus on goals means no way to measure and no consensus on how to judge goodness. > > 2008/9/24 Kirstan Vandersluis <[EMAIL PROTECTED]>: > > Linthicum is speaking from experience that the data side is where > > groups fail the most, due to lack of understanding or > > underestimation of the scale of the problem. I certainly have seen > > this too. > > > > Rob & Steve, I personally question whether too much emphasis is > > placed on the SOA approach. Rob, your opinions express "SOA" as a > > verb... its how you design and partition services. I feel that SOA > > is a noun... it is an architecture and organization that you have > > (or end up with), and one that will bring business agility plus IT > > cost savings if it has the right service oriented qualities. > > Steve's book on SOA adoption strategies is one way to create one, > > but that doesn't mean there aren't others. Linthicum is suggesting > > leading with data is a valid way. We've heard lots of other > > opinions supporting entity services/core services that lean in that > > direction as well. If the result of this strategy is a successful > > SOA, its hard to argue with the approach. > > > The question I've got though is where are the references for a Data > first approach that lead to a "good" SOA. > Now I'm not saying that a > DOA can't deliver decent service but I do think that an approach that > separates service and process is liable to create a relatively poor > SOA. There are lots and lots of different ways to create an > architecture but a service oriented one surely has to be oriented > around the services I think we all agree. But the problem is we define "service" differently. Example: Erl's definition versus yours. > I'm never going to argue against anything that truly works, as opposed > to gets one project live. I agree, getting a project live does not automatically qualify as an SOA success for the company. > The question though is does this make a > change and transformation programme towards SOA succeed? There are > many different ways to get a project live, and data concentration can > be one of them, that doesn't mean that in 5 years time it will have > achieved and form of transformation of the IT estate towards a more > business, and less technically, oriented environment. Yes, IT should be business oriented, but I believe this includes IT resources being organized as services that are aligned with business functions and data. Services are building blocks for higher level business functions, and the business should be able to communicate changed or new functionality in terms of those building blocks. -Kirstan
