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. -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 >
