Comments on: SOA, a Business Facilitator http://www4.sungard.com/blogs/darrenWesemann/2007/09/27/soa-a-business-facilitator/ Darren Wesemann on SunGard Technology Thu, 08 Jan 2009 20:11:29 +0000 http://wordpress.org/?v=2.0.4 by: Darren Wesemann Blog » Blog Archive » SOA Top-down and Bottom-up / Flexibility and Reuse http://www4.sungard.com/blogs/darrenWesemann/2007/09/27/soa-a-business-facilitator/#comment-11180 Sat, 03 May 2008 15:02:21 +0000 http://www4.sungard.com/blogs/darrenWesemann/2007/09/27/soa-a-business-facilitator/#comment-11180 [...] Given that, it’s important to realize that the business domain (top-down) needs to weigh in heavier in the mix, at least as it relates to the prioritization of the SOA activities across the board (see my blog entry from last year here regarding the importance of a business focus on SOA).  This fosters the energy required to accelerate the flexibility benefits early on.  Meaningful reuse takes time anyway, in fact those that realize that sooner rather than later end up less trodden down by missed expectations.  In a delicate balance, developers and architects need to deal with the shared architectures and components that both follow those priorities as well as deal with the lower-level technical aspects the business domain doesn’t need to engage in (stuff like which message caching approach to use, which object-relational mapping to adopt, what debugger to leverage, or which API to chose for a particular task, etc). [...] […] Given that, it’s important to realize that the business domain (top-down) needs to weigh in heavier in the mix, at least as it relates to the prioritization of the SOA activities across the board (see my blog entry from last year here regarding the importance of a business focus on SOA).  This fosters the energy required to accelerate the flexibility benefits early on.  Meaningful reuse takes time anyway, in fact those that realize that sooner rather than later end up less trodden down by missed expectations.  In a delicate balance, developers and architects need to deal with the shared architectures and components that both follow those priorities as well as deal with the lower-level technical aspects the business domain doesn’t need to engage in (stuff like which message caching approach to use, which object-relational mapping to adopt, what debugger to leverage, or which API to chose for a particular task, etc). […]

]]> by: Charlie Peppler http://www4.sungard.com/blogs/darrenWesemann/2007/09/27/soa-a-business-facilitator/#comment-6084 Wed, 05 Dec 2007 21:32:53 +0000 http://www4.sungard.com/blogs/darrenWesemann/2007/09/27/soa-a-business-facilitator/#comment-6084 Darren, I can't agree more. I've had similar experiences when working with financial service firms. One of the problems seems to be that everyone is used to having different applications doing different things, with data duplication, and application redundancy, and the organization has adapted to life as a "data bucket brigade", fetching buckets of data (typically Excel spreadsheets) from one application, and then bringing them to the next one. Operational processes have "hardened" around this way of doing business, and it's difficult to get both the operations management, and their underlying personnel to see a different way of doing things. There has to be a means for getting everybody's head up out of the computer screens, and clearly identify how the business is going to flow, before IT ever really gets involved. IT is the cart, the business process is the horse. It _has_ to start with the business process, but somebody has to lead folks into believing that the technical people can get the applications (via SOA) to "talk amongst themselves", once the true business processes have been clearly identified. It's almost more of a people, culture problem then a technical one. The technology part is easy. It's getting the folks to work as a unit (instead of independent silos) that's hard. Charlie Peppler Darren,

I can’t agree more. I’ve had similar experiences when working with financial service firms. One of the problems seems to be that everyone is used to having different applications doing different things, with data duplication, and application redundancy, and the organization has adapted to life as a “data bucket brigade”, fetching buckets of data (typically Excel spreadsheets) from one application, and then bringing them to the next one.

Operational processes have “hardened” around this way of doing business, and it’s difficult to get both the operations management, and their underlying personnel to see a different way of doing things. There has to be a means for getting everybody’s head up out of the computer screens, and clearly identify how the business is going to flow, before IT ever really gets involved. IT is the cart, the business process is the horse.

It _has_ to start with the business process, but somebody has to lead folks into believing that the technical people can get the applications (via SOA) to “talk amongst themselves”, once the true business processes have been clearly identified. It’s almost more of a people, culture problem then a technical one. The technology part is easy. It’s getting the folks to work as a unit (instead of independent silos) that’s hard.

Charlie Peppler

]]>