Anne as a question on this, are the books of record the post-transactional elements or the in-flow elements? It looks below as if they are post transactional, and I've always been in with the idea of shared services around post-transactional data.
There is an interesting question here about sectorisation of approaches. Finance is a hugely data centric industry (arguably its just a set of massive Excel spreadsheets) where the data is the only thing that actually exists, there is very little physicality (or as we are seeing right now, very little connection to reality!). Most of my work has been in more physical industries where data is just a representation of a physical reality and where changes in the physical world are the RWEs of most services. Steve 2008/9/28 Anne Thomas Manes <[EMAIL PROTECTED]>: > I can cite an excellent success story that adopted a data-first > approach, although I am not at liberty to identify the company. The > enterprise architecture team in the group insurance business in a > large insurance company spent a great deal of time working with their > business people to understand the issues that impede business. They > determined that the fundamental challenge they had to address was to > enable better sharing of data among their various business systems > (e.g., claims, policy management, underwriting, billing, etc). The > inability to quickly and easily share high quality information among > these systems was impeding their business processes. They determined > that the goals of their SOA initiative ought to be to improve data > quality and business process efficiency. (I found these goals to be > refreshingly practical rather than the usual "reduce cost and increase > agility".) > > They set to work defining what they call "books of record" for their > key data entities. They identified the sources of truth for these > books of record and defined mappings from their various applications > and databases to these formats. (i.e., a master data management > exercise). They created services that enable access to the books of > record (i.e., data services), and they used these books of record as > the foundation for their service message inputs and outputs. > > The results of this initiative have been extremely successful -- i.e., > they have met their goals to improve data quality and increase > business process efficiency. When they started the initiative, the > business groups viewed the IT organization as an "order-taker". Now > they view it as a partner that can deliver significant value to the > business. > > Anne > > On Fri, Sep 26, 2008 at 1:08 AM, Kirstan Vandersluis <[EMAIL PROTECTED]> > wrote: >> --- 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 >> >> >
