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

Does SOA require being a service-oriented organization first?

Vote 0 Votes
As Joe McKendrick asks in his ZDnet blog, Does SOA require being a 'service-oriented organization' beforehand? Does good service-oriented architecture result from having a "service-oriented" focus and organization,  or does SOA help lead to a more service-oriented organization?

12 Replies

| Add a Reply
  • Which came first, the chicken or the egg?

  • My point is that the question itself provides the answer; you need both and they feed off each other forming an iterative "virtuous" circle.

  • All businesses have *some* level of service-orientation or basis (eg legal department, marketing department, sales department, etc) which have specialisations, even if there are no formal procedures for how and when to use them... likewise IT has always been about providing services. The fact that SOA emphasizes and exploits this service orientation has little to do with a business having an interdepartmental service-focus. IMHO.

  • Every individual within an organization provides a particular service which collectively rolls up to a functional group such as a department providing a coarse grained service and so on. So organizations by itself are Service Oriented and don’t need to do anything special, the IT just needs to align with the business for a successful SOA implementation.

  • I wonder if the question is asking “1. Is it organized as a set of service consumers and providers?? or whether “2. It is organized appropriately for SOA??

    As an organization matures in its use of SOA, there are numerous changes that will be required. Some of these are relevant to question 1 and some to question 2. Some examples of organizational capabilities relevant to question 1 include activities that mirror the separation of the service:
    - separation of service provisioning from solution delivery
    - separation of service specification from service implementation
    - separation of service testing and certification
    - outsourcing and offshore practices organized around service specification and delivery
    - etc

    Some examples of organization capabilities relevant to question 2 are more general organization changes that will make the organization more mature in its use of SOA and service oriented everything:
    - service portfolio planning function and responsibilities established
    - SOA CoE set up
    - roles and responsibilities established for service architect, service specification designer, tester etc etc
    - SOA and ITIL/ITSM responsibilities aligned and suitably integrated
    - Etc etc

    These are clearly not comprehensive, but you will get the idea.
    The question about sequencing is more complex because it’s not binary. But once we have some clarity on the question, it’s straightforward to map each organizational capability onto the states (phases) of the SOA Maturity Model and decide precedence.


  • I'd like to see a non-service oriented business ("All businesses have *some* level of service-orientation or basis").

    Another thing if the business is organised as services and consumers - internally and externally.

    When Business Architecture gets in force, process-centric organisations will gone At the same time, product centric organisations will be replaced by the service-centric ones where products will be just combinations of services.

  • From the technology perspective, I dont think it is necessary .. The IT organization should be capable of defining small chunks of SOA solutions to the business and make the business realize value of service orientation .. a step by step proliferation will be a better way to create/sustain service oriented organization.

    On the other hand, leaving the technical part out, most organizations today are inherently designed (verticals and horizontals) for services that horizontal departments provide to verticals .. what IT can do is to better enable intra-enterprise services based collaboration as well as create extra-enterprise services based collaboration by automating repeatable processes

  • If you have a business your service-oriented. Shame on you if you haven't had the appropriate oversight to ensure that your automated systems are service-oriented as well.

    If you are the IT arm of the business you should have been service-oriented decades ago!! Shame on you if you have not provided this to your company.

    If your an individual and your not service-oriented shame on you, won't be long before someone else walks over you as they "service" the business, i.e., business folks doing IT and IT folks doing business :)

    Remember "SOA" is just a marketing term and the "business" is getting much more clear on the value since they to are becoming more technology savvy, if for no other reason than to save themselves. Sad part is that the business will go find it internally or externally which ever keeps them in business - IT had better wake-up and realize it before they become what I would coin as "Outsourced-SOA".

  • Some businesses are in business in spite of themselves. That being said, the businesses that could benefit the most from service orientation best practices are the least inclined to adopt such practices. Conversely, the organizations that are the most advanced with SOA best practices are those that are forward-thinking on many fronts.

    Service orientation can lay the groundwork for better business practices.

  • There's a lot of poor implementations of SOA out there because those designing the SOA don't understand service-orientation. Just today I heard a group talk about using SOA a way to simplify the integration and interoperability problems and to provide a component framework. I believe many out there don't fully understand that a component framework is still a good thing in and of itself, and is not necessarily SOA. The service aspect of an entity comes with a lot of baggage that a component does not. For example, service levels and costing models. If a business does not ensure those things for itself in delivering a service, it usually goes out of business.

  • This discussion reminds me of the widespread confusion in the ITIL world about "service" and the consequent lack of real alignment with SOA. This really is at the heart of the service oriented organization. I did some research on ITIL and SOA last April and commented at the time:

    - to be honest found it (ITIL) a slippery beast
    - I found lots of inconsistency and no attempt on the part of the ITIL community to address core issues of nomenclature.
    - I therefore proposed a nomenclature and a simple classification system which I hope will at least avoid senseless time wasting over semantics.
    FYI I had a lot of corroborating response from large ITIL users. If this interests you see my blog http://tinyurl.com/2wx5hpf

  • implementing SOA properly does not require being Service Oriented Organization beforehand. It does require a level of Reuse Culture in the IT deparment and beyond. The Organizational Culture of some of my customers or potential customers was based upon rejecting anything that was Not Invented Here (NIH). NIH in that context could be something that was invented in another department of the same enterprise.I could tell that their SOA initiative will fail before it was launched. The only path towars successful SOA initiativeapplicable to them was chainging their Organizational Culture to more mature culture with some level of Reuse Culture.

    AS far as Service Oriented Organization is concerned, I think that Business units tend to be more Service Oriented than the IT department, so it is expected to find at least some degree of Service Orientation in the Business Architecture of any organization. However, that does not ensure a proper level of Service Abstraction.

Add a Reply

Recently Commented On

Monthly Archives