Happy New Year, everyone. Another year wraps up, and we now enter a new decade (which technically begins January 1, 2011). The practice of service oriented architecture has been part of the business technology scene for close to a decade. Some may argue that SOA has been around a lot longer than that, but SOA as we know it today — the development and deployment of loosely coupled, orchestrated, cross or intra-enterprise services (mainly Web services) to fulfill business processes — was first discussed in the mid 1990s, and came to fruition starting about 2003-2004. Through this time, there has been no shortage of confusion in the market what it means to be “service oriented.” Frequently, comments posted here at this blogsite call for better and clearer definitions of SOA, service orientation, and all else. For a great reference source of SOA-related definitions, see Don Fornes’ “Plain English Guide” to SOA. By the way, I like Don’s definition of SOA itself: “A new and better way to get a bunch of different software programs to work together so people can do things that require information from each of those systems.” As for the business purpose of SOA, here are some thinking points to consider: SOA is a “mutual” exercise for the business: Perhaps the best analogy for the way SOA should be governed is that of a mutual insurance company, in which the members are the company’s “owners” who play a role in electing company management. With SOA, every department should be the “owner” of the initiative, and play a role in the governance committee or team that oversees deployment decisions. The IT department should be but one player in the SOA scenario, and should serve as the “administrative” arm of the SOA infrastructure. Another analogy I’ve used over the years is that of a condo or homeowner’s association, in which everyone is an owner, but grants some oversight to a central governance board to oversee common services, such as maintenance and trash hauling. Again, IT is one of the “owners,” and also is contracted to oversee administration of the services. The perception that SOA is an “IT thing,” or that it should be controlled and managed by IT, has hampered the progression of service orientation in many companies.

Inside the Briefcase

ITBriefcase.net Membership!

Tweet Register as an ITBriefcase.net member to unlock exclusive...

Women in Tech Boston

Hear from an industry analyst and a Fortinet customer...

Four Reasons To Embrace Service-Oriented Thinking in 2011

December 31, 2010 No Comments

Happy New Year, everyone. Another year wraps up, and we now enter a new decade (which technically begins January 1, 2011).

The practice of service oriented architecture has been part of the business technology scene for close to a decade. Some may argue that SOA has been around a lot longer than that, but SOA as we know it today — the development and deployment of loosely coupled, orchestrated, cross or intra-enterprise services (mainly Web services) to fulfill business processes — was first discussed in the mid 1990s, and came to fruition starting about 2003-2004.

Through this time, there has been no shortage of confusion in the market what it means to be “service oriented.” Frequently, comments posted here at this blogsite call for better and clearer definitions of SOA, service orientation, and all else.

For a great reference source of SOA-related definitions, see Don Fornes’ “Plain English Guide” to SOA. By the way, I like Don’s definition of SOA itself: “A new and better way to get a bunch of different software programs to work together so people can do things that require information from each of those systems.”

As for the business purpose of SOA, here are some thinking points to consider:

SOA is a “mutual” exercise for the business: Perhaps the best analogy for the way SOA should be governed is that of a mutual insurance company, in which the members are the company’s “owners” who play a role in electing company management. With SOA, every department should be the “owner” of the initiative, and play a role in the governance committee or team that oversees deployment decisions. The IT department should be but one player in the SOA scenario, and should serve as the “administrative” arm of the SOA infrastructure. Another analogy I’ve used over the years is that of a condo or homeowner’s association, in which everyone is an owner, but grants some oversight to a central governance board to oversee common services, such as maintenance and trash hauling. Again, IT is one of the “owners,” and also is contracted to oversee administration of the services. The perception that SOA is an “IT thing,” or that it should be controlled and managed by IT, has hampered the progression of service orientation in many companies.

Read More of Joe McKendrick’s Blog on ZDNet