Re: [service-orientated-architecture] Re: SOA Infrastructure

Mon, 13 Mar 2006 08:19:25 -0800

As many of you in this thread have pointed out, the impediments to SOA adoption are more cultural than technical.  But I'm a technologist, therefore I always like to see if we can't use technology to help solve the problem. (more on this point later)

As Jan pointed out:

I think [JP and Todd are arguing] that service orientation can be beneficially
applied at the business level by managing/modeling interactions
between intra-organisational parties in terms of services they
provide to each other (resulting in a contracts and responsibilities
view).

In my travels, I heard this approach referred to as Service Oriented Enterprise (SOE), and it's primary focus is to change the cultural structure of an IT organization. It certainly applies well to all interactions between intra- and inter-organizational parties, but I think IT departments need this kick in the pants more than other departments. Most IT departments don't have a service-oriented mindset. Instead they have a dictatorial mindset. "We tell you what we will give you, and you must abide by all our rules, and you will like it and not complain." And most IT department are run as a cost center.

In SOE, the IT department adopts a mindset focusing on providing services to the other departments, and they must compete with outside service providers for the privilege of providing those services. The other departments become "customers" rather than "users". The IT department is no longer a cost center. It becomes a profit center. It establishes contracts with its customers, and it must deliver on those contracts or suffer appropriate remunerations.

SOE is a an application of SOA: taking a service-oriented approach when designing an organisational system.

SODA is another application of SOA: taking a service-oriented approach when designing software applications.

But -- I think in both cases you need a certain amount of software infrastructure to support these applications of SOA principles. (Remember, I'm a technologist, and I like to use technology when it can help solve problems.)

SOE requires a bunch of infrastructure software to help the organization define, negotiate, manage, and maintain the contracts that exist between organizations, and it requires a ton of software to implement and operate the services and manage the SLAs.

SODA requires a bunch of infrastructure software that supports all service-oriented applications -- not just a specific application, so I reject the term SODA infrastructure. This infrastructure applies to software "systems", not software "applications. "Application" is too fine a granularity.

From my perspective, SOA infrastructure refers to all software infrastructure that may be used to facilitate development of service-oriented software systems, including application platforms and frameworks, SOA management systems, XML gateways, ESBs, other mediation systems, other middleware systems, registries, repositories, collaboration systems, contract management systems, policy management systems, collaboration tools, testing tools, etc. Some of these infrastructure products already exist in many enterprises, but many do not. Much of this infrastructure facilitates collaboration and development/management of contracts.

Anne

On 3/13/06, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote:
+1
Ron Schmelzer wrote:
Maybe the point is that SOA does align business and technology, but maybe companies already have ENOUGH technology. So the problem isn't to apply MORE technology, but rather to let the human side catch up with the equation? Sometimes in our haste to be techies, we forget that there's a balance with human activity. It's quite possible that companies already have all the technology they need to make SOA a reality. So, what's preventing SOA adoption? Maybe it's not the need for more technology. I'm not advocating a strong position here, but I am saying that there is another side to this argument / debate that is worth discussing.

I don't think anyone is suggesting to ditch technology and go back to typewriters (ok, maybe the Selectric branch of IBM might suggest that ;), but I think the emphasis has been placed too much on technology as being the sole answer to the problem. I see here a natural counterweight that requires us to think first in terms of human activities and then in terms of technology enablement rather than vice-versa.

Ron Schmelzer


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS





SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



Reply via email to