We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

Is 'Service-Oriented Approach' a Better Way to Define SOA?

Vote 0 Votes
As Joe McKendrick asks in this blog, a question which was inspired by JP Morgenthal, and as JP asks: Is SOA really architecture, or is it simply a strategy for business transformation?

So is 'service-oriented approach' a better way to define SOA?

6 Replies

| Add a Reply
  • The concept of service-orientation can apply to many things. How many businesses out there describe themselves as a service-oriented company? A lot of what we do as architects is categorization. We create categories that make the job of others easier by giving them context. The intent is that this categorization can help guide them to better decisions toward the goals involved, both at the project level and at the business level. When categorizing non-technical things, some people may question whether that's architecture or not.

    The term architect has become pervasive in many IT shops, even if it is overused by many. If your organization has too many architects and does a poor job is defining what is architecture and what it isn't, then the term architecture may become a "bad" word. Every organization has words that now leave a bad taste in people's mouths because of prior experience. If calling things a "service-oriented approach" rather than "service-oriented architecture" help you accomplish your goals by avoiding the baggage that may be associated with term architecture or using terminology that may resonate better with your stakeholders, then by all means, go with it.

    -tb

  • I think 'service oriented' can apply right across the enterprise. Most, if not all enterprises strive to get consistency and reusability in everything they do so that when the 'service' is done well, customers will be happy. If not, the service must be adapted. This new adapted serice should then be reused by all, not just the one that discovered the fault. Of course all older versions of the service should be deprecated to ensure consistency. This 'service' could be anything from someone taking a call in a call centre to someone serving behind a counter. It could also apply to the IT service that's invoked to log the phone call or register the transaction from the shop assistant. So 'service-oriented' everywhere IMHO.

  • Our colleague Dave Linthicum said that Service Oriented Architecture would eventually blend in as part of Enterprise Architecture. SOA seems to have a more of an action element to it, versus EA. For example, you don't really hear about companies launching EA programs to accomplish this or that -- it's something that sensible enterprises just do to get their business technology houses in order and ready to adapt. Perhaps SOA is more of an activity, versus EA, which is the foundation.

  • A "service-oriented approach" to something is very different than understanding or creating a Service-Oriented Architecture.

    A "service-oriented approach" can take the form of something like adhering to Information Technology Infrastructure Library(ITIL).

    BUT, WAIT, we are probably talking about services that perform some automated functionality....As such, there are design fundamentals, paradigms, characteristics, standards, best practices, principles, and design patterns that lay the foundation for a service-oriented approach.

    A Service-Oriented Architecture establishes an architectural model for efficiency, agility and productivity and is designed in compliance with service-oriented design principles. Which, in my opinion, sits inside a SOA Infrastructure.

  • My view is that approach and architecture are two different things. Somewhat contrary to Joe's view above, I see the approach as an activity. An approach is an action undertaken to solve a problem. In the context of IT, architecture is a deliverable. It is a documented structure within which solutions are created.

    I think the heart of the question is has the term SOA been co-opted? Since the architectural deliverable has not been pervasive but the approach has, did the meaning shift? Changing the definition will only create confusion. As people take a service oriented approach, slowly evolving legacy architectures, then perhaps the deliverable will become attainable without disrupting the business driven IT value chain. Said another way, the approach is a tactical execution to the larger strategy of the architecture all the while delivering tangible business value.

  • Maybe we should ask what's easier to sell: an approach or an architecture?

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT