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, otherwise its a different type of orientation. I'd certainly argue that one that considers Data/Service/Process independently isn't SOA except in a small intermediary sense. I'm never going to argue against anything that truly works, as opposed to gets one project live. 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. There are lots of ways to create a strong SOA change programme, but surely one of the pre-requisites of being service oriented is being... well service oriented. Steve > > -Kirstan > > --- In [email protected], "Rob Eamon" > > <[EMAIL PROTECTED]> wrote: >> >> +1. >> >> Starting with data is a data/object-oriented approach, not an SO >> approach. Data is important most certainly, but in SO the service > is >> king and that's where one should start. The inputs/outputs are > driven >> by desired capabilities of the service, not the other way around. >> Identify the services first, then define the data formats and >> semantics. >> >> Haven't we had several "data first" approaches in the past? SQL > was >> going to be the savior of the data-starved business person. OO > (data >> with behavior) was finally going to deliver the agility craved by >> enterprises. Integration still predominantly focuses on > replicating >> data. >> >> The desire for data first is understandable I suppose. We have a > long >> history of "I just need that customer data" or "we need to send > the >> order data over to system X". This is still the >> predominant "requirement" for most IT projects it seems. "Get that >> data from there over to there." >> >> But SO is supposed to be different. There is data involved but the >> focus isn't on just moving it around. The focus is on "what do you >> need to do?" In an SO approach, the answer cannot be "I need to > get >> the customer data." Data access is not a "capability." >> >> An SO approach will redirect such "requirements": >> >> A: "We need the customer data from system X." >> >> B: "Okay, what are you going to do with it? What led you to the >> conclusion that you need customer data from system X?" >> >> A: "Well we're doing this marketing campaign. We're sending direct >> mailers to customers matching various demographics. We need system > X >> customer data to do that." >> >> IMO, even when folks say that they need access to data, they will >> have started out with some "service", action or capability in > mind. >> They want to do something. They don't want the data just because > it's >> there. >> >> IMO, a data first approach undermines SO rather than promotes. >> >> -Rob >> >> --- In [email protected], "Steve > Jones" >> <jones.steveg@> wrote: >> > >> > This is where I disagree. You need to know the capabilities and > the >> > services first in order to the concern yourself with the data > inputs >> > and outputs. I completely agree that the definition of data > formats >> > is important and that interfaces should be designed to be > consumer, >> > rather than producer, friendly. Dave says below that people are >> > getting it wrong by starting with "services or processes". > Maybe a >> > data centric view doesn't lead to Single canonical form, but it > has >> > done when I've seen organisations take this approach. >> > >> > If you aren't starting with the services how can it be service >> > oriented? Surely that would be a Data Oriented Architecture? >> > >> > To know where data is appropriate you have to understand the >> > services and the capabilities. There are certain data reporting >> > elements (post transactional) where unified views make sense and >> > its important to understand those as well, but the important bit > is >> > to first understand the services. I'm not saying data isn't >> > important but that a view that says "start with the data, then > work >> > up to the services, then the agile layer" implies that services > sit >> > between a data view and a process view, something that only > makes >> > sense in a technically oriented, rather than business oriented, >> > view of SOA. >> > >> > Data is important and you need to understand it, but starting > with >> > it? >> > >> > Steve >> > >
