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