• First Reference
  • About us
  • Contact us
  • 24th Annual Ontario Employment Law Conference 📣
  • Blog Signup 📨

First Reference Talks

Discussions on Human Resources, Employment Law, Payroll and Internal Controls

  • Home
  • About
  • Archives
  • Resources
You are here: Home / Business / Your service-oriented architecture expert opinion

By Ron Richard | 2 Minutes Read February 4, 2013

Your service-oriented architecture expert opinion

I recently came across two different definitions of service-oriented architecture (SOA):

  1. SOA is essentially a set of principles used during the design and development of systems that must enable interoperability with other systems. … SOA tends to be a loosely coupled system of functionality exposed over a network (i.e., Internet) that allows users to combine and use the resources exposed. (Info-Tech Research Group)
  2. SOA is the underlying structure supporting communications between services. SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. Each interaction is self-contained and loosely coupled, so that each interaction is independent of any other interaction. (SearchSOA)

And I asked a connection, Grady Booch, if he would share his expert opinion and answer the following question, do these two definitions align, or is one correct or more correct?
Here is his reply:

My take is that these two perspectives are in reasonable harmony. Three things that both of them don’t address, however:

  • SOA is more than just message-passing on steroids…and yet, a naive interpretation of the first definition could lead one to conclude that. It would be valuable to describe what SOA is not (it’s not just message-passing).
  • The hard part of SOA is reaching the right granularity of service. Too fine-grained and it requires too much work to make the parts fit and leads to misuse, unless you provide patterns of good use. Too coarse and it’s hard to integrate with new, unforeseen uses.
  • SOA is not just about web services; one may still have an SOA architecture and use more than heavyweight web services.

On a related note Grady points out that:

Quality and value are two of the forces that shape as well as are emergent from the architecture of a software-intensive system. Interestingly, these factors—quality and value—appear to be consistent with architectural elegance and simplicity. (From a review of Inherent Quality Simplicity)

Here is one of Grady’s presentations (“SOA as an Architectural Pattern: Best Practices in Software Architecture”), and here is the SOA Manifesto (Grady, of course, is one of the noted authors).
Looking forward to reading your comments and opinions in relation to the noted definitions, and in general about SOA. Here also is an interesting job posting involving SOA (Director of Insights), and here a some additional links as food for thought:

  • SOA Consortium discussion paper (“Business Architecture: The Missing Link between Business Strategy and Enterprise Architecture”)
  • Study on cloud and service oriented architecture for e-government
  • TechRepublic SOA white papers & case studies
  • SOA migration case studies and lessons learned

My sincere thanks to Grady for his commentary.
Ron Richard, I.S.P, ITCP/IP3P
LinkedIn Profile and Personal Website

  • About
  • Latest Posts
Ron Richard
Ron Richard, Quality, Information Technology and Enterprise Risk Management specialist, has earned professional designations from multiple countries, held positions at most any level, and acquired more than 30 years of relevant experience including related work done at the College of the North Atlantic. Ron is author of Inherent Quality Simplicity and the Inside Internal Control newsletter Modern Quality Management series.
Latest posts by Ron Richard (see all)
  • Change, exponential power, enterprise architecture, governance and stakeholder engagement - March 4, 2013
  • Take testing activities up a level - February 4, 2013
  • Your service-oriented architecture expert opinion - February 4, 2013

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to email a link to a friend (Opens in new window)
  • Click to print (Opens in new window)
  • More
  • Click to share on Reddit (Opens in new window)
  • Click to share on Tumblr (Opens in new window)
  • Click to share on Pocket (Opens in new window)
  • Click to share on Mastodon (Opens in new window)

Article by Ron Richard / Business, Finance and Accounting, Not for Profit, Privacy / Case studies, Cloud, Definitions, e-government, expert opinion, Grady Booch, IBM, Info-Tech, Inherent Quality Simplicity, Lessons Learned, Service Oriented Architecture, SOA, SOA Consortium, SOA Manifesto, TechTarget, Whitepapers

Get the Latest Posts in your Inbox for Free!

Electronic monitoring

About Ron Richard

Ron Richard, Quality, Information Technology and Enterprise Risk Management specialist, has earned professional designations from multiple countries, held positions at most any level, and acquired more than 30 years of relevant experience including related work done at the College of the North Atlantic. Ron is author of Inherent Quality Simplicity and the Inside Internal Control newsletter Modern Quality Management series.

Reader Interactions

Comments

  1. Ron says

    February 20, 2013 at 2:14 pm

    Thanks Karl, great to have an expert from France read and comment; and Thanks Regine, great also to have an expert from the UK do the same (Grady of course is US based; my thanks again for his contribution). It would be great if other experts from different parts of the world also commented from various EA, SOA, Cloud, Governance, SLAs, ALM and other perspectives such as “Business Architecture: The Missing Link between Business Strategy and Enterprise Architecture”.

  2. Regine Deleu says

    February 18, 2013 at 12:21 pm

    I totally agree with Grady, SOA has elements described in both definitions. SOA is an architect style, a set of principles and a methodology for designing and developing software in the form of inter-operable services. These services are built as software components and have well-defined business functionality which can be reused for different purposes. They are orchestrated through loose coupling.

  3. Karl Schulmeistrs says

    February 18, 2013 at 12:05 pm

    I tend to agree with G. Booch that the two above definitions are neither compatible nor complete. SOA is a design as well as an implementation pattern. On the design side the difficulty is in fact getting the granularity of service correct, on the implementation side the difficulty historically has been governance and lifecycle management – specifically services that have been “orphaned” by their original implementors/consumers but are still in use by other consumers and duplicate but highly similar services all being carried on the IT Budget of the organization
    Cloud Computing somewhat reduces the ALM and governance issues by putting the costs of service continutity and reference management on the vendor. But this brings into necessity much stronger reliance on SLAs (Service Level Agreements)) – something that to date is not yet really automated.

Footer

About us

Established in 1995, First Reference is the leading publisher of up to date, practical and authoritative HR compliance and policy databases that are essential to ensure organizations meet their due diligence and duty of care requirements.

First Reference Talks

  • Home
  • About
  • Archives
  • Resources

Main Menu

  • About First Reference
  • Resources
  • Contact us
  • 1 800 750 8175

Stay Connected

  • Facebook
  • LinkedIn
  • Twitter
  • YouTube

We welcome your comments on our blog articles. However, we do not respond to specific legal questions in this space.
We do not provide any form of legal advice or legal opinion. Please consult a lawyer in your jurisdiction or try one of our products.


Copyright © 2009 - 2023 · First Reference Inc. · All Rights Reserved
Legal and Copyright Notices · Publisher's Disclaimer · Privacy Policy · Accessibility Policy