Loading ...
Sorry, an error occurred while loading the content.
 

Re: BOA & SOA

Expand Messages
  • remyfannader
    I 100% agree with the importance of identities. I would add that the way objects and processes are identified is pivotal for requirements analysis as well as
    Message 1 of 70 , Feb 29, 2012
      I 100% agree with the importance of identities. I would add that the way
      objects and processes are identified is pivotal for requirements
      analysis as well as for enterprise and systems architectures.
      http://caminao.wordpress.com/how-to-represent-objects-and-activities/ide\
      ntities-2/
      http://caminao.wordpress.com/2012/02/01/objects_with_attitudes/
      Remy.
      --- In service-orientated-architecture@yahoogroups.com, Steve Jones
      <jones.steveg@...> wrote:
      >
      > On 28 February 2012 20:50, David Tildesley davotnz@... wrote:
      >
      > > **
      > >
      > >
      > > Hi Michael,
      > >
      > > << Michael said: Getting back to CDM, I am not sure that we have to
      call
      > > a domain data model canonical;>>
      > >
      > > That's what I was saying: CDM is not the domain model but it can be
      > > derived from it (it's a pale reflection, stripped of behaviour) and
      CDM
      > > doesn't have to exist as a class diagram/model apart from
      convenience if
      > > you are using a modelling tool that does MDA to xml schemas (e.g
      Sparx).
      > > The xml schemas end up being the embodiment of the CDM.
      > >
      >
      >
      > > <<Michael said: However, I do not recall any significant
      participation of
      > > Business in the modelling that time...>>
      > > It was the FDD process (Jeff De Luca) that pioneered the domain
      modelling
      > > process (using the color modelling technique) that directly engages
      the
      > > business with IT in a joint domain modelling workshoop. It works and
      it
      > > works well.
      > >
      > > <<Michael said: Also, probably, the most unaccetable part of CDM
      (for me)
      > > is a single definition of semantic and ontology mandatory for all
      business
      > > units and IT - I do not believe it is realistic and not not think is
      > > necessary>>
      > >
      > > I suspect you are saying that because you have witnessed IT making
      the CDM
      > > decisions as opposed to encouraging the business to agree and decide
      using
      > > consensus techniques on canonical names (part of the internal
      ontology of
      > > the business).
      > >
      >
      > I'm saying it because I work 90% of the time on defining these
      standards
      > with business people and we agree on two things every time
      >
      > 1) Identification is the key
      > 2) local business areas need agility
      >
      > This is why a technical centric approach like CDM (and it is
      technically
      > centric) misses the point. When area A talks to area B about
      Individual X
      > the only thing required is that both A and B are able to identify X as
      the
      > same individual in the real world.
      >
      > The net effect of this in technology is that MDM with its system x-ref
      > approach is much better at ensuring the flexibility AND the assurance
      than
      > a transaction centric approach like CDM.
      >
      > Steve
      >
      >
      >
      > >
      > > Regards,
      > > David.
      > >
      > > *From:* Michael Poulin m3poulin@...
      > > *To:* "service-orientated-architecture@yahoogroups.com" <
      > > service-orientated-architecture@yahoogroups.com
      > > *Sent:* Wednesday, 29 February 2012 1:25 AM
      > > *Subject:* Re: [service-orientated-architecture] Re: BOA & SOA
      > >
      > >
      > > Hi David,
      > >
      > > actually, I worked with Coad's color modelling and was a big fan of
      > > TogetherJ for years (starting with their first presentation in the
      US). I
      > > think, I still has it on my machine. However, I do not recall any
      > > significant participation of Business in the modelling that time...
      > >
      > > As of "Maybe someday someone will put the business back into SOA" -
      it is
      > > done already in OASIS SOA RAF committee specification, Draft 3
      (June, 2011)
      > > where SOA ecosystem is positioned in between business and technology
      and in
      > > both of them. Also, I've just written a book about service
      orientation of
      > > business (and Steve still has not responded with promised
      review...).
      > >
      > > I think that Martin Fowler made this observation because of two
      factors:
      > > 1) misunderstood value of SOA in industry and substitution of it by
      > > technology that could not provide for promises of architecture and
      service
      > > orientation (there is no service orientation in Web Services and
      related
      > > integration); so, he wanted to distance technology from a failure
      announced
      > > in 2009 ("SOA is Dead"); 2) he intuitively recognised that service
      > > orientation shifts focus from objects to functions making objects an
      > > implementation, not driving, means (as in my DOSOM + DDD approach).
      > > Moreover, SOA shifts attention from developers to architects, which
      is not
      > > very appreciated by Martin as well. Real SOA now has very little in
      common
      > > with SOA 2005.
      > >
      > > Getting back to CDM, I am not sure that we have to call a domain
      data
      > > model canonical; I used to think about canonical model that
      comprises
      > > domain model and that is mandatory for all to use. Also, probably,
      the most
      > > unaccetable part of CDM (for me) is a single definition of semantic
      and
      > > ontology mandatory for all business units and IT - I do not believe
      it is
      > > realistic and not not think is necessary. MDM with appropriate
      domain /
      > > service semantic mapping solve the problem.
      > >
      > > - Michael
      > >
      > >
      > >
      > > *From:* David Tildesley davotnz@...
      > > *To:* service-orientated-architecture@yahoogroups.com
      > > *Sent:* Tuesday, February 28, 2012 9:59 AM
      > > *Subject:* [service-orientated-architecture] Re: BOA & SOA
      > >
      > >
      > > Hi Michael,
      > >
      > > Unlike DDD, when using the color modelling technique, IT and the
      business
      > > experts are jointly and totally focused on the business problem
      domain, not
      > > the technology . I suspect we may be on a similar looking page,
      except the
      > > difference being the 10+ years of pioneering modelling across
      multiple
      > > business domains that underpinned the eventual publishing of the
      color
      > > modelling with UML technique by Peter Coad, Jeff de Luca & co.
      > >
      > > And by saying this, I don't mean to dis DDD - it's just that I found
      the
      > > majority of the book interesting but irrelevant to the task of
      domain
      > > modelling and too focused on application design - services,
      factories,
      > > repositories, value objects, etc.
      > >
      > > The key takeaways from DDD:
      > >
      > >
      > > - "The domain layer is where the model lives" - pg 75
      > > - The whole of chapter 2 "Communication and the Use of Language"
      > >
      > > More importantly, Eric put the 'business" back into "business
      > > application".
      > >
      > > Maybe someday someone will put the business back into SOA.
      > >
      > > Martin Fowler made an observation back in 2005:
      > > http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
      > >
      > > Would he make the same comment in 2012?
      > >
      > > David.
      > >
      > >
      > > --- In service-orientated-architecture@yahoogroups.com, Michael
      Poulin
      > > m3poulin@ wrote:
      > > >
      > > > I talked to Eric about a domain design for services and he agreed
      with
      > > my approach based on DOSOM rather than on DDD (for _services_).
      > > >
      > > >
      > > > - Michael
      > > >
      > > >
      > > >
      > > >
      > > > >________________________________
      > > > > From: David Tildesley davotnz@
      > > > >To: "service-orientated-architecture@yahoogroups.com"
      > > service-orientated-architecture@yahoogroups.com
      > > > >Sent: Monday, February 27, 2012 12:29 AM
      > > > >Subject: Re: [service-orientated-architecture] BOA & SOA
      > > > >
      > > > >
      > > > >Â
      > > > >The answer is that it is not up to me or you to decide what is
      the
      > > boundary of any given business domain. As I said - there could be
      more than
      > > one within a large and complex organisation and therefore several
      CDMs.
      > > > >Just simply attempting to model the boundaries/scope would be a
      step
      > > forward in terms of offering some clarity for most organisations.
      > > > >Â
      > > > >If in the case of a homogenous business domain, one part ofÂ
      the
      > > business calls a customer a client while the other calls a
      client a
      > > customer then it's about time they sorted that out amongst
      themselves. One
      > > of the big benefits of DDD (and is very true of consensus based
      domain
      > > modelling) is the "Ubiquitous language" outcome is it not? (at least
      that
      > > was what Eric Evans was reinforcing - which I happen to agree with
      whole
      > > heartedly).
      > > > >Â
      > > > >Sorry haven't got time right now to comment on the rest - weekend
      is
      > > over, grafting has begun.
      > > > >Â
      > > > >David.
      > > > >Â
      > > > >
      > > > >
      > > > >From: Michael Poulin m3poulin@
      > > > >To: "service-orientated-architecture@yahoogroups.com"
      > > service-orientated-architecture@yahoogroups.com
      > > > >Sent: Monday, 27 February 2012 2:24 AM
      > > > >Subject: Re: [service-orientated-architecture] BOA & SOA
      > > > >
      > > > >
      > > > >Â
      > > > >I'd like to join Steve and ask: how do you define 'domain' or
      'business
      > > domain'?
      > > > >
      > > > >
      > > > >For example, you have a business domain of "Client" with a
      sub-domain
      > > of "Customer" because one Client can appear as several Customer to
      your
      > > company. At the same time, in the business part of your company, one
      > > Division calls particular external business a Clients while another
      > > Division calls the _same_ external business a Customer; and they
      disagree
      > > with any attempts to call them differently. Thus, you have a single
      > > "domain" with no sub-domains...
      > > > >
      > > > >
      > > > >In my experience with Steve's example of canonical model of
      Customer, I
      > > have not found one business unit that used all fields/elements of
      described
      > > canonical definition. Consequently, they denied using the whole
      data-set in
      > > their operations and in the systems that 'owned'; everyone wanted
      its own
      > > sub-view on the canonical model of Customer. As a result, the
      canonical
      > > model of Customer was used and existed in IT only (what a great
      agility!)
      > > > >
      > > > >
      > > > >- Michael
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >From: Steve Jones jones.steveg@
      > > > >>To: service-orientated-architecture@yahoogroups.com
      > > > >>Sent: Sunday, February 26, 2012 9:49 AM
      > > > >>Subject: Re: [service-orientated-architecture] BOA & SOA
      > > > >>
      > > > >>
      > > > >>Â
      > > > >>
      > > > >>
      > > > >>
      > > > >>On 26 February 2012 06:07, David Tildesley davotnz@ wrote:
      > > > >>
      > > > >>
      > > > >>>Â
      > > > >>>Hi Steve (and Michael - hope you don't mind if I answer your
      concerns
      > > here as well).
      > > > >>>
      > > > >>>
      > > > >>>It's good that we are getting a little closer to the core of
      the
      > > subject matter and I feel the need to explain some terminology that
      I used.
      > > > >>>
      > > > >>>
      > > > >>>"Domain Model" - as per Martin Fowler's description. "Domain
      > > Modelling" - first phase of FDD "Develop an overall model". Â
      Domain is
      > > business problem focused. Domain modelling must be consensus based
      effort
      > > involving both business and IT. Domain modelling is best done in
      chunks,
      > > carving off sub domains of the overall business domain and letting
      each
      > > chunk be informed by the chunks that have gone before.
      > > > >>>
      > > > >>>
      > > > >>><< Steve says "The concept of product in sales is not the same
      as the
      > > concept in supply chain, not only will they have different
      attributes but
      > > they may represent completely different things. Â Customer
      doesn't 'live'
      > > in a single domain, the logistics area needs to know where to ship
      to..." >>
      > > > >>>
      > > > >>>
      > > > >>>True that depending on the business domain, "Product" may be
      quite
      > > different from one business domain to another. Â But that's not
      the point,
      > > the point is that a  CDM is for a particular business domain -
      another
      > > business domain can/should have a different CDM that is specific to
      it. On
      > > the other hand a well decoupled model will have  one
      "component" that is
      > > say centered on e.g. a "sale" (a moment-interval archetype) that
      will
      > > include a reference to the Customer (Party archetype) component.
      Each
      > > recognizable component of the CDM is a strong candidate for a SOA
      entity
      > > service. The natural decoupling point of a component is usually the
      role
      > > archetype (a Party, Place or Thing playing a role with respect to a
      > > Moment-Interval). The overall CDM is therefore a set of loosely
      coupled
      > > components that fall out of the domain modelling exercise that
      specifies
      > > the business layer of the functional (business logic, rules etc)
      components
      > > of the business. Because
      > > > domain modelling is/should be a consensus based joint exercise
      with IT
      > > and the business, the names of the objects/entities are also
      consensus
      > > based with full business involvement.Â
      > > > >>
      > > > >>
      > > > >>Lets get specific here on what you mean as 'canonical'
      > > > >>
      > > > >>
      > > > >>Lets take Customer
      > > > >>
      > > > >>
      > > > >>A fully canonical model for customer would include
      > > > >>Name (prefixes, given, middle, surname, suffixes), Alternate
      Names
      > > > >>DOB, Gender
      > > > >>
      > > > >>
      > > > >>Identity documents (Passport, driving license)
      > > > >>Physical identity (depends on company/use) (iris, fingerprint)
      > > > >>Addresses:
      > > > >>Postal Addresses
      > > > >>Email Addresses
      > > > >>Phone numbers
      > > > >>Social media addresses
      > > > >>
      > > > >>
      > > > >>
      > > > >>
      > > > >>This is just the 'core' information, so would your canonical
      model
      > > that is passed between services to represent the customer include
      this?
      > > > >>
      > > > >>
      > > > >>Then we move onto the business associations, so lets take a bank
      a
      > > customer also has
      > > > >>
      > > > >>
      > > > >>Risk Assessment,
      > > > >>AML status
      > > > >>Accounts, Loans, etc
      > > > >>
      > > > >>
      > > > >>Those accounts and loans have their own addresses and
      potentially
      > > their own identity processes. Â In addition those accounts have
      balances,
      > > terms, contracts etc. Â These have multiple other associations.
      > > > >>
      > > > >>
      > > > >>So where in your CDM world would you draw the line at the
      Canonical
      > > definition of customer? Â The 'Core', the associations such as
      Risk etc
      > > which are customer specific, the relationship to accounts etc, the
      > > relationship of those accounts to assets... or at some other point.
      > > > >>
      > > > >>
      > > > >>How much of this has to be populated for a service to service
      > > invocation to be considered valid.
      > > > >>Â
      > > > >>
      > > > >>
      > > > >>This would really help me understand how practical your CDM
      approach
      > > is...
      > > > >>
      > > > >>
      > > > >>Steve
      > > > >>
      > > > >>>
      > > > >>>The "canonical" in CDM is a synonym for "standard", however the
      key
      > > thing here (and perhaps the main cause of confusion in this thread)
      is that
      > > CDM is a model that is standard for the business it serves and not
      for
      > > someone else's business, or for that matter, another part of a large
      and
      > > complex enterprise that is composed of entirely different
      businesses.Â
      > > > >>>
      > > > >>>
      > > > >>>Each SOA service then has a contract that contains an XML
      schema that
      > > is simply a view on a domain component (not be confused with XML
      > > terminology for a component).
      > > > >>
      > > > >>
      > > > >>
      > > > >>
      > > > >>Â
      > > > >>
      > > > >>>
      > > > >>>I would agree that if you don't have consensus domain modelling
      as a
      > > discipline in your organisation, then your chances of creating a CDM
      are
      > > near zero. Is this not the main reason why CDM efforts (and
      consequently
      > > SOA also) Â have failed? - they didn't stand a chance of
      succeeding in the
      > > first place in many organisations due to the parlous state of the
      business
      > > applications and the lack of consensus based domain modelling
      > > > >>>
      > > > >>>
      > > > >>>Regards,
      > > > >>>David. Â
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>From: Steve Jones jones.steveg@
      > > > >>>To: service-orientated-architecture@yahoogroups.com
      > > > >>>Sent: Sunday, 26 February 2012 5:38 AM
      > > > >>>
      > > > >>>Subject: Re: [service-orientated-architecture] BOA & SOA
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>Â
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>On 24 February 2012 10:57, David Tildesley davotnz@ wrote:
      > > > >>>
      > > > >>>
      > > > >>>>Â
      > > > >>>>Steve, your idea of a canonical model is in fact yet another
      > > strawman. Here is your statement from the post you quote (oh ...
      wait it
      > > happens to be one of your own posts ... what a co-incidence):
      > > > >>>>
      > > > >>>>
      > > > >>>><<Therefore, design a Canonical Data Model that is independent
      from
      > > any specific application. Require each application to produce and
      consume
      > > messages in this common format.>>
      > > > >>>>
      > > > >>>>
      > > > >>>>Wrong on both counts. I suspect the problem may be that when
      you
      > > think of a "canonical data model", you think of the likes of CIQ,
      FpML etc.
      > > and you are quoting folk who think it's a good idea to use such
      external
      > > models within their enterprise in the vague hope it may match what
      their
      > > enterprise needs in the way of a CDM. Such folk are just lazy and
      belong in
      > > the same camp as those that think they can build a business
      application
      > > without doing any domain modelling. In fact they are the same folk
      that go
      > > and buy dozens of COTS packages with overlapping functionality and
      with
      > > only a small fraction of useful functionality at inflated prices,
      requiring
      > > expensive "experts"to install and customise them to the point where
      they
      > > are hard to upgrade. Then after creating COTS hell where "customer"
      exists
      > > in multiple COTS application , go and propose management fork out
      for a MDM
      > > as a "solution" to the mess. Then the vendors change their product
      roadmap,
      > > or get
      > > > swallowed up by bigger vendors and you get left with white
      elephants.
      > > But wait, I digress.
      > > > >>>>
      > > > >>>>
      > > > >>>>
      > > > >>>>Here's the thing - if we take the COTS mess out of the picture
      for a
      > > minute and assume that each business application covers a
      particular
      > > domain (e.g one of: Customer, Party, Identity, Correspondence,
      Account,
      > > Journal, Asset, ...). Then we assume that the people who built each
      > > application had the common sense and foresight to model the
      domain, lo
      > > and behold, they quickly discover they already have their CDM - a
      loosely
      > > connected bunch of component models taken from their own application
      domain
      > > models, corresponding more or less to the significant business
      entities at
      > > the centre of the components, converted into xml schemas. i.e a CDM
      that
      > > reflects their business exactly. Now they can get on and
      compose BPM
      > > automation to quickly deliver high business value services while
      their
      > > competition are fighting fires in the COTS hell.
      > > > >>>
      > > > >>>
      > > > >>>Â
      > > > >>>
      > > > >>>>
      > > > >>>>Ok, now lets put some of the COTS mess back in the picture
      (it's
      > > pretty hard to avoid - and they are not all bad, and you will have a
      > > mixture of COTS and custom in your enterprise). Let's say you are
      lucky and
      > > the COTS package exposed its functionality as services /API. But of
      course,
      > > the COTS package service model doesn't match your enterprise CDM. Do
      you
      > > complain to the vendor that they should match your CDM? No, they
      will laugh
      > > at you - just like the SAAS providers will laugh if you pull the
      same stunt
      > > on them. Instead, you will simply do the obvious - adapt and
      transform.
      > > > >>>>
      > > > >>>
      > > > >>>
      > > > >>>David,
      > > > >>>
      > > > >>>
      > > > >>>I'm genuinely confused by what you are proposing. Â The
      domain models
      > > from one business model are highly unlikely to be decent and
      shareable.
      > > Â The concept of product in sales is not the same as the
      concept in supply
      > > chain, not only will they have different attributes but they may
      represent
      > > completely different things. Â Customer doesn't 'live' in a
      single domain,
      > > the logistics area needs to know where to ship to...
      > > > >>>
      > > > >>>
      > > > >>>You appear to deride MDM but what you appear to be proposing is
      in
      > > fact a single operational real-time MDM solution where a single
      domain
      > > controls a given entity and others query that. Â Good MDM
      solutions these
      > > days actually don't try and have all of the information about a
      given
      > > entity but instead provide the core information and the cross
      reference to
      > > where other information can be found.
      > > > >>>
      > > > >>>
      > > > >>>CDM is a bad idea, using MDM to provide the keys,
      transformation and
      > > x-ref is a good idea. Â So yes adapt and transform.... and that
      is what MDM
      > > + SOA enables, you should adapt and transform based on the keys for
      the
      > > core entities not try and do it based on the attributes.
      > > > >>>
      > > > >>>
      > > > >>>Steve
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>>Â
      > > > >>>
      > > > >>>>
      > > > >>>>David.
      > > > >>>>
      > > > >>>>From: Steve Jones jones.steveg@
      > > > >>>>To: service-orientated-architecture@yahoogroups.com
      > > > >>>>Sent: Thursday, 23 February 2012 11:48 PM
      > > > >>>>
      > > > >>>>Subject: Re: [service-orientated-architecture] BOA & SOA
      > > > >>>>
      > > > >>>>
      > > > >>>>Â
      > > > >>>>I don't quite agree on every single level. Â CDM is a bad
      idea
      > > full-stopÂ
      > >
      http://service-architecture.blogspot.com/2006/08/single-canonical-form-n\
      ot-for-soa.htmlwhether internal or external its a bad idea and
      externally its just dead in
      > > the water.
      > > > >>>>
      > > > >>>>
      > > > >>>>Steve
      > > > >>>>
      > > > >>>>
      > > > >>>>On 22 February 2012 08:56, David Tildesley davotnz@ wrote:
      > > > >>>>
      > > > >>>>
      > > > >>>>>Â
      > > > >>>>><<"...If you consider the impossibility of imposing the
      canonical
      > > data model on your next SaaS provider, the virtue of this approach
      becomes
      > > apparent.">>
      > > > >>>>>
      > > > >>>>>
      > > > >>>>>What? CDM is for internal SOA consumption, it makes no sense
      to
      > > force it on external parties. This is nothing but a straw man
      argument.
      > > > >>>>>
      > > > >>>>>
      > > > >>>>>David T.
      > > > >>>>>
      > > > >>>>>
      > > > >>>>>
      > > > >>>>>From: Gervas Douglas gervas.douglas@
      > > > >>>>>To: service-orientated-architecture@yahoogroups.com
      > > > >>>>>Sent: Tuesday, 21 February 2012 11:53 AM
      > > > >>>>>
      > > > >>>>>Subject: [service-orientated-architecture] BOA & SOA
      > > > >>>>>
      > > > >>>>>
      > > > >>>>>Â
      > > > >>>>><<The adage of â€Å"No Pain, No Gain�
      isn’t just for sports.
      > > While all organizations fantasize about a fully-integrated IT
      paradise that
      > > works seamlessly across departments, groups and geographies, few
      actually
      > > sign up to experience the pain involved in the process of
      integration.
      > > > >>>>>The only reason anybody spends money on integration at all is
      > > because software, as a rule, doesn't integrate by itself. But no
      executive
      > > thinks that spending money on integration addresses a strategic need
      of the
      > > business. Instead, money spent on integration typically goes into
      fixing
      > > something that really shouldn't have been broken in the first place.
      > > > >>>>>Based on the traditional approach, a software application is
      > > defined with system-based requirements, its design, and then coding
      and
      > > testing within a well-defined software development lifecycle. The
      primary
      > > focus is on the code's implementation. As a result, integration with
      teams
      > > has traditionally been tightly coupled with little consideration for
      > > metadata. Today, integration solutions and paradigms have shifted
      the focus
      > > to code re-use and consolidated application solutions. This approach
      > > redefines the solution based on business-defined services - which is
      how it
      > > should have been done from the start.
      > > > >>>>>With the introduction of service-oriented architecture, the
      > > paradigm of business users creating application functionality was
      very
      > > exciting and led to a lot of buzz. This was done through building
      and
      > > managing business processes, all hosted on an enterprise service bus
      - thus
      > > disentangling the integration â€Å"spaghetti�
      forever. SOA abstracts the
      > > underlying technology, so that developers enmeshed in connecting
      systems
      > > and applications can now focus on building services. With a selling
      > > proposition like that, it was no surprise that everyone wanted a
      piece of
      > > the action.
      > > > >>>>>What Isn't Working with SOA
      > > > >>>>>However, for all the excitement SOA generated, the enthusiasm
      has
      > > dimmed a bit somewhere down the line. So, what happened?
      > > > >>>>>SOA is usually mistaken for a set of Web services defining a
      > > complete solution. Rather, SOA is a technology paradigm that
      supports the
      > > processes defined and governed by business. There has been a
      considerable
      > > investment in building SOA infrastructure already, but the payback
      has been
      > > slow, leading companies to invest in development of Web services
      rather
      > > than define a pure service bus.
      > > > >>>>>There is a perception of 'SOA' as a means to enable
      integration
      > > with legacy systems. Legacy encapsulation can certainly be a great
      enabler
      > > for business processes, but it doesn't substitute for an effective
      SOA
      > > strategy.
      > > > >>>>>A successful SOA initiative should focus on reducing
      complexity,
      > > transforming systems into services that implement core capabilities
      and
      > > eliminating redundancy. Further, it must define common patterns that
      apply
      > > to all business units and set up 'software factories' that enable
      the
      > > delivery of new products as services in a fraction of the time it
      used to
      > > take.
      > > > >>>>>A successful SOA initiative must begin with strategic
      investment
      > > and aim at lowering total cost of ownership as subsequent
      implementations
      > > takes place. For an organization to adopt this strategy, it needs to
      be
      > > mature enough to take the risk of initial investment. Organizations
      with a
      > > clear focus on implementation will reap long-term benefits. To
      define the
      > > SOA roadmap well, it is critical to understand that it is about
      processes
      > > or services definition as well as technology and people. (See Figure
      1,
      > > left.)
      > > > >>>>>What Should We Be Thinking About?
      > > > >>>>>Cut through the hype, be realistic. SOA has been overhyped,
      > > oversold and set up to fail. Headlines decrying the failure of
      strategic
      > > SOA projects tell tales of woe. In many cases, organizations that
      merely
      > > needed some straightforward extensions to their existing
      architecture were
      > > up-sold unwieldy architectures that proved impossible to deploy.
      It's a bit
      > > like starting to build a bypass for a town, but somewhere along the
      way the
      > > project grew to the size of a major city. Some useful reality
      checks:
      > > > >>>>> * Ensure relevance by grading usefulness of each solution
      fit.
      > > > >>>>> * Start small and deliver business value before becoming
      more
      > > ambitious.
      > > > >>>>> * Define a roadmap for the entire service lifecycle, not
      just
      > > service identification.
      > > > >>>>> * Ensure that SOA is requirements-driven and not
      demand-driven.
      > > > >>>>>Crack the whip and rein them in. Governance is one of the
      most
      > > abused terms in the SOA world. Many on the SOA team manage
      architectural
      > > principle exceptions to orchestrate grossly inappropriate solution
      > > architectures. Those who question them are labeled prudes and
      dismissed in
      > > the name of progressive architecture. It is imperative to determine
      and
      > > price-out the SOA solutions that actually provide significant value
      to
      > > business. Applications that provide very little value to business
      but cost
      > > an awful lot are the ones to eliminate first. Doing SOA right
      requires core
      > > services and infrastructure to be built before the high-visibility,
      > > high-value projects can be properly accomplished. It is important to
      ensure
      > > strict adherence of key projects to all governance mandates.
      > > > >>>>>Skip the canonical data model. Purists may shake their heads,
      but
      > > our experience has been that the enterprise canonical data model is
      not
      > > indispensable for an SOA initiative. The way forward is a federated
      MDM
      > > strategy and a brokerage approach to communication between systems.
      This
      > > should ideally be based around a distributed data strategy that
      leaves
      > > information in the source systems but provides references between
      them. If
      > > you consider the impossibility of imposing the canonical data model
      on your
      > > next SaaS provider, the virtue of this approach becomes apparent.
      > > > >>>>>Get on the dirty bus. The real enterprise service bus is a
      myth.
      > > The entire enterprise will never get on a single
      â€Å"bus.� This is
      > > primarily because there never will be a business case strong enough
      pull
      > > funding for the strategic service model on legacy systems. A more
      pragmatic
      > > approach would be to divide the enterprise bus into two logical
      sections:
      > > the clean data bus that hosts enterprise services adhering to the
      > > enterprise service framework, and the dirty bus to host specific
      services
      > > for legacy and non-adhering systems. The dirty bus clearly scores
      over the
      > > erstwhile point-to-point integration, offering greater control over
      > > auditing, logging and exception handling.
      > > > >>>>>Socialize and SLA(y) them. In order to ensure that SOA is
      useful,
      > > it will need to be used. Many an organization has lost the fruits of
      the
      > > SOA karma earned over the years because the services developed were
      not
      > > socialized enough. It is essential that the services are published
      through
      > > an elaborate (yet simple to read) service catalog to ensure that
      they are
      > > available across the enterprise for use. The other crucial factor in
      > > ensuring reuse (and indeed use as well) is to make results
      predictable.
      > > This is enforced through well-defined and closely monitored service
      level
      > > agreements. SLAs also bolster the business case by ensuring higher
      level of
      > > reliability in meeting business objectives.
      > > > >>>>>So(A), Where Should We Be Looking To Go?
      > > > >>>>>(See related Figure 2, left.)
      > > > >>>>>Is the future cloudy? Cloud computing is the rage today. It
      is
      > > obvious that SOA and cloud computing go hand-in-hand. Cloud
      computing
      > > encompasses any subscription-based or pay-per-use service that, in
      real
      > > time over the Internet, extends IT's existing capabilities. In
      essence,
      > > this is distributed computing. An application is built using the
      resource
      > > from multiple services, potentially from multiple locations. Behind
      the
      > > service interface is usually a grid of computers to provide the
      resources.
      > > The grid is typically hosted by one company and consists of a
      homogeneous
      > > environment of hardware and software, making it easier to support
      and
      > > maintain. Nothing really changes outside of that,
      > > > including the need to do SOA properly.
      > > > >>>>>Information as a service. Information as a service accepts
      the idea
      > > that data resides within many systems and repositories. The new
      paradigm's
      > > trick is to enable standardized access to this disparate data.
      Developing
      > > vast databases that have been wrapped and delivered as business
      > > intelligence snippets to the whole enterprise vastly increases the
      reach of
      > > critical BI. When you combine this concept with the federated mantra
      of
      > > cloud computing and build it on top of an agile SOA-based platform,
      the
      > > nebulous vision becomes much clearer.
      > > > >>>>>Integration as a service. Right now, three critical
      technologies
      > > (connectivity, policy enforcement and semantics) are available as
      > > capabilities and/or services within the SOA. The future will see
      IaaS
      > > infrastructure embedded in hardware or offered more often as managed
      > > services. Capabilities, such as analytics, will be offered as a
      real-time
      > > service. And this isn’t too far in the future: A major
      telecommunications
      > > company is now manufacturing an appliance with SOA integration built
      in.
      > > Attached in your basement, it connects you to services provisioned
      from
      > > within the company's network. These services go way beyond mere
      routing and
      > > transformation and provide full-blooded process orchestration
      capabilities.
      > > > >>>>>Lean and agile competency centers. In this rapidly changing
      > > business and technology landscape, the first-generation integration
      > > competency centers struggled to constantly deliver significant
      > > efficiencies, making it imperative to go beyond the obvious. Most
      > > organizations are moving toward defining a framework through the
      > > transformation of their organization into a â€Å"Lean
      ICC� - one that is
      > > agile, efficient and adaptable in responding to opportunities and
      threats.
      > > The Lean ICC shortens the awareness-to-adoption cycle with an
      accelerated
      > > ICC deployment process accompanied by comprehensive but crisp
      communication
      > > and change management. With a highly modularized yet integrated
      framework,
      > > such competency centers are tailored to the specific needs of
      business,
      > > with prioritization based on market dynamics, enterprise inertia,
      business
      > > priorities, investment strategy and ROI.
      > > > >>>>>To get ahead in the game, organizations must align IT with
      business
      > > strategy. Leveraging existing systems, ensuring acceptance across
      the
      > > enterprise and readily adapting to change can improve performance
      for
      > > competitive advantage. SOA is one critical change agent that can no
      longer
      > > be excluded from any serious IT strategy that aims to be a
      growth-enabler.
      > > Architectural assets without the overhead of owning, operating and
      > > maintaining them makes eminent sense.>>
      > > > >>>>>
      > > > >>>>>You can find this at:
      > >
      http://www.information-management.com/newsletters/SOA-cloud-as-a-service\
      -ROI-SLA-10021971-1.html?zkPrintable=1&nopagination=1
      > > > >>>>>
      > > > >>>>>Gervas
      > > > >>>>>
      > > > >>>>>
      > > > >>>>>
      > > > >>>>
      > > > >>>>
      > > > >>>>
      > > > >>>
      > > > >>>
      > > > >>>
      > > > >>
      > > > >>
      > > > >>
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > > >
      > >
      > >
      > >
      > >
      > >
      > >
      >
    • David Tildesley
      I haven t forgotten - just very busy at the moment. David.
      Message 70 of 70 , Mar 18, 2012
        I haven't forgotten - just very busy at the moment.

        David.
        --- In service-orientated-architecture@yahoogroups.com, Steve Jones <jones.steveg@...> wrote:
        >
        > On 8 March 2012 19:42, David Tildesley <davotnz@...> wrote:
        >
        > > **
        > >
        > >
        > > I'm sure that I can quite you a few dozen definitions for SOA and MDM from
        > > various sources that you won't be happy with. The same applies here. I
        > > haven't finished describing how the CDM is used and "mega-schema" approach
        > > is just a fetish as mentioned previously.
        > >
        >
        > Its odd to call something that is mainstream a fetish, but I am genuinely
        > interested in how your CDM approach works.
        >
        > Steve
        >
        >
        > >
        > > David.
        > >
        > > ------------------------------
        > > *From:* Steve Jones <jones.steveg@...>
        > > *To:* service-orientated-architecture@yahoogroups.com
        > > *Sent:* Friday, 9 March 2012 6:03 AM
        > > *Subject:* Re: [service-orientated-architecture] Re: BOA & SOA
        > >
        > >
        > >
        > >
        > > On 8 March 2012 09:39, David Tildesley <davotnz@...> wrote:
        > >
        > > **
        > >
        > > You are quoting EAI patterns. SOA is not about application to
        > > application integration.
        > >
        > >
        > > I was quoting the definition of the term, IFW is a canonical Web Service
        > > centric model approach. The principle remains the same. Canonical models
        > > are generally accepted as being 'mega-schema' approaches, whether EAI,
        > > DataWarehouse, SOA or Excel spreadsheets.
        > >
        > > Steve
        > >
        > >
        > > I'll have to leave the answer to the rest later when I have more time.
        > >
        > > David.
        > >
        > > --- In service-orientated-architecture@yahoogroups.com, Steve Jones
        > > <jones.steveg@> wrote:
        > > >
        > > > On 7 March 2012 09:24, David Tildesley <davotnz@> wrote:
        > > >
        > > > > **
        > > > >
        > > > >
        > > > > << I'd really love to see an example of what you consider then and
        > > > > exactly what sort of XSDs are passed between different business areas &
        > > > > services to enable transactions to be complete. >>
        > > > >
        > > > > This is where you keep reverting to your view of what a CDM is and then
        > > > > asking me to conform to it.
        > > > >
        > > >
        > > > Its not my view, its what CDM is
        > > >
        > > > http://eaipatterns.com/CanonicalDataModel.html
        > > > http://en.wikipedia.org/wiki/Canonical_Model
        > > > etc, etc.
        > > >
        > >
        > > You are quoting EAI patterns. SOA is not about application to application
        > > integration.
        > >
        > > >
        > > > >
        > > > > The xsd's for a particular service contract are a realisation of a
        > > > > particular view of the canonical data model - they are not the
        > > canonical
        > > > > data model. That particular view of the CDM expressed as xsd schema is
        > > > > unique to that particular service.
        > > > >
        > > >
        > > >
        > > >
        > > > >
        > > > > e.g.
        > > > >
        > > > > Party Relationship
        > > > > Management. The PRM scope is creating and tracking of the
        > > > >
        > > > > relationships between parties that are relevant to the business and of
        > > > > value to track.
        > > > >
        > > >
        > > > > e.g.:
        > > > >
        > > > >
        > > > > - BillingContact
        > > > > - CustomerRelationshipManager
        > > > > - Agent
        > > > >
        > > > > Here is an obvious candidate for a SOA service - it's just going to
        > > > > create, update, query and delete party relationships. PartyRelationship
        > > > > element is at the centre of the component (or if you want to view it
        > > from
        > > > > another angle, at the root of the XML that carries the component) and
        > > it's
        > > > > going to have "to" (party role = "RelationshipToParty" and "from"
        > > (party
        > > > > role = "RelationshipFromParty") which are just references to a Party, a
        > > > > status, a validFromDateTime, optionally a validToDateTime, a
        > > > > partyRelationshipDescription (consisting of unique code, description) ,
        > > > > and
        > > > > most importantly, an unique identifier.
        > > > >
        > > >
        > > > Strictly speaking these are capabilities of Party Management rather than
        > > > being a service domain in their own right and this is classic MDM. I
        > > > think its all clear if you are talking about a service that works
        > > directly
        > > > on part of the Customer domain what information can be shared. The
        > > > question is what does it look like in the transactional stream rather
        > > than
        > > > the MDM stream.
        > > >
        > > >
        > > > >
        > > > > There can only be one enterprise service called "PartyRelationship" in
        > > > > the enterprise i.e. is responsible for PartyRelationship. It has a
        > > schema
        > > > > that conforms to that part of the CDM that is identified as the
        > > > > PartyRelationship component and which is loosely coupled to other
        > > > > components of the CDM for which it is not responsible for but can
        > > > > legitimately reference. The enterprise service tells you nothing about
        > > the
        > > > > implementation and it doesn't need to (that's the beauty about SOA).
        > > > >
        > > > > And so on until you have a unique service and schema for every
        > > identified
        > > > > component in the CDM. And by "component" I do not mean "object". A
        > > > > component is a set of related objects with a significant entity type
        > > object
        > > > > at it's epicenter. A CDM then is a loosely connected set of components.
        > > > > There is nothing in the architecture that needs to realize the CDM in
        > > > > it's entirety. Which is really useful because you can take your time
        > > about
        > > > > building out the CDM over time as needed, component by component
        > > (service
        > > > > by service).
        > > > >
        > > >
        > > > Again you are describing an MDM approach.
        > > >
        > > >
        > > >
        > > > >
        > > > > "OrderForCustomer", "ShipmentForCustomer", "InvoiceForCustomer" are
        > > > > individual enterprise services that each reference a Party in the role
        > > of
        > > > > Customer but each one of these is likely to have other roles objects
        > > that
        > > > > reference other components (services) e.g. "BillingContactParty",
        > > > > "DeliveryAddress", "BillingAddress", ... They will also have a
        > > significant
        > > > > number of Description objects. It is not the job of these individual
        > > entity
        > > > > type services to de-reference the references they contain to other
        > > > > components - that's the job of the consumer of the service.
        > > > >
        > > >
        > > > Now I'm into confusion again. Yes these services 'reference' a Party, my
        > > > question is 'HOW' do they do that. So you've got a SAP Logistics system
        > > > handling shipments (Shipment), Siebel handling sales (Order).
        > > >
        > > > If its the job of the 'consumer' to do the dereferencing/cross
        > > > referencing/lookup/etc HOW does it do this.
        > > >
        > > > Lets say that Sales Management calls Logistics (ShipmentForCustomer). HOW
        > > > does Sales Management have the right information about the customer to
        > > call
        > > > Logistics. How does Logistics identify whether this is a new customer or
        > > a
        > > > previous customer in order to calculate shipment times? Siebel has an ID
        > > > of AAA for the customer, Logistics has BBB, Siebel has 50 customer
        > > > attributes, Logistics has 20, the overlap is 18 attributes. What gets
        > > > passed?
        > > >
        > > > I get the MDM pieces you've talked about (although I'd disagree that you
        > > > have separate services doing relationships over normal party management)
        > > > but I'm still completely in the dark about what your CDM is and what sort
        > > > of information is shared about mastered entities within the main
        > > > transactional threads.
        > > >
        > > > Something as simple as an example would be great, not an example
        > > explaining
        > > > about MDM services (hence the reason I said that MDM and CDM are far from
        > > > orthogonal) but about explaining how those mastered entities are passed
        > > > between transactional systems.
        > > >
        > > > Steve
        > > >
        > > > PS OrderForCustomer is a capability in OASIS SOA RM terms BTW, the
        > > service
        > > > might be something like Sales Management with a capability of Order.
        > > >
        > > >
        > > > >
        > > > >
        > > > > Regards,
        > > > > David.
        > > > >
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > ------------------------------
        > > > > *From:* Steve Jones <jones.steveg@>
        > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > *Sent:* Wednesday, 7 March 2012 3:40 AM
        > > > >
        > > > > *Subject:* Re: [service-orientated-architecture] Re: BOA & SOA
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > On 6 March 2012 08:15, David Tildesley <davotnz@> wrote:
        > > > >
        > > > > **
        > > > >
        > > > > Hi Steve,
        > > > >
        > > > > I don't have a definition for a "Customer CDM" - it doesn't make any
        > > sense
        > > > > to me and I think this is where you and I have been talking past each
        > > > > other.
        > > > >
        > > > >
        > > > > I'm certainly confused. So what does the CDM have in it? What makes it
        > > > > canonical?
        > > > >
        > > > >
        > > > > I've already explained the role of "role" in decoupling the CDM
        > > components
        > > > > to avoid precisely the problem you mentioned in your blog<
        > > http://service-architecture.blogspot.co.nz/2006/08/single-canonical-form-not-for-soa.html>
        > > about
        > > > > "single canonical form".
        > > > >
        > > > >
        > > > > This confuses me as when you talked about it I read that as 'MDM
        > > > > components' and I'm still unclear as to how your CDM pieces aren't
        > > just MDM.
        > > > >
        > > > >
        > > > >
        > > > > I'm the last person that would suggest to "smash" all customer
        > > information
        > > > > into one large "object" (using the term loosely) as I have recently
        > > worked
        > > > > with a vendor product that does exactly that (incidentally the vendor
        > > made
        > > > > it usable by declaring everything in it as "optional").
        > > > >
        > > > >
        > > > > Which of course makes it unusable as different people populate
        > > different
        > > > > bits.
        > > > >
        > > > >
        > > > >
        > > > > In my view, there is no reason to have large "super objects" (or as one
        > > > > architect I know calls it - a "super type"). The issue is that unless
        > > you
        > > > > know how to model a domain and invest in modelling the domain with the
        > > > > business, that's exactly what you gravitate to.
        > > > >
        > > > > I come back to what I said at the very beginning - your description of
        > > a
        > > > > CDM is a description of a CDM fetish and a fetish that shouldn't be
        > > used as
        > > > > an argument against CDM.
        > > > >
        > > > >
        > > > > I'd really love to see an example of what you consider then and exactly
        > > > > what sort of XSDs are passed between different business areas &
        > > services to
        > > > > enable transactions to be complete. It would help me to understand why
        > > > > your 'CDM components' aren't just MDM pieces and how functional
        > > > > transactions invoke these components and what they pass between
        > > themselves.
        > > > >
        > > > > Yes the business needs to model its master data and yes that is a
        > > > > horizontal effort but that still doesn't give you a CDM in your
        > > operational
        > > > > environment... at least not for me if you do it well.
        > > > >
        > > > > Steve
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > Regards,
        > > > > David.
        > > > >
        > > > > ------------------------------
        > > > > *From:* Steve Jones <jones.steveg@>
        > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > *Sent:* Tuesday, 6 March 2012 12:23 PM
        > > > > *Subject:* Re: [service-orientated-architecture] Re: BOA & SOA
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > On 5 March 2012 21:28, David Tildesley <davotnz@> wrote:
        > > > >
        > > > > **
        > > > >
        > > > > << steve says ... 2 points
        > > > >
        > > > > >
        > > > > > 1) There is no technical O2C process just one domain calling another,
        > > > > this
        > > > > > is part of an abstract business process not a technical orchestrated
        > > one
        > > > > > (we can get onto why end-to-end BPM doesn't work next if you want).
        > > > > >
        > > > > > 2) How does the calling domain know all of the information about the
        > > > > > customer...
        > > > >
        > > > > > 1) What is in the CDM - i.e. what level of detail does it have, is it
        > > > > > 'complete' from a customer information perspective (customer,
        > > addresses,
        > > > > > risk profile, etc)
        > > > > > 2) If you are using an MDM solution to do the mapping... what value
        > > does
        > > > > > the CDM deliver for customer.
        > > > >
        > > > > >>
        > > > >
        > > > > I don't get what you are after - business domain's are abstract things
        > > - a
        > > > > scope, a boundary, of a set of business services, functions, processes
        > > and
        > > > > collaborations. I hardly think that a financial system that takes care
        > > of
        > > > > invoicing etc. fits into that category. If the "SendInvoice()" were a
        > > SaaS,
        > > > > then the same applies - treat it like it were any other application
        > > service
        > > > > in the enterprise (notwithstanding sorting out the non functionals).
        > > > >
        > > > >
        > > > >
        > > > > Business domains are far from abstract, there is a Finance department,
        > > a
        > > > > customer service department and sales department, logistics, etc, etc,
        > > etc.
        > > > > These aren't abstract things. I'm after, and I think the the definition
        > > > > of 1) is pretty clear, is your definition of a customer CDM.
        > > > >
        > > > >
        > > > >
        > > > > The business process will need to know as much information (having
        > > > > collected it from various enterprise services and via other means -
        > > e.g.
        > > > > web shopping application - whatever) as is required to invoke the
        > > > > "SendInvoice()" via a enterprise service wrapper (or direct).
        > > > >
        > > > >
        > > > > And I'm saying that 'as much' = MDM = keys which means no requirement
        > > for
        > > > > a CDM. Saying 'will need to know as much information' is nonsense. How
        > > > > will Sales know the risk profile without asking Finance? And if they
        > > are
        > > > > asking Finance to fill out the risk profile what information have they
        > > sent
        > > > > to identify the customer? How does Sales know the last delivery time
        > > > > achieved for that customer as its internal to Logistics?
        > > > >
        > > > > Or is your architecture that all information is extracted into these
        > > > > uber-processes. If that is the case then the question is: When these
        > > uber
        > > > > processes need to change or the services on which they depend
        > > changes...
        > > > > who approves it?
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > It doesn't matter whether it is an O2C process, bpm or otherwise,
        > > > > enterprise services are there to be reused, otherwise what it is the
        > > point
        > > > > of SOA?
        > > > >
        > > > >
        > > > > Now this really is a strawman...
        > > > >
        > > > >
        > > > >
        > > > > I started out this discussion pointing out that knocking CDM for
        > > spurious
        > > > > reasons is not sufficient argument against CDM. "It's too hard" is not
        > > > > sufficient argument because we don't know whether the person making
        > > that
        > > > > statement has any clue as to how to go about efficiently and
        > > effectively
        > > > > arriving at a CDM that will work for their business. I suggested an
        > > > > effective technique to get to a workable CDM. I pointed out that CDM
        > > and
        > > > > MDM are orthogonal (and they are - you have presented no convincing
        > > > > argument to the contrary).
        > > > >
        > > > >
        > > > > Nope, its not that CDM is hard, its that its a crap idea.
        > > > >
        > > > >
        > > > >
        > > > > I've kept my side of the bargain, it's time for you to describe how an
        > > O2C
        > > > > using SO approach using your MDM theory looks like.
        > > > >
        > > > >
        > > > > My way is easy, the MDM solution involves the business areas getting
        > > > > together and agreeing on identification rules and core identification
        > > > > critieria. This is automated via MDM which also synchronises any shared
        > > > > information between domains. When one domain calls another they pass
        > > only
        > > > > the key to identify the customer, the MDM solution then maps the source
        > > > > domain key to the destination domain key and voila the transformation
        > > is
        > > > > done.
        > > > >
        > > > >
        > > > > Very simple and it requires a non-transactional flow to enable this as
        > > the
        > > > > only time that there is exchange on mastered information is when there
        > > is
        > > > > change to the mastered information not just everytime there is a
        > > > > transaction.
        > > > >
        > > > > You've singularly not said how a CDM works, what you've said is 'its
        > > hard,
        > > > > but I can do it' but not shown how you would enable a large and complex
        > > > > enterprise to work with a CDM. You've not once given an example as to
        > > the
        > > > > attributes and entities in your CDM for the O2C (or any other process).
        > > > > Saying 'the process has gathered the information' is nonsense. I'm
        > > > > genuinely interested to hear of how you made CDM work as I've
        > > repeatedly
        > > > > simplified IT estates by removing it.
        > > > >
        > > > > Steve
        > > > >
        > > > >
        > > > >
        > > > > Regards,
        > > > > David.
        > > > >
        > > > >
        > > > > --- In service-orientated-architecture@yahoogroups.com, Steve Jones
        > > > > <jones.steveg@> wrote:
        > > > > >
        > > > > > On 4 March 2012 21:59, David Tildesley davotnz@ wrote:
        > > > > >
        > > > > > > **
        > > > >
        > > > > > >
        > > > > > >
        > > > > > > Hi Steve,
        > > > > > >
        > > > > > > OK, I get what you are after.
        > > > > > >
        > > > > > > I would treat the service "Finance.SendInvoice(Customer, Order)"
        > > like
        > > > > any
        > > > > > > other application service. Behind it could be a COTS package, a
        > > > > customer
        > > > > > > app, an EAI integration, a failed previous SOA implementation, ...
        > > it
        > > > > > > doesn't matter to my business process "order to cash". The fact
        > > that
        > > > > it may
        > > > > > > use a CDM is also irrelevant. What is relevant is that someone has
        > > > > told me
        > > > > > > I have to use it (rebuilding it is not an option) and the
        > > information
        > > > > that
        > > > > > > it expects to be passed.
        > > > > > >
        > > > > > > This is a straight transformation problem to be solved. My business
        > > > > > > process "Order to Cash" will already have the information
        > > available to
        > > > > > > provide to this process with one notable likely exception - the
        > > i.d.
        > > > > of an
        > > > > > > existing customer that this system is expecting.
        > > > > > >
        > > > > >
        > > > > > 2 points
        > > > > >
        > > > > > 1) There is no technical O2C process just one domain calling another,
        > > > > this
        > > > > > is part of an abstract business process not a technical orchestrated
        > > one
        > > > > > (we can get onto why end-to-end BPM doesn't work next if you want).
        > > > > >
        > > > > > 2) How does the calling domain know all of the information about the
        > > > > > customer...
        > > > > >
        > > > > >
        > > > > > > It is likely to pose at least two significant problems:
        > > > > > >
        > > > > > >
        > > > > > > - Semantic mapping
        > > > > > > - cross referencing of "object" identifiers
        > > > >
        > > > > > >
        > > > > > > There are standard ways to solve these two problems which I don't
        > > need
        > > > > to
        > > > > > > describe here. One of them could be MDM (for the cross-referencing
        > > of
        > > > > > > "object" identifiers).
        > > > > > >
        > > > > > > For a capability as significant as this in the enterprise, I would
        > > > > > > definitely consider wrapping it with an enterprise service that
        > > allows
        > > > > > > other processes to call this as a sub-process. Of course the
        > > wrapping
        > > > > would
        > > > > > > be using the CDM I am using.
        > > > > > >
        > > > > > > Hope that answers you question.
        > > > > > >
        > > > > >
        > > > > > Not quite. As above, I'm asking when one domain calls another,
        > > directly
        > > > > not
        > > > > > with some external orchestration. O2C is an abstract process,
        > > probably
        > > > > > best thought of as choreography/BAM than BPM. So the two questions
        > > > > > remain, so I'm clear.
        > > > > >
        > > > > > 1) What is in the CDM - i.e. what level of detail does it have, is it
        > > > > > 'complete' from a customer information perspective (customer,
        > > addresses,
        > > > > > risk profile, etc)
        > > > > > 2) If you are using an MDM solution to do the mapping... what value
        > > does
        > > > > > the CDM deliver for customer.
        > > > > >
        > > > > > Steve
        > > > > >
        > > > > > >
        > > > > > > David.
        > > > > > >
        > > > > > > *From:* Steve Jones jones.steveg@
        > > > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > > > *Sent:* Monday, 5 March 2012 12:30 AM
        > > > > > >
        > > > > > > *Subject:* Re: [service-orientated-architecture] Re: BOA & SOA
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > On 4 March 2012 07:58, David Tildesley davotnz@ wrote:
        > > > > > >
        > > > > > > **
        > > > >
        > > > > > >
        > > > > > > <<Yes.... and at the same time no. What you've just described is
        > > the
        > > > > > > MDM approach (although in a more complex way than is normal), this
        > > > > doesn't
        > > > > > > actually answer the question of CDM within the normal transactional
        > > > > flow.
        > > > > > > So you've got all of these Master Data Services you've described
        > > and
        > > > > now
        > > > > > > comes the question....
        > > > > > >
        > > > > > > Sales wants to send an invoice to someone so needs to call
        > > > > > > Finance.SendInvoice(Customer, Order)
        > > > > > >
        > > > > > > What do they put in the Customer bit?
        > > > > > >
        > > > > > > Steve >>
        > > > > > >
        > > > > > > Finance.SendInvoice(Customer, Order) doesn't make any sense to me
        > > for
        > > > > > > the following reasons:
        > > > > > >
        > > > > > > Would you not would want to ensure that you have shipped (whole or
        > > a
        > > > > part
        > > > > > > of) the order before you invoice the customer? And if you placed
        > > items
        > > > > on
        > > > > > > back-order because you had no stock and the customer agreed to
        > > ship the
        > > > > > > "in-stock" items, best you only invoice for what you have shipped.
        > > The
        > > > > > > moment-interval that follows the "OrderForCustomer" but precedes
        > > the
        > > > > > > creation of "InvoiceForCustomer" is "ShipmentForCustomer".
        > > > > > >
        > > > > > >
        > > > > > > We aren't into design here, the point is that one service domain
        > > calls
        > > > > > > another service domain passing in a mastered entity (Customer) and
        > > a
        > > > > > > transactional entity (Order).
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > Another problem: Wouldn't you create the invoice before you sent
        > > it?
        > > > > e.g.
        > > > > > >
        > > Finance.InvoiceForCustomer.createInvoiceForCustomer(InvoiceForCustomer)
        > > > > > >
        > > > > > > So in summary, the name of the "objects" you are passing in don't
        > > make
        > > > > any
        > > > > > > sense to me in the context of the operation name.
        > > > > > >
        > > > > > > Can you please clarify what you are wanting me to demonstrate? I
        > > think
        > > > > you
        > > > > > > want me to discuss a "process" type service?
        > > > > > >
        > > > > > >
        > > > > > > Nope. I want you to discuss cross domain CDM calls and what
        > > attributes
        > > > > > > you are putting into the customer xsd.
        > > > > > >
        > > > > > > Steve
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > David.
        > > > > > >
        > > > > > > *From:* Steve Jones jones.steveg@
        > > > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > > > *Sent:* Sunday, 4 March 2012 4:25 AM
        > > > > > >
        > > > > > > *Subject:* Re: [service-orientated-architecture] Re: BOA & SOA
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > On 3 March 2012 10:56, David Tildesley davotnz@ wrote:
        > > > > > >
        > > > > > > **
        > > > >
        > > > > > >
        > > > > > > << This is why I asked the question of what is in scope for
        > > Customer in
        > > > > > > your
        > > > > > > CDM. In IFW the answer is 'everything'. What would you put in
        > > there? >>
        > > > > > >
        > > > > > >
        > > > > > > Yep, I know what you are saying about those vendor frameworks.
        > > Their
        > > > > > > Party/CustomerParty/Customer "objects" (I use the term loosely) are
        > > > > > > somewhat large.
        > > > > > >
        > > > > > > In answer to your question:
        > > > > > >
        > > > > > > Customer is a *role *played by a Party in relationship with
        > > something
        > > > > of
        > > > >
        > > > > > > business value at a point in time (e.g. sale, invoice, shipment,
        > > > > account,
        > > > > > > XYZrequestForSomeBusinessService, correspondence, ...) and as such
        > > it
        > > > > will
        > > > > > > appear in many components of the CDM but only as a reference (which
        > > > > > > incidentally would appear a relationship in an UML class diagram if
        > > > > that's
        > > > > > > the notation you happened to use to represent your CDM).
        > > > > > >
        > > > > > > And so the strict answer to your question is: probably nothing - a
        > > > > role is
        > > > > > > (usually) not a component in it's own right.
        > > > > > >
        > > > > > > Let's say the business needs a capability of: Party Relationship
        > > > > > > Management. This PRM capability scope is creating and tracking of
        > > the
        > > > > > > relationships between parties that are relevant to the business
        > > and of
        > > > > > > value to track.
        > > > > > >
        > > > > > > e.g.:
        > > > > > >
        > > > > > >
        > > > > > > - BillingContact
        > > > > > > - CustomerRelationshipManager
        > > > > > > - Agent
        > > > >
        > > > > > >
        > > > > > >
        > > > > > > Here is an obvious candidate for a SOA service - it's just going to
        > > > > > > create, update, query and delete party relationships.
        > > PartyRelationship
        > > > > > > element is at the centre of the component (or if you want to view
        > > it
        > > > > from
        > > > > > > another angle, at the root of the XML that carries the component)
        > > and
        > > > > it's
        > > > > > > going to have "to" (party role = "RelationshipToParty" and "from"
        > > > > (party
        > > > > > > role = "RelationshipFromParty") which are just references to a
        > > Party, a
        > > > > > > status, a validFromDateTime, optionally a validToDateTime, a
        > > > > > > partyRelationshipDescription (consisting of unique code,
        > > description)
        > > > > , and
        > > > > > > most importantly, an unique identifier.
        > > > > > >
        > > > > > > You will notice several things so far from the above:
        > > > > > >
        > > > > > > - It's not overburdened and it's not big and therefore it's easily
        > > > >
        > > > > > > understood by both developers and the business.
        > > > > > > - It's self-contained as it only has references to things outside
        > > > >
        > > > > > > itself which it is not responsible for. i.e. it is not responsible
        > > for
        > > > > > > creating or maintaining Party.
        > > > > > > - The PartyRelationship can be referenced by other components
        > > because
        > > > > > > it has an identifier
        > > > > > > - It only contains roles played by things outside of it with
        > > respect
        > > > >
        > > > > > > to it. It doesn't contain roles played by it with respect to things
        > > > > > > outside of the component.
        > > > > > > - Because of the above, it can be easily composed.
        > > > > > > - You most likely understood it in the absence of a diagram (I am
        > > > > > > hoping).
        > > > > > > - It has business value but it's limited - e.g. You will be able to
        > > > >
        > > > > > > get a list of relationships from this service of any given type
        > > but you
        > > > > > > will know nothing about the Party(s) playing the roles - another
        > > > > service
        > > > > > > will be required to de-reference the Party references (that's
        > > next).
        > > > > > >
        > > > > > > Next: The business needs a Party Management Capability. The Party
        > > > > > > Management scope is Party: both forms of legally recognized Party:
        > > > > Person
        > > > > > > and Organisation.
        > > > > > >
        > > > > > > Here is an obvious candidate for a SOA service - it's just going to
        > > > > > > create, update, query and delete party's. Party element is going
        > > to be
        > > > > at
        > > > > > > the centre of the component and will have: an unique identifier, a
        > > > > status,
        > > > > > > a "choice" of person or organisation elements. The person element
        > > will
        > > > > > > contain: dateOfBirth, firstNames, surname, preferredName, ... and
        > > other
        > > > > > > obvious "attributes" of person. The organisation will "attributes"
        > > > > such as
        > > > > > > legal name, trading name, organisation units, tax number,
        > > > > > > organisationTypeDescription (containing code, description).
        > > > > > >
        > > > > > > The PartyManagement service then has similar qualities to the first
        > > > > > > service above and now an orchestrated business process can find a
        > > party
        > > > > > > using this service (Party.QueryPartyList) using what is known
        > > about the
        > > > > > > Party, get the best match with an acceptable match-score threshold
        > > (for
        > > > > > > that business process), and then ask the PartyRelationship service
        > > for
        > > > > the
        > > > > > > list of Relationships the Party has "to" or "from" using the Party
        > > > > unique
        > > > > > > identifier as the Party reference in the
        > > > > > > PartyRelationship.QueryPartyRelationshipList. Then for each
        > > > > > > PartyRelationship, de-reference the "from" or "to" Party by using
        > > the
        > > > > > > reference in "Party.QueryParty"
        > > > > > >
        > > > > > > How did the two services above differ? The PartyRelationship
        > > service
        > > > > had a
        > > > > > > pink at it's heart (and therefore a bunch of yellows associated
        > > with
        > > > > it),
        > > > > > > whilst the Party service had a green at it's heart. They both had
        > > > > blues.
        > > > > > > With yellows in the mix, you have a bunch of references to
        > > de-reference
        > > > > > > outside of the service. Apart from that they are both "entity" type
        > > > > > > services, asking to be composed as part of a "process" type
        > > service.
        > > > > (at
        > > > > > > the higher level of abstraction, think of business processes
        > > leveraging
        > > > > > > functional capabilities).
        > > > > > >
        > > > > > > Hope that answers your question.
        > > > > > >
        > > > > > >
        > > > > > > Yes.... and at the same time no. What you've just described is the
        > > MDM
        > > > > > > approach (although in a more complex way than is normal), this
        > > doesn't
        > > > > > > actually answer the question of CDM within the normal transactional
        > > > > flow.
        > > > > > > So you've got all of these Master Data Services you've described
        > > and
        > > > > now
        > > > > > > comes the question....
        > > > > > >
        > > > > > > Sales wants to send an invoice to someone so needs to call
        > > > > > > Finance.SendInvoice(Customer, Order)
        > > > > > >
        > > > > > > What do they put in the Customer bit?
        > > > > > >
        > > > > > > Steve
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > David.
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > --- In service-orientated-architecture@yahoogroups.com, Steve
        > > Jones
        > > > > > > jones.steveg@ wrote:
        > > > >
        > > > > > > >
        > > > > > > > On 28 February 2012 09:09, David Tildesley davotnz@ wrote:
        > > > > > > >
        > > > > > > > > **
        > > > > > >
        > > > > > > > >
        > > > > > > > >
        > > > > > > > > Steve,
        > > > > > > > >
        > > > > > > > > In answer to your question: <<Multiple canonical models... how
        > > > > would
        > > > > > > they
        > > > > > > > > be canonical then?>> . I rather like the wikipedia definition.
        > > "A
        > > > > > > > > Canonical Model is any model that iscanonical<
        > > > > > > http://en.wikipedia.org/wiki/Canonical> in
        > > > > > >
        > > > > > > > > nature, i.e. a model which is in the simplest form possible
        > > based
        > > > > on a
        > > > > > > > > standard, common view within a given context."
        > > > > > > > >
        > > > > > > > > "within a given context" answers your question. Take the
        > > example
        > > > > of a
        > > > > > > > > Retail Bank. In recent years they have expanded their business
        > > > > from the
        > > > > > > > > core retail banking (savings account, loan, cash transactions)
        > > into
        > > > > > > areas
        > > > > > > > > such as General and Life Insurance, Wealth management (unit
        > > trust
        > > > > > > > > investments etc) and so have multiple distinct business domains
        > > > > > > (contexts).
        > > > > > > > > It's perfectly reasonable if they decide to have a CDM for
        > > each and
        > > > > > > it's
        > > > > > > > > also reasonable if they choose a single CDM, accepting the
        > > > > tradeoffs
        > > > > > > that
        > > > > > > > > need to be made (elements and attributes that may be
        > > irrelevant to
        > > > > a
        > > > > > > > > particular business context but a core set of common elements
        > > and
        > > > > > > > > attributes making it worthwhile to persevere with the one
        > > model,
        > > > > > > relying on
        > > > > > > > > supplementary documentation and/or schema rules such as
        > > available
        > > > > via
        > > > > > > > > schematron to make it clear what is mandatory in a particular
        > > > > business
        > > > > > > > > context to the developers).
        > > > > > > > >
        > > > > > > >
        > > > > > > > Good example, IBM have just such a thing its called IFW (
        > > > > > > >
        > > > > > >
        > > > >
        > > http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=%2Fcom.ibm.ws.icp.bkkpayfep1.doc%2Fbkk%2Fpay%2Fpaymdev%2Fconcept%2Fci%2Findstds%2Fc_ifw.html
        > > > > > > )
        > > > > > > > it aims to be exactly that. Oracle have an attempt called AIA (
        > > > > > > >
        > > > > > >
        > > > >
        > > http://www.oracle.com/us/products/applications/application-integration-architecture/index.html
        > > > > > > )
        > > > > > > > these include the functional and data elements but certainly not
        > > to
        > > > > the
        > > > > > > > level of real validation (there is no WS-Contract
        > > > > > > >
        > > > >
        > > http://www.mwdadvisors.com/blog/2005/12/why-is-there-no-ws-contract.html
        > > > > > > )
        > > > > > > > that is required. These massive beasts require an army of
        > > > > consultants to
        > > > > > > > implement and 'tailor' for a given customer. Think of it as a
        > > > > 'meta-ERP'
        > > > > > > > approach. These approaches still suffer from the issues of
        > > fragile
        > > > > base
        > > > > > > > class and extensive retesting required when a single attribute
        > > > > changes.
        > > > > > > > This is why I'm not a fan. Both IFW and AIA also suffer from the
        > > > > problem
        > > > > > > > of entity identification across domains.
        > > > > > > >
        > > > > > > > If you've got enough money then yes you can do it. But shouldn't
        > > we
        > > > > > > really
        > > > > > > > think about what is sensible?
        > > > > > > >
        > > > > > > > This is why I asked the question of what is in scope for
        > > Customer in
        > > > > your
        > > > > > > > CDM. In IFW the answer is 'everything'. What would you put in
        > > there?
        > > > > > > >
        > > > > > > >
        > > > > > > > Steve
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > >
        > > > > > > > >
        > > > > > > > > David.
        > > > > > > > >
        > > > > > > > > --- In service-orientated-architecture@yahoogroups.com, Steve
        > > > > Jones
        > > > > > > > > jones.steveg@ wrote:
        > > > > > >
        > > > > > > > > >
        > > > > > > > > > On 27 February 2012 00:29, David Tildesley davotnz@ wrote:
        > > > > > > > > >
        > > > > > > > > > > **
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > The answer is that it is not up to me or you to decide
        > > what is
        > > > > the
        > > > > > > > > > > boundary of any given business domain. As I said - there
        > > could
        > > > > be
        > > > > > > more
        > > > > > > > > than
        > > > > > > > > > > one within a large and complex organisation and therefore
        > > > > several
        > > > > > > CDMs.
        > > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > Multiple canonical models... how would they be canonical
        > > then?
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > > Just simply attempting to model the boundaries/scope would
        > > be a
        > > > > > > step
        > > > > > > > > > > forward in terms of offering some clarity for most
        > > > > organisations.
        > > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > You mean a sort of approach to defining a business services
        > > > > > > architecture
        > > > > > > > > > which clearly identified their domains and their structure...
        > > > > > > > > >
        > > > > > > > > > Yes I agree its a very important thing to do that, critical
        > > in
        > > > > fact.
        > > > > > > Wish
        > > > > > > > > > I'd been talking about that for 10+ years....
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > > If in the case of a homogenous business domain, one part
        > > of the
        > > > > > > > > business
        > > > > > > > > > > calls a customer a client while the other calls a client a
        > > > > customer
        > > > > > > > > > > then it's about time they sorted that out amongst
        > > themselves.
        > > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > Yes, and this would be called MDM and its one of the reasons
        > > that
        > > > > > > CDMs
        > > > > > > > > > don't work within transactions and that doing an MDM approach
        > > > > does
        > > > > > > work.
        > > > > > > > > > Its fine to say 'sorted out' but the challenge is two fold
        > > > > > > > > >
        > > > > > > > > > 1) How do you identify the customer at a given touch-point
        > > > > > > > > > 2) how do I communicate to others about the customer I've
        > > > > identified
        > > > > > > > > >
        > > > > > > > > > The former is WITHIN the bounds of a given domain, the later
        > > is
        > > > > > > across
        > > > > > > > > > domains. Having a single misguided attempt at providing a
        > > full on
        > > > > > > schema
        > > > > > > > > > that defines 'customer' for everyone is going to cause many
        > > more
        > > > > > > issues
        > > > > > > > > > than it fails. This is why a much better approach is to
        > > focus on
        > > > > the
        > > > > > > > > > governance and definition parts (what MDM is good at) then
        > > > > provide a
        > > > > > > key
        > > > > > > > > > based exchange (MDM providing the x-ref) which removes the
        > > > > fragile
        > > > > > > base
        > > > > > > > > > class problem. The MDM part can also then keep the core
        > > > > information
        > > > > > > in
        > > > > > > > > > sync across systems (and out of the primary transaction
        > > flow).
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > > One of the big benefits of DDD (and is very true of
        > > consensus
        > > > > based
        > > > > > > > > domain
        > > > > > > > > > > modelling) is the "Ubiquitous language" outcome is it not?
        > > (at
        > > > > > > least
        > > > > > > > > that
        > > > > > > > > > > was what Eric Evans was reinforcing - which I happen to
        > > agree
        > > > > with
        > > > > > > > > whole
        > > > > > > > > > > heartedly).
        > > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > Unfortunately however it suffers from a challenge: it doesn't
        > > > > work
        > > > > > > if you
        > > > > > > > > > try and make this 'language' detailed. What you appear to be
        > > > > making
        > > > > > > the
        > > > > > > > > > mistake is that if you took a single application approach and
        > > > > > > 'scaled it
        > > > > > > > > > up' to the enterprise that it would still work. Sadly this
        > > isn't
        > > > > the
        > > > > > > case
        > > > > > > > > > because the primary issue is not one of technology its one of
        > > > > people
        > > > > > > and
        > > > > > > > > > the worst thing that technology can try and do is codify the
        > > data
        > > > > > > > > > structures across the boundaries for common information sets
        > > and
        > > > > > > believe
        > > > > > > > > > that this is in some way helping.
        > > > > > > > > >
        > > > > > > > > > I regularly get business folks to agree on the common
        > > > > definitions,
        > > > > > > > > > including getting them to agree on what is core, share, sync,
        > > > > > > federated
        > > > > > > > > > information within that set. The role of SOA is to provide
        > > the
        > > > > > > > > boundaries,
        > > > > > > > > > the role of MDM is to provide a horizontally consistent
        > > > > communication
        > > > > > > > > > foundation.
        > > > > > > > > >
        > > > > > > > > > The role of CDM is to move forwards with optimism towards
        > > > > failure.
        > > > > > > > > >
        > > > > > > > > > Steve
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > Sorry haven't got time right now to comment on the rest -
        > > > > weekend
        > > > > > > is
        > > > > > > > > over,
        > > > > > > > > > > grafting has begun.
        > > > > > > > > > >
        > > > > > > > > > > David.
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > *From:* Michael Poulin m3poulin@
        > > > > > > > > > > *To:* "service-orientated-architecture@yahoogroups.com" <
        > > > > > > > > > > service-orientated-architecture@yahoogroups.com
        > > > > > > > > > > *Sent:* Monday, 27 February 2012 2:24 AM
        > > > > > > > > > >
        > > > > > > > > > > *Subject:* Re: [service-orientated-architecture] BOA & SOA
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > I'd like to join Steve and ask: how do you define 'domain'
        > > or
        > > > > > > 'business
        > > > > > > > > > > domain'?
        > > > > > > > > > >
        > > > > > > > > > > For example, you have a business domain of "Client" with a
        > > > > > > sub-domain
        > > > > > > > > of
        > > > > > > > > > > "Customer" because one Client can appear as several
        > > Customer to
        > > > > > > your
        > > > > > > > > > > company. At the same time, in the business part of your
        > > > > company,
        > > > > > > one
        > > > > > > > > > > Division calls particular external business a Clients while
        > > > > another
        > > > > > > > > > > Division calls the _same_ external business a Customer; and
        > > > > they
        > > > > > > > > disagree
        > > > > > > > > > > with any attempts to call them differently. Thus, you have
        > > a
        > > > > single
        > > > > > > > > > > "domain" with no sub-domains...
        > > > > > > > > > >
        > > > > > > > > > > In my experience with Steve's example of canonical model of
        > > > > > > Customer, I
        > > > > > > > > > > have not found one business unit that used all
        > > fields/elements
        > > > > of
        > > > > > > > > described
        > > > > > > > > > > canonical definition. Consequently, they denied using the
        > > whole
        > > > > > > > > data-set in
        > > > > > > > > > > their operations and in the systems that 'owned'; everyone
        > > > > wanted
        > > > > > > its
        > > > > > > > > own
        > > > > > > > > > > sub-view on the canonical model of Customer. As a result,
        > > the
        > > > > > > canonical
        > > > > > > > > > > model of Customer was used and existed in IT only (what a
        > > great
        > > > > > > > > agility!)
        > > > > > > > > > >
        > > > > > > > > > > - Michael
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > *From:* Steve Jones jones.steveg@
        > > > > > > > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > > > > > > > *Sent:* Sunday, February 26, 2012 9:49 AM
        > > > > > > > > > > *Subject:* Re: [service-orientated-architecture] BOA & SOA
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > On 26 February 2012 06:07, David Tildesley davotnz@ wrote:
        > > > > > > > > > >
        > > > > > > > > > > **
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > Hi Steve (and Michael - hope you don't mind if I answer
        > > your
        > > > > > > concerns
        > > > > > > > > > > here as well).
        > > > > > > > > > >
        > > > > > > > > > > It's good that we are getting a little closer to the core
        > > of
        > > > > the
        > > > > > > > > subject
        > > > > > > > > > > matter and I feel the need to explain some terminology
        > > that I
        > > > > used.
        > > > > > > > > > >
        > > > > > > > > > > "Domain Model" - as per Martin Fowler's description.
        > > "Domain
        > > > > > > > > Modelling" -
        > > > > > > > > > > first phase of FDD "Develop an overall model". Domain is
        > > > > business
        > > > > > > > > problem
        > > > > > > > > > > focused. Domain modelling must be consensus based effort
        > > > > involving
        > > > > > > both
        > > > > > > > > > > business and IT. Domain modelling is best done in chunks,
        > > > > carving
        > > > > > > off
        > > > > > > > > sub
        > > > > > > > > > > domains of the overall business domain and letting each
        > > chunk
        > > > > be
        > > > > > > > > informed
        > > > > > > > > > > by the chunks that have gone before.
        > > > > > > > > > >
        > > > > > > > > > > << Steve says "The concept of product in sales is not the
        > > same
        > > > > as
        > > > > > > the
        > > > > > > > > > > concept in supply chain, not only will they have different
        > > > > > > attributes
        > > > > > > > > but
        > > > > > > > > > > they may represent completely different things. Customer
        > > > > doesn't
        > > > > > > > > 'live' in
        > > > > > > > > > > a single domain, the logistics area needs to know where to
        > > ship
        > > > > > > to..."
        > > > > > > > > >>
        > > > > > > > > > >
        > > > > > > > > > > True that depending on the business domain, "Product" may
        > > be
        > > > > quite
        > > > > > > > > > > different from one business domain to another. But that's
        > > not
        > > > > the
        > > > > > > > > point,
        > > > > > > > > > > the point is that a CDM is for a particular business
        > > domain -
        > > > > > > another
        > > > > > > > > > > business domain can/should have a different CDM that is
        > > > > specific to
        > > > > > > > > it. On
        > > > > > > > > > > the other hand a well decoupled model will have one
        > > "component"
        > > > > > > that is
        > > > > > > > > > > say centered on e.g. a "sale" (a moment-interval archetype)
        > > > > that
        > > > > > > will
        > > > > > > > > > > include a reference to the Customer (Party archetype)
        > > > > component.
        > > > > > > Each
        > > > > > > > > > > recognizable component of the CDM is a strong candidate
        > > for a
        > > > > SOA
        > > > > > > > > entity
        > > > > > > > > > > service. The natural decoupling point of a component is
        > > > > usually the
        > > > > > > > > role
        > > > > > > > > > > archetype (a Party, Place or Thing playing a role with
        > > respect
        > > > > to a
        > > > > > > > > > > Moment-Interval). The overall CDM is therefore a set of
        > > loosely
        > > > > > > coupled
        > > > > > > > > > > components that fall out of the domain modelling exercise
        > > that
        > > > > > > > > specifies
        > > > > > > > > > > the business layer of the functional (business logic, rules
        > > > > etc)
        > > > > > > > > components
        > > > > > > > > > > of the business. Because domain modelling is/should be a
        > > > > consensus
        > > > > > > > > based
        > > > > > > > > > > joint exercise with IT and the business, the names of the
        > > > > > > > > objects/entities
        > > > > > > > > > > are also consensus based with full business involvement.
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > Lets get specific here on what you mean as 'canonical'
        > > > > > > > > > >
        > > > > > > > > > > Lets take Customer
        > > > > > > > > > >
        > > > > > > > > > > A fully canonical model for customer would include
        > > > > > > > > > > Name (prefixes, given, middle, surname, suffixes),
        > > Alternate
        > > > > Names
        > > > > > > > > > > DOB, Gender
        > > > > > > > > > >
        > > > > > > > > > > Identity documents (Passport, driving license)
        > > > > > > > > > > Physical identity (depends on company/use) (iris,
        > > fingerprint)
        > > > > > > > > > > Addresses:
        > > > > > > > > > > Postal Addresses
        > > > > > > > > > > Email Addresses
        > > > > > > > > > > Phone numbers
        > > > > > > > > > > Social media addresses
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > This is just the 'core' information, so would your
        > > canonical
        > > > > model
        > > > > > > > > that is
        > > > > > > > > > > passed between services to represent the customer include
        > > this?
        > > > > > > > > > >
        > > > > > > > > > > Then we move onto the business associations, so lets take a
        > > > > bank a
        > > > > > > > > > > customer also has
        > > > > > > > > > >
        > > > > > > > > > > Risk Assessment,
        > > > > > > > > > > AML status
        > > > > > > > > > > Accounts, Loans, etc
        > > > > > > > > > >
        > > > > > > > > > > Those accounts and loans have their own addresses and
        > > > > potentially
        > > > > > > their
        > > > > > > > > > > own identity processes. In addition those accounts have
        > > > > balances,
        > > > > > > > > terms,
        > > > > > > > > > > contracts etc. These have multiple other associations.
        > > > > > > > > > >
        > > > > > > > > > > So where in your CDM world would you draw the line at the
        > > > > Canonical
        > > > > > > > > > > definition of customer? The 'Core', the associations such
        > > as
        > > > > Risk
        > > > > > > etc
        > > > > > > > > > > which are customer specific, the relationship to accounts
        > > etc,
        > > > > the
        > > > > > > > > > > relationship of those accounts to assets... or at some
        > > other
        > > > > point.
        > > > > > > > > > >
        > > > > > > > > > > How much of this has to be populated for a service to
        > > service
        > > > > > > > > invocation
        > > > > > > > > > > to be considered valid.
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > This would really help me understand how practical your CDM
        > > > > > > approach
        > > > > > > > > is...
        > > > > > > > > > >
        > > > > > > > > > > Steve
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > The "canonical" in CDM is a synonym for "standard", however
        > > > > the key
        > > > > > > > > thing
        > > > > > > > > > > here (and perhaps the main cause of confusion in this
        > > thread)
        > > > > is
        > > > > > > that
        > > > > > > > > CDM
        > > > > > > > > > > is a model that is standard for the business it serves and
        > > not
        > > > > for
        > > > > > > > > someone
        > > > > > > > > > > else's business, or for that matter, another part of a
        > > large
        > > > > and
        > > > > > > > > complex
        > > > > > > > > > > enterprise that is composed of entirely different
        > > businesses.
        > > > > > > > > > >
        > > > > > > > > > > Each SOA service then has a contract that contains an XML
        > > > > schema
        > > > > > > that
        > > > > > > > > is
        > > > > > > > > > > simply a view on a domain component (not be confused with
        > > XML
        > > > > > > > > terminology
        > > > > > > > > > > for a component).
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > I would agree that if you don't have consensus domain
        > > > > modelling as
        > > > > > > a
        > > > > > > > > > > discipline in your organisation, then your chances of
        > > creating
        > > > > a
        > > > > > > CDM
        > > > > > > > > are
        > > > > > > > > > > near zero. Is this not the main reason why CDM efforts (and
        > > > > > > > > consequently
        > > > > > > > > > > SOA also) have failed? - they didn't stand a chance of
        > > > > succeeding
        > > > > > > in
        > > > > > > > > the
        > > > > > > > > > > first place in many organisations due to the parlous state
        > > of
        > > > > the
        > > > > > > > > business
        > > > > > > > > > > applications and the lack of consensus based domain
        > > modelling
        > > > > > > > > > >
        > > > > > > > > > > Regards,
        > > > > > > > > > > David.
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > *From:* Steve Jones jones.steveg@
        > > > > > > > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > > > > > > > *Sent:* Sunday, 26 February 2012 5:38 AM
        > > > > > > > > > >
        > > > > > > > > > > *Subject:* Re: [service-orientated-architecture] BOA & SOA
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > On 24 February 2012 10:57, David Tildesley davotnz@ wrote:
        > > > > > > > > > >
        > > > > > > > > > > **
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > Steve, your idea of a canonical model is in fact yet
        > > another
        > > > > > > strawman.
        > > > > > > > > > > Here is your statement from the post you quote (oh ...
        > > wait it
        > > > > > > happens
        > > > > > > > > to
        > > > > > > > > > > be one of your own posts ... what a co-incidence):
        > > > > > > > > > >
        > > > > > > > > > > <<*Therefore, design a Canonical Data Model that is
        > > independent
        > > > > > > from
        > > > > > > > > any
        > > > > > > > >
        > > > > > > > > > > specific application. Require each application to produce
        > > and
        > > > > > > consume
        > > > > > > > > > > messages in this common format.>>*
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > Wrong on both counts. I suspect the problem may be that
        > > when
        > > > > you
        > > > > > > think
        > > > > > > > > of
        > > > > > > > > > > a "canonical data model", you think of the likes of CIQ,
        > > FpML
        > > > > etc.
        > > > > > > and
        > > > > > > > > you
        > > > > > > > > > > are quoting folk who think it's a good idea to use such
        > > > > external
        > > > > > > models
        > > > > > > > > > > within their enterprise in the vague hope it may match what
        > > > > their
        > > > > > > > > > > enterprise needs in the way of a CDM. Such folk are just
        > > lazy
        > > > > and
        > > > > > > > > belong in
        > > > > > > > > > > the same camp as those that think they can build a business
        > > > > > > application
        > > > > > > > > > > without doing any domain modelling. In fact they are the
        > > same
        > > > > folk
        > > > > > > > > that go
        > > > > > > > > > > and buy dozens of COTS packages with overlapping
        > > functionality
        > > > > and
        > > > > > > with
        > > > > > > > > > > only a small fraction of useful functionality at inflated
        > > > > prices,
        > > > > > > > > requiring
        > > > > > > > > > > expensive "experts"to install and customise them to the
        > > point
        > > > > where
        > > > > > > > > they
        > > > > > > > > > > are hard to upgrade. Then after creating COTS hell where
        > > > > "customer"
        > > > > > > > > exists
        > > > > > > > > > > in multiple COTS application , go and propose management
        > > fork
        > > > > out
        > > > > > > for
        > > > > > > > > a MDM
        > > > > > > > > > > as a "solution" to the mess. Then the vendors change their
        > > > > product
        > > > > > > > > roadmap,
        > > > > > > > > > > or get swallowed up by bigger vendors and you get left with
        > > > > white
        > > > > > > > > > > elephants. But wait, I digress.
        > > > > > > > > > >
        > > > > > > > > > > Here's the thing - if we take the COTS mess out of the
        > > picture
        > > > > for
        > > > > > > a
        > > > > > > > > > > minute and assume that each business application covers a
        > > > > > > particular
        > > > > > > > > > > domain (e.g one of: Customer, Party, Identity,
        > > Correspondence,
        > > > > > > Account,
        > > > > > > > > > > Journal, Asset, ...). Then we assume that the people who
        > > built
        > > > > each
        > > > > > > > > > > application had the common sense and foresight to model the
        > > > > > > domain, lo
        > > > > > > > > and
        > > > > > > > > > > behold, they quickly discover they already have their CDM
        > > - a
        > > > > > > loosely
        > > > > > > > > > > connected bunch of component models taken from their own
        > > > > > > application
        > > > > > > > > domain
        > > > > > > > > > > models, corresponding more or less to the significant
        > > business
        > > > > > > > > entities at
        > > > > > > > > > > the centre of the components, converted into xml schemas.
        > > i.e
        > > > > a CDM
        > > > > > > > > that
        > > > > > > > > > > reflects their business exactly. Now they can get on and
        > > > > compose
        > > > > > > BPM
        > > > > > > > > > > automation to quickly deliver high business value services
        > > > > while
        > > > > > > their
        > > > > > > > > > > competition are fighting fires in the COTS hell.
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > Ok, now lets put some of the COTS mess back in the picture
        > > > > (it's
        > > > > > > pretty
        > > > > > > > > > > hard to avoid - and they are not all bad, and you will
        > > have a
        > > > > > > mixture
        > > > > > > > > of
        > > > > > > > > > > COTS and custom in your enterprise). Let's say you are
        > > lucky
        > > > > and
        > > > > > > the
        > > > > > > > > COTS
        > > > > > > > > > > package exposed its functionality as services /API. But of
        > > > > course,
        > > > > > > the
        > > > > > > > > COTS
        > > > > > > > > > > package service model doesn't match your enterprise CDM.
        > > Do you
        > > > > > > > > complain to
        > > > > > > > > > > the vendor that they should match your CDM? No, they will
        > > > > laugh at
        > > > > > > you
        > > > > > > > > -
        > > > > > > > > > > just like the SAAS providers will laugh if you pull the
        > > same
        > > > > stunt
        > > > > > > on
        > > > > > > > > them.
        > > > > > > > > > > Instead, you will simply do the obvious - adapt and
        > > transform.
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > David,
        > > > > > > > > > >
        > > > > > > > > > > I'm genuinely confused by what you are proposing. The
        > > domain
        > > > > models
        > > > > > > > > from
        > > > > > > > > > > one business model are highly unlikely to be decent and
        > > > > shareable.
        > > > > > > The
        > > > > > > > > > > concept of product in sales is not the same as the concept
        > > in
        > > > > > > supply
        > > > > > > > > chain,
        > > > > > > > > > > not only will they have different attributes but they may
        > > > > represent
        > > > > > > > > > > completely different things. Customer doesn't 'live' in a
        > > > > single
        > > > > > > > > domain,
        > > > > > > > > > > the logistics area needs to know where to ship to...
        > > > > > > > > > >
        > > > > > > > > > > You appear to deride MDM but what you appear to be
        > > proposing
        > > > > is in
        > > > > > > > > fact a
        > > > > > > > > > > single operational real-time MDM solution where a single
        > > domain
        > > > > > > > > controls a
        > > > > > > > > > > given entity and others query that. Good MDM solutions
        > > these
        > > > > days
        > > > > > > > > actually
        > > > > > > > > > > don't try and have all of the information about a given
        > > entity
        > > > > but
        > > > > > > > > instead
        > > > > > > > > > > provide the core information and the cross reference to
        > > where
        > > > > other
        > > > > > > > > > > information can be found.
        > > > > > > > > > >
        > > > > > > > > > > CDM is a bad idea, using MDM to provide the keys,
        > > > > transformation
        > > > > > > and
        > > > > > > > > x-ref
        > > > > > > > > > > is a good idea. So yes adapt and transform.... and that is
        > > what
        > > > > > > MDM +
        > > > > > > > > SOA
        > > > > > > > > > > enables, you should adapt and transform based on the keys
        > > for
        > > > > the
        > > > > > > core
        > > > > > > > > > > entities not try and do it based on the attributes.
        > > > > > > > > > >
        > > > > > > > > > > Steve
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > David.
        > > > > > > > > > > *From:* Steve Jones jones.steveg@
        > > > > > > > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > > > > > > > *Sent:* Thursday, 23 February 2012 11:48 PM
        > > > > > > > > > >
        > > > > > > > > > > *Subject:* Re: [service-orientated-architecture] BOA & SOA
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > I don't quite agree on every single level. CDM is a bad
        > > idea
        > > > > > > full-stop
        > > > > > > > > > >
        > > > > > > > >
        > > > > > >
        > > > >
        > > http://service-architecture.blogspot.com/2006/08/single-canonical-form-not-for-soa.htmlwhetherinternalorexternalits a bad idea and externally its just dead in
        > > > >
        > > > > > > > > > > the water.
        > > > > > > > > > >
        > > > > > > > > > > Steve
        > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > On 22 February 2012 08:56, David Tildesley davotnz@ wrote:
        > > > > > > > > > >
        > > > > > > > > > > **
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > <<"...If you consider the impossibility of imposing the
        > > > > canonical
        > > > > > > data
        > > > > > > > > > > model on your next SaaS provider, the virtue of this
        > > approach
        > > > > > > becomes
        > > > > > > > > > > apparent.">>
        > > > > > > > > > >
        > > > > > > > > > > What? CDM is for internal SOA consumption, it makes no
        > > sense to
        > > > > > > force
        > > > > > > > > it
        > > > > > > > > > > on external parties. This is nothing but a straw man
        > > argument.
        > > > > > > > > > >
        > > > > > > > > > > David T.
        > > > > > > > > > >
        > > > > > > > > > > *From:* Gervas Douglas gervas.douglas@
        > > > > > > > > > > *To:* service-orientated-architecture@yahoogroups.com
        > > > > > > > > > > *Sent:* Tuesday, 21 February 2012 11:53 AM
        > > > > > > > > > >
        > > > > > > > > > > *Subject:* [service-orientated-architecture] BOA & SOA
        > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > >
        > > > > > > > > > > <<The adage of "No Pain, No Gain" isn't just for sports.
        > > While
        > > > > all
        > > > > > > > > > > organizations fantasize about a fully-integrated IT
        > > paradise
        > > > > that
        > > > > > > works
        > > > > > > > > > > seamlessly across departments, groups and geographies, few
        > > > > actually
        > > > > > > > > sign up
        > > > > > > > > > > to experience the pain involved in the process of
        > > integration.
        > > > > > > > > > > The only reason anybody spends money on integration at all
        > > is
        > > > > > > because
        > > > > > > > > > > software, as a rule, doesn't integrate by itself. But no
        > > > > executive
        > > > > > > > > thinks
        > > > > > > > > > > that spending money on integration addresses a strategic
        > > need
        > > > > of
        > > > > > > the
        > > > > > > > > > > business. Instead, money spent on integration typically
        > > goes
        > > > > into
        > > > > > > > > fixing
        > > > > > > > > > > something that really shouldn't have been broken in the
        > > first
        > > > > > > place.
        > > > > > > > > > > Based on the traditional approach, a software application
        > > is
        > > > > > > defined
        > > > > > > > > with
        > > > > > > > > > > system-based requirements, its design, and then coding and
        > > > > testing
        > > > > > > > > within a
        > > > > > > > > > > well-defined software development lifecycle. The primary
        > > focus
        > > > > is
        > > > > > > on
        > > > > > > > > the
        > > > > > > > > > > code's implementation. As a result, integration with teams
        > > has
        > > > > > > > > > > traditionally been tightly coupled with little
        > > consideration
        > > > > for
        > > > > > > > > metadata.
        > > > > > > > > > > Today, integration solutions and paradigms have shifted the
        > > > > focus
        > > > > > > to
        > > > > > > > > code
        > > > > > > > > > > re-use and consolidated application solutions. This
        > > approach
        > > > > > > redefines
        > > > > > > > > the
        > > > > > > > > > > solution based on business-defined services - which is how
        > > it
        > > > > > > should
        > > > > > > > > have
        > > > > > > > > > > been done from the start.
        > > > > > > > > > > With the introduction of service-oriented architecture, the
        > > > > > > paradigm of
        > > > > > > > > > > business users creating application functionality was very
        > > > > exciting
        > > > > > > > > and led
        > > > > > > > > > > to a lot of buzz. This was done through building and
        > > managing
        > > > > > > business
        > > > > > > > > > > processes, all hosted on an enterprise service bus - thus
        > > > > > > > > disentangling the
        > > > > > > > > > > integration "spaghetti" forever. SOA abstracts the
        > > underlying
        > > > > > > > > technology,
        > > > > > > > > > > so that developers enmeshed in connecting systems and
        > > > > applications
        > > > > > > can
        > > > > > > > > now
        > > > > > > > > > > focus on building services. With a selling proposition like
        > > > > that,
        > > > > > > it
        > > > > > > > > was no
        > > > > > > > > > > surprise that everyone wanted a piece of the action.
        > > > > > > > > > > What Isn't Working with SOA
        > > > > > > > > > > However, for all the excitement SOA generated, the
        > > enthusiasm
        > > > > has
        > > > > > > > > dimmed a
        > > > > > > > > > > bit somewhere down the line. So, what happened?
        > > > > > > > > > > SOA is usually mistaken for a set of Web services defining
        > > a
        > > > > > > complete
        > > > > > > > > > > solution. Rather, SOA is a technology paradigm that
        > > supports
        > > > > the
        > > > > > > > > processes
        > > > > > > > > > > defined and governed by business. There has been a
        > > considerable
        > > > > > > > > investment
        > > > > > > > > > > in building SOA infrastructure already, but the payback has
        > > > > been
        > > > > > > slow,
        > > > > > > > > > > leading companies to invest in development of Web services
        > > > > rather
        > > > > > > than
        > > > > > > > > > > define a pure service bus.
        > > > > > > > > > > There is a perception of 'SOA' as a means to enable
        > > integration
        > > > > > > with
        > > > > > > > > > > legacy systems. Legacy encapsulation can certainly be a
        > > great
        > > > > > > enabler
        > > > > > > > > for
        > > > > > > > > > > business processes, but it doesn't substitute for an
        > > effective
        > > > > SOA
        > > > > > > > > strategy.
        > > > > > > > > > > A successful SOA initiative should focus on reducing
        > > > > complexity,
        > > > > > > > > > > transforming systems into services that implement core
        > > > > > > capabilities and
        > > > > > > > > > > eliminating redundancy. Further, it must define common
        > > patterns
        > > > > > > that
        > > > > > > > > apply
        > > > > > > > > > > to all business units and set up 'software factories' that
        > > > > enable
        > > > > > > the
        > > > > > > > > > > delivery of new products as services in a fraction of the
        > > time
        > > > > it
        > > > > > > used
        > > > > > > > > to
        > > > > > > > > > > take.
        > > > > > > > > > > A successful SOA initiative must begin with strategic
        > > > > investment
        > > > > > > and
        > > > > > > > > aim
        > > > > > > > > > > at lowering total cost of ownership as subsequent
        > > > > implementations
        > > > > > > takes
        > > > > > > > > > > place. For an organization to adopt this strategy, it
        > > needs to
        > > > > be
        > > > > > > > > mature
        > > > > > > > > > > enough to take the risk of initial investment.
        > > Organizations
        > > > > with a
        > > > > > > > > clear
        > > > > > > > > > > focus on implementation will reap long-term benefits. To
        > > define
        > > > > > > the SOA
        > > > > > > > > > > roadmap well, it is critical to understand that it is about
        > > > > > > processes
        > > > > > > > > or
        > > > > > > > > > > services definition as well as technology and people. (*See
        > > > > Figure
        > > > > > > 1,
        > > > > > > > > > > left.*)
        > > > > > > > >
        > > > > > > > > > > What Should We Be Thinking About?
        > > > > > > > > > > *Cut through the hype, be realistic*. SOA has been
        > > overhyped,
        > > > > > > oversold
        > > > > > > > >
        > > > > > > > > > > and set up to fail. Headlines decrying the failure of
        > > > > strategic SOA
        > > > > > > > > > > projects tell tales of woe. In many cases, organizations
        > > that
        > > > > > > merely
        > > > > > > > > needed
        > > > > > > > > > > some straightforward extensions to their existing
        > > architecture
        > > > > were
        > > > > > > > > up-sold
        > > > > > > > > > > unwieldy architectures that proved impossible to deploy.
        > > It's
        > > > > a bit
        > > > > > > > > like
        > > > > > > > > > > starting to build a bypass for a town, but somewhere along
        > > the
        > > > > way
        > > > > > > the
        > > > > > > > > > > project grew to the size of a major city. Some useful
        > > reality
        > > > > > > checks:
        > > > > > > > > > >
        > > > > > > > > > > - Ensure relevance by grading usefulness of each solution
        > > fit.
        > > > > > > > > > > - Start small and deliver business value before becoming
        > > more
        > > > > > > > > > > ambitious.
        > > > > > > > > > > - Define a roadmap for the entire service lifecycle, not
        > > just
        > > > > > > service
        > > > > > > > > > > identification.
        > > > > > > > > > > - Ensure that SOA is requi<br/><br/>(Message over 64 KB, truncated)
      Your message has been successfully submitted and would be delivered to recipients shortly.