Loading ...
Sorry, an error occurred while loading the content.

Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

Expand Messages
  • Anders W. Tell
    Interesting comment, do you mean Equality, or SOA is part of BDA or BDA i realized by SOA? /anders ... Interesting comment, do you mean Equality, or SOA is
    Message 1 of 13 , Feb 1, 2011
    • 0 Attachment
      Interesting comment, do you mean Equality, or SOA is part of BDA or BDA i realized by SOA?

      /anders


      On Dec 29, 2010, at 9:03 PM, Michael Poulin wrote:

       

      I am afraid that Gabhart  does not see SOA  further than an 'IT nose'. It is pity. Business-Driven Architecture is SOA and nothing else.

      - Michael


      From: Gervas Douglas <gervas.douglas@...>
      To: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com; enterprise-architecture@yahoogroups.com
      Sent: Wed, December 29, 2010 4:33:28 PM
      Subject: [enterprise-architecture] Gabhart on Business-Driven Architecture

       

      <<One essential aspect of getting genuine value out of architecture involves the proper identification of when to apply certain tools to solve a problem.  There is often a struggle between the desire to apply a new technique / methodology / framework / technology to a problem and the decision to apply the correct solution for a given problem domain.  Just because it is possible to solve a problem with SOA does not mean it was the best fit.  Just because you can put a particular application in the Cloud does not necessarily mean that Cloud Computing was the best answer to address the requirements.  Architects must set aside their excitement for playing with new technologies and methodologies in favor of a pragmatic and objective analysis of finding the best solution for a given problem.

      Example #1 - I’m currently leading the architecture and design for a legacy system modernization effort.  The steering committee directed me to apply SOA.  The technical stakeholders assumed SOA.  My preliminary investigation into the project pointed me toward SOA.  Finally, my personal bias favors the use of SOA (my brain naturally operates in a service oriented fashion, I wrote a book on SOA, the title of this blog used to be ‘SOA Matters’, etc.).  And yet, after a more in-depth analysis and some genuine architectural soul-searching…..I had to admit that SOA was not the best answer for the system and was a fairly poor answer for the organizations that would be using the system.  The decision to EXCLUDE the use of SOA ended up being as important to the overall architecture and system design as the decision to INCLUDE other architectural design strategies for consideration.

      Example #2 - I often find myself advising clients against the use of Cloud Computing.  I am not a Luddite and I have no particular bias against things which are ‘new and shiny’.  What I do have is a healthy degree of skepticism and a keen awareness that you need a business case for technology, not a mandate that allows you to pursue whatever is new and trendy.  While I believe strongly in the value of Cloud Computing and have several clients that I am actively engaged in consulting regarding the use of Cloud, these are the exception cases.  I find far more often that I work with clients to help them better understand Cloud and in many cases realize that applying a Cloud solution in their case would not really be value-added.  Generally a significant degree of value can be achieved with basic server virtualization, a lean SOA implementation, and/or some good solid clustering, load-balancing, and routing solutions.  Just because it is possible to deploy a solution into the Cloud does not necessarily mean that you should.  There needs to be a genuine business case that points to Cloud as the best answer, not just an acceptable answer.  This principle applies to all sorts of architecture implementation options.

      Example #3 - My basic advice around governance (and it holds true for EA governance, SOA governance, MDM governance, etc.) is to go as simple as you can possibly get away with being.  ????  This often surprises people.  But don’t we want more governance?  If we have more standards, more guidelines, more tools, more processes, etc. - then that points to more maturity, right?  Not usually.  I tend to find that an over-abundance of those things points to a lack of maturity and a fear that things will be mishandled.  A more mature enterprise would rely upon skills, education, resources allocation, and a core set of design principles to handle the bulk of those things.  So I actually actively encourage organizations to go as lean as they can possibly get away with for their installation.  As they expand and grow, there will be more pressures and more demands that may force the introduction of new tools, processes, and standards, but don’t put them in there until you need them and they will be value-added.  This maintains your sanity and tends to promote a value-driven approach to governance rather than a model where-by governance is added for its own sake (which tends to be counter-productive, instilling frustration and resentment within the team).

      What’s driving your architecture?

      Often times, the title of my blog posting will come very readily to me.  This one I struggled with a bit.  I ultimately selected ‘Business-driven Architecture’ and there was a lot of contemplation behind that decision.  What I find far too often is that enterprises end up with their architecture being driven by all sorts of things OTHER than their business:

      • Vendor-driven Architecture
      • Platform-driven Architecture
      • Buzzword-driven Architecture
      • Fad-driven Architecture
      • Consultant-driven Architecture

      If you are not driving architecture decisions based upon what is fundamentally and foremost in the best interests of the business, then you are missing the boat.  We have to take technologists, vendors, and pocket-lining consultants out of the driver’s seat and put stakeholders, domain experts, and business leaders into the driver’s seat to steer the enterprise in the direction it needs to go.  Business-driven, strategic architecture is the only type that ultimately has value.>>

      You can find this at: http://soamatters.com/blog/2010/11/11/business-driven-architecture/

      Gervas




    • Michael Poulin
      Andres, it is your question is interesting ( to me, at least ) :-) I see SOA as one of possible realisations of the Concept of Service Orientation. While BDA
      Message 2 of 13 , Feb 2, 2011
      • 0 Attachment
        Andres, it is your question is interesting ( to me, at least ) :-)

        I see SOA as one of possible realisations of the Concept of Service Orientation. While BDA and technical EA are actual implementation of architectural abstraction, Service Orientation may be (if applied properly) the common, shared , enterprise-wide concept for both  - Business and Technology. Saying this, I think that to be successful in the modern dynamic/volatile market, the BDA must be implemented as SOA (in the prosper time, it may be more BPM oriented).

        - Michael


        From: Anders W. Tell <anderst@...>
        To: enterprise-architecture@yahoogroups.com
        Cc: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com
        Sent: Tue, February 1, 2011 12:34:55 PM
        Subject: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

         

        Interesting comment, do you mean Equality, or SOA is part of BDA or BDA i realized by SOA?

        /anders


        On Dec 29, 2010, at 9:03 PM, Michael Poulin wrote:

         

        I am afraid that Gabhart  does not see SOA  further than an 'IT nose'. It is pity. Business-Driven Architecture is SOA and nothing else.

        - Michael


        From: Gervas Douglas <gervas.douglas@...>
        To: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com; enterprise-architecture@yahoogroups.com
        Sent: Wed, December 29, 2010 4:33:28 PM
        Subject: [enterprise-architecture] Gabhart on Business-Driven Architecture

         

        <<One essential aspect of getting genuine value out of architecture involves the proper identification of when to apply certain tools to solve a problem.  There is often a struggle between the desire to apply a new technique / methodology / framework / technology to a problem and the decision to apply the correct solution for a given problem domain.  Just because it is possible to solve a problem with SOA does not mean it was the best fit.  Just because you can put a particular application in the Cloud does not necessarily mean that Cloud Computing was the best answer to address the requirements.  Architects must set aside their excitement for playing with new technologies and methodologies in favor of a pragmatic and objective analysis of finding the best solution for a given problem.

        Example #1 - I’m currently leading the architecture and design for a legacy system modernization effort.  The steering committee directed me to apply SOA.  The technical stakeholders assumed SOA.  My preliminary investigation into the project pointed me toward SOA.  Finally, my personal bias favors the use of SOA (my brain naturally operates in a service oriented fashion, I wrote a book on SOA, the title of this blog used to be ‘SOA Matters’, etc.).  And yet, after a more in-depth analysis and some genuine architectural soul-searching…..I had to admit that SOA was not the best answer for the system and was a fairly poor answer for the organizations that would be using the system.  The decision to EXCLUDE the use of SOA ended up being as important to the overall architecture and system design as the decision to INCLUDE other architectural design strategies for consideration.

        Example #2 - I often find myself advising clients against the use of Cloud Computing.  I am not a Luddite and I have no particular bias against things which are ‘new and shiny’.  What I do have is a healthy degree of skepticism and a keen awareness that you need a business case for technology, not a mandate that allows you to pursue whatever is new and trendy.  While I believe strongly in the value of Cloud Computing and have several clients that I am actively engaged in consulting regarding the use of Cloud, these are the exception cases.  I find far more often that I work with clients to help them better understand Cloud and in many cases realize that applying a Cloud solution in their case would not really be value-added.  Generally a significant degree of value can be achieved with basic server virtualization, a lean SOA implementation, and/or some good solid clustering, load-balancing, and routing solutions.  Just because it is possible to deploy a solution into the Cloud does not necessarily mean that you should.  There needs to be a genuine business case that points to Cloud as the best answer, not just an acceptable answer.  This principle applies to all sorts of architecture implementation options.

        Example #3 - My basic advice around governance (and it holds true for EA governance, SOA governance, MDM governance, etc.) is to go as simple as you can possibly get away with being.  ????  This often surprises people.  But don’t we want more governance?  If we have more standards, more guidelines, more tools, more processes, etc. - then that points to more maturity, right?  Not usually.  I tend to find that an over-abundance of those things points to a lack of maturity and a fear that things will be mishandled.  A more mature enterprise would rely upon skills, education, resources allocation, and a core set of design principles to handle the bulk of those things.  So I actually actively encourage organizations to go as lean as they can possibly get away with for their installation.  As they expand and grow, there will be more pressures and more demands that may force the introduction of new tools, processes, and standards, but don’t put them in there until you need them and they will be value-added.  This maintains your sanity and tends to promote a value-driven approach to governance rather than a model where-by governance is added for its own sake (which tends to be counter-productive, instilling frustration and resentment within the team).

        What’s driving your architecture?

        Often times, the title of my blog posting will come very readily to me.  This one I struggled with a bit.  I ultimately selected ‘Business-driven Architecture’ and there was a lot of contemplation behind that decision.  What I find far too often is that enterprises end up with their architecture being driven by all sorts of things OTHER than their business:

        • Vendor-driven Architecture
        • Platform-driven Architecture
        • Buzzword-driven Architecture
        • Fad-driven Architecture
        • Consultant-driven Architecture

        If you are not driving architecture decisions based upon what is fundamentally and foremost in the best interests of the business, then you are missing the boat.  We have to take technologists, vendors, and pocket-lining consultants out of the driver’s seat and put stakeholders, domain experts, and business leaders into the driver’s seat to steer the enterprise in the direction it needs to go.  Business-driven, strategic architecture is the only type that ultimately has value.>>

        You can find this at: http://soamatters.com/blog/2010/11/11/business-driven-architecture/

        Gervas





      • Anders W. Tell
        Im not sure i see the rationale behind the necessity. Of course SOA, service orientation could be used for implementations but I havent seen any evidence on
        Message 3 of 13 , Feb 5, 2011
        • 0 Attachment
          Im not sure i see the rationale behind the necessity. Of course SOA, service orientation could be used for implementations but I havent seen any evidence on the superiority and necessity of IT-Sxxx. On the contrary Im part of a major EU project where the use of E(IT)A and IT-Sxxx was major reasons for halting the project.

          Aren't we better of saying that IT-Sxx is one possible paradigm with certain characteristics amongst other paradigm with other characteristics?.
          Could you elaborate on the rationale of necessity?

          /anders


          On Feb 2, 2011, at 10:20 AM, Michael Poulin wrote:

           

          Andres, it is your question is interesting ( to me, at least ) :-)

          I see SOA as one of possible realisations of the Concept of Service Orientation. While BDA and technical EA are actual implementation of architectural abstraction, Service Orientation may be (if applied properly) the common, shared , enterprise-wide concept for both  - Business and Technology. Saying this, I think that to be successful in the modern dynamic/volatile market, the BDA must be implemented as SOA (in the prosper time, it may be more BPM oriented).

          - Michael


          From: Anders W. Tell <anderst@...>
          To: enterprise-architecture@yahoogroups.com
          Cc: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com
          Sent: Tue, February 1, 2011 12:34:55 PM
          Subject: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

           

          Interesting comment, do you mean Equality, or SOA is part of BDA or BDA i realized by SOA?

          /anders


          On Dec 29, 2010, at 9:03 PM, Michael Poulin wrote:

           

          I am afraid that Gabhart  does not see SOA  further than an 'IT nose'. It is pity. Business-Driven Architecture is SOA and nothing else.

          - Michael


          From: Gervas Douglas <gervas.douglas@...>
          To: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com; enterprise-architecture@yahoogroups.com
          Sent: Wed, December 29, 2010 4:33:28 PM
          Subject: [enterprise-architecture] Gabhart on Business-Driven Architecture

           

          <<One essential aspect of getting genuine value out of architecture involves the proper identification of when to apply certain tools to solve a problem.  There is often a struggle between the desire to apply a new technique / methodology / framework / technology to a problem and the decision to apply the correct solution for a given problem domain.  Just because it is possible to solve a problem with SOA does not mean it was the best fit.  Just because you can put a particular application in the Cloud does not necessarily mean that Cloud Computing was the best answer to address the requirements.  Architects must set aside their excitement for playing with new technologies and methodologies in favor of a pragmatic and objective analysis of finding the best solution for a given problem.

          Example #1 - I’m currently leading the architecture and design for a legacy system modernization effort.  The steering committee directed me to apply SOA.  The technical stakeholders assumed SOA.  My preliminary investigation into the project pointed me toward SOA.  Finally, my personal bias favors the use of SOA (my brain naturally operates in a service oriented fashion, I wrote a book on SOA, the title of this blog used to be ‘SOA Matters’, etc.).  And yet, after a more in-depth analysis and some genuine architectural soul-searching…..I had to admit that SOA was not the best answer for the system and was a fairly poor answer for the organizations that would be using the system.  The decision to EXCLUDE the use of SOA ended up being as important to the overall architecture and system design as the decision to INCLUDE other architectural design strategies for consideration.

          Example #2 - I often find myself advising clients against the use of Cloud Computing.  I am not a Luddite and I have no particular bias against things which are ‘new and shiny’.  What I do have is a healthy degree of skepticism and a keen awareness that you need a business case for technology, not a mandate that allows you to pursue whatever is new and trendy.  While I believe strongly in the value of Cloud Computing and have several clients that I am actively engaged in consulting regarding the use of Cloud, these are the exception cases.  I find far more often that I work with clients to help them better understand Cloud and in many cases realize that applying a Cloud solution in their case would not really be value-added.  Generally a significant degree of value can be achieved with basic server virtualization, a lean SOA implementation, and/or some good solid clustering, load-balancing, and routing solutions.  Just because it is possible to deploy a solution into the Cloud does not necessarily mean that you should.  There needs to be a genuine business case that points to Cloud as the best answer, not just an acceptable answer.  This principle applies to all sorts of architecture implementation options.

          Example #3 - My basic advice around governance (and it holds true for EA governance, SOA governance, MDM governance, etc.) is to go as simple as you can possibly get away with being.  ????  This often surprises people.  But don’t we want more governance?  If we have more standards, more guidelines, more tools, more processes, etc. - then that points to more maturity, right?  Not usually.  I tend to find that an over-abundance of those things points to a lack of maturity and a fear that things will be mishandled.  A more mature enterprise would rely upon skills, education, resources allocation, and a core set of design principles to handle the bulk of those things.  So I actually actively encourage organizations to go as lean as they can possibly get away with for their installation.  As they expand and grow, there will be more pressures and more demands that may force the introduction of new tools, processes, and standards, but don’t put them in there until you need them and they will be value-added.  This maintains your sanity and tends to promote a value-driven approach to governance rather than a model where-by governance is added for its own sake (which tends to be counter-productive, instilling frustration and resentment within the team).

          What’s driving your architecture?

          Often times, the title of my blog posting will come very readily to me.  This one I struggled with a bit.  I ultimately selected ‘Business-driven Architecture’ and there was a lot of contemplation behind that decision.  What I find far too often is that enterprises end up with their architecture being driven by all sorts of things OTHER than their business:

          • Vendor-driven Architecture
          • Platform-driven Architecture
          • Buzzword-driven Architecture
          • Fad-driven Architecture
          • Consultant-driven Architecture

          If you are not driving architecture decisions based upon what is fundamentally and foremost in the best interests of the business, then you are missing the boat.  We have to take technologists, vendors, and pocket-lining consultants out of the driver’s seat and put stakeholders, domain experts, and business leaders into the driver’s seat to steer the enterprise in the direction it needs to go.  Business-driven, strategic architecture is the only type that ultimately has value.>>

          You can find this at: http://soamatters.com/blog/2010/11/11/business-driven-architecture/

          Gervas







        • Michael Poulin
          Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional
          Message 4 of 13 , Feb 5, 2011
          • 0 Attachment
            Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

            The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

            So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

            When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple. I am wring about this on many occasions in my BLOG at ebizQ (http://www.ebizq.net/blogs/service_oriented/2009/01/)

            If you need an actual professional consultation, contact me via LinkedIn.

            - Michael


            From: Anders W. Tell <anderst@...>
            To: service-orientated-architecture@yahoogroups.com
            Sent: Sat, February 5, 2011 3:31:30 PM
            Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

             

            Im not sure i see the rationale behind the necessity. Of course SOA, service orientation could be used for implementations but I havent seen any evidence on the superiority and necessity of IT-Sxxx. On the contrary Im part of a major EU project where the use of E(IT)A and IT-Sxxx was major reasons for halting the project.

            Aren't we better of saying that IT-Sxx is one possible paradigm with certain characteristics amongst other paradigm with other characteristics?.
            Could you elaborate on the rationale of necessity?

            /anders


            On Feb 2, 2011, at 10:20 AM, Michael Poulin wrote:

             

            Andres, it is your question is interesting ( to me, at least ) :-)

            I see SOA as one of possible realisations of the Concept of Service Orientation. While BDA and technical EA are actual implementation of architectural abstraction, Service Orientation may be (if applied properly) the common, shared , enterprise-wide concept for both  - Business and Technology. Saying this, I think that to be successful in the modern dynamic/volatile market, the BDA must be implemented as SOA (in the prosper time, it may be more BPM oriented).

            - Michael


            From: Anders W. Tell <anderst@...>
            To: enterprise-architecture@yahoogroups.com
            Cc: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com
            Sent: Tue, February 1, 2011 12:34:55 PM
            Subject: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

             

            Interesting comment, do you mean Equality, or SOA is part of BDA or BDA i realized by SOA?

            /anders


            On Dec 29, 2010, at 9:03 PM, Michael Poulin wrote:

             

            I am afraid that Gabhart  does not see SOA  further than an 'IT nose'. It is pity. Business-Driven Architecture is SOA and nothing else.

            - Michael


            From: Gervas Douglas <gervas.douglas@...>
            To: service-orientated-architecture@yahoogroups.com; cloudcomputing-tech@yahoogroups.com; enterprise-architecture@yahoogroups.com
            Sent: Wed, December 29, 2010 4:33:28 PM
            Subject: [enterprise-architecture] Gabhart on Business-Driven Architecture

             

            <<One essential aspect of getting genuine value out of architecture involves the proper identification of when to apply certain tools to solve a problem.  There is often a struggle between the desire to apply a new technique / methodology / framework / technology to a problem and the decision to apply the correct solution for a given problem domain.  Just because it is possible to solve a problem with SOA does not mean it was the best fit.  Just because you can put a particular application in the Cloud does not necessarily mean that Cloud Computing was the best answer to address the requirements.  Architects must set aside their excitement for playing with new technologies and methodologies in favor of a pragmatic and objective analysis of finding the best solution for a given problem.

            Example #1 - I’m currently leading the architecture and design for a legacy system modernization effort.  The steering committee directed me to apply SOA.  The technical stakeholders assumed SOA.  My preliminary investigation into the project pointed me toward SOA.  Finally, my personal bias favors the use of SOA (my brain naturally operates in a service oriented fashion, I wrote a book on SOA, the title of this blog used to be ‘SOA Matters’, etc.).  And yet, after a more in-depth analysis and some genuine architectural soul-searching…..I had to admit that SOA was not the best answer for the system and was a fairly poor answer for the organizations that would be using the system.  The decision to EXCLUDE the use of SOA ended up being as important to the overall architecture and system design as the decision to INCLUDE other architectural design strategies for consideration.

            Example #2 - I often find myself advising clients against the use of Cloud Computing.  I am not a Luddite and I have no particular bias against things which are ‘new and shiny’.  What I do have is a healthy degree of skepticism and a keen awareness that you need a business case for technology, not a mandate that allows you to pursue whatever is new and trendy.  While I believe strongly in the value of Cloud Computing and have several clients that I am actively engaged in consulting regarding the use of Cloud, these are the exception cases.  I find far more often that I work with clients to help them better understand Cloud and in many cases realize that applying a Cloud solution in their case would not really be value-added.  Generally a significant degree of value can be achieved with basic server virtualization, a lean SOA implementation, and/or some good solid clustering, load-balancing, and routing solutions.  Just because it is possible to deploy a solution into the Cloud does not necessarily mean that you should.  There needs to be a genuine business case that points to Cloud as the best answer, not just an acceptable answer.  This principle applies to all sorts of architecture implementation options.

            Example #3 - My basic advice around governance (and it holds true for EA governance, SOA governance, MDM governance, etc.) is to go as simple as you can possibly get away with being.  ????  This often surprises people.  But don’t we want more governance?  If we have more standards, more guidelines, more tools, more processes, etc. - then that points to more maturity, right?  Not usually.  I tend to find that an over-abundance of those things points to a lack of maturity and a fear that things will be mishandled.  A more mature enterprise would rely upon skills, education, resources allocation, and a core set of design principles to handle the bulk of those things.  So I actually actively encourage organizations to go as lean as they can possibly get away with for their installation.  As they expand and grow, there will be more pressures and more demands that may force the introduction of new tools, processes, and standards, but don’t put them in there until you need them and they will be value-added.  This maintains your sanity and tends to promote a value-driven approach to governance rather than a model where-by governance is added for its own sake (which tends to be counter-productive, instilling frustration and resentment within the team).

            What’s driving your architecture?

            Often times, the title of my blog posting will come very readily to me.  This one I struggled with a bit.  I ultimately selected ‘Business-driven Architecture’ and there was a lot of contemplation behind that decision.  What I find far too often is that enterprises end up with their architecture being driven by all sorts of things OTHER than their business:

            • Vendor-driven Architecture
            • Platform-driven Architecture
            • Buzzword-driven Architecture
            • Fad-driven Architecture
            • Consultant-driven Architecture

            If you are not driving architecture decisions based upon what is fundamentally and foremost in the best interests of the business, then you are missing the boat.  We have to take technologists, vendors, and pocket-lining consultants out of the driver’s seat and put stakeholders, domain experts, and business leaders into the driver’s seat to steer the enterprise in the direction it needs to go.  Business-driven, strategic architecture is the only type that ultimately has value.>>

            You can find this at: http://soamatters.com/blog/2010/11/11/business-driven-architecture/

            Gervas








          • Anders W. Tell
            ... Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and
            Message 5 of 13 , Feb 13, 2011
            • 0 Attachment

              On Feb 5, 2011, at 8:54 PM, Michael Poulin wrote:

               

              Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

              Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and operational domains and is accepted by non-IT people and not defined by IT professionals?

              Im currently researching the topic of differences between the point-of-views of Non-IT and IT/engineering, so any new developments are of interest to know. One reason for this is that there seems to be a number of SO artifacts that Non-IT professional dont understand or really understand. Im interested in what can be improved.



              The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

              Now this is where you loose me. What are the chains of logic/causality from SO to "actual" flexibility and adoption to market changes? 
              Of course a flexible IT solution is supporting/contributing but there appears to be lots of aspects that influence a flexible organinsation and a contribution of an IT-part may drown in other influences.



              So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

              IT point-of-view: web services and REST. rather disinteresting from a Non-IT point-of-view.

              Delegation on the other hand is of interest, and access to (information) resources.



              When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple.

              Now we are on the same page. IT solutions is a performer of work or used as a tool for other performers.


              If you need an actual professional consultation, contact me via LinkedIn.

              Unfortunately Im one of those that give advice and do research, so maybe we can share experiences instead ;)

              cheers
              /anders
            • Michael Poulin
              I think, it is not easy to read too many inclusions in the e-mail though inclusions provide for the context. So, I hope your interest in the the new and
              Message 6 of 13 , Feb 13, 2011
              • 0 Attachment
                I think, it is not easy to read too many inclusions in the e-mail though inclusions provide for the context.

                So, I hope your interest in the "the new and modern SO" may be satisfied to some degree by the OASIS SOA Reference Architecture Foundation to-be standard expected this spring (April-May). I tried to put there as many ideas of Steve Jones and mine as I could. OASIS SOA RAF states that the services exist and operate within a SOA ecosystem, and the quote I can give you now is:
                "
                1 Service Oriented Architecture (SOA) is an architectural paradigm that has gained
                3 significant attention within the information technology (IT) and business communities.
                4 The SOA ecosystem described in this document occupies the boundary between
                5 business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither
                6 business nor IT completely own, govern and manage this SOA ecosystem. Both sets of
                concerns must be accommodated for the SOA ecosystem to fulfill its purposes"

                Also, "the new and modern SOchanges the answer to WHAT question, not to HOW when we talk about services. For example, traditionally, if an application/module/component implements useful functionality, developers just put a Web Service interface on it and test how this interface reacts to the invocation. Nobody verifies whether the application code is thread-safe. When I say 'now, service is an application with a suitable interface, and I am, as a consumer, is interested in the business functionality and results provided by this application in respond to my multiple invocations' the developers have to recognise that I did not say anything about how to make this application reachable - via Web Services or not - but I was interested in the outcome of multiple requests. This will point the attention on the application operational behaviour and, among others, to issue of protection from the concurrent access will surface.

                B(u)y my book, flexibility (FLX) may be specified (it is not definition yet) as: 
                "max (FLX) = min { ∑(T2M+INV+IMP) where the T2M stands for time-to-market; the INV is how much the realisation of this change costs the organisation, and the IMP is the cost of adjustment of existing systems/solutions caused by realisation of this change"

                - Michael


                From: Anders W. Tell <anderst@...>
                To: service-orientated-architecture@yahoogroups.com
                Sent: Sun, February 13, 2011 11:06:13 AM
                Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                 


                On Feb 5, 2011, at 8:54 PM, Michael Poulin wrote:

                 

                Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

                Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and operational domains and is accepted by non-IT people and not defined by IT professionals?

                Im currently researching the topic of differences between the point-of-views of Non-IT and IT/engineering, so any new developments are of interest to know. One reason for this is that there seems to be a number of SO artifacts that Non-IT professional dont understand or really understand. Im interested in what can be improved.



                The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

                Now this is where you loose me. What are the chains of logic/causality from SO to "actual" flexibility and adoption to market changes? 
                Of course a flexible IT solution is supporting/contributing but there appears to be lots of aspects that influence a flexible organinsation and a contribution of an IT-part may drown in other influences.



                So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

                IT point-of-view: web services and REST. rather disinteresting from a Non-IT point-of-view.

                Delegation on the other hand is of interest, and access to (information) resources.



                When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple.

                Now we are on the same page. IT solutions is a performer of work or used as a tool for other performers.


                If you need an actual professional consultation, contact me via LinkedIn.

                Unfortunately Im one of those that give advice and do research, so maybe we can share experiences instead ;)

                cheers
                /anders

              • Steve Jones
                Oh boy, its hard to believe that in 2011 people are still not seeing SOA as a conceptual way of thinking about problems rather than as a bunch of web services.
                Message 7 of 13 , Feb 13, 2011
                • 0 Attachment
                  Oh boy, its hard to believe that in 2011 people are still not seeing SOA as a conceptual way of thinking about problems rather than as a bunch of web services.

                  The SOA RAF is looking great and I hope that people use it but I fear that we still live in an IT environment where people view implementation as being purely about lines of code and all "advances" in IT are based on an assumption of minimising typing.

                  Steve

                  On 13 February 2011 15:05, Michael Poulin <m3poulin@...> wrote:
                   

                  I think, it is not easy to read too many inclusions in the e-mail though inclusions provide for the context.

                  So, I hope your interest in the "the new and modern SO" may be satisfied to some degree by the OASIS SOA Reference Architecture Foundation to-be standard expected this spring (April-May). I tried to put there as many ideas of Steve Jones and mine as I could. OASIS SOA RAF states that the services exist and operate within a SOA ecosystem, and the quote I can give you now is:
                  "
                  1 Service Oriented Architecture (SOA) is an architectural paradigm that has gained
                  3 significant attention within the information technology (IT) and business communities.
                  4 The SOA ecosystem described in this document occupies the boundary between
                  5 business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither
                  6 business nor IT completely own, govern and manage this SOA ecosystem. Both sets of
                  concerns must be accommodated for the SOA ecosystem to fulfill its purposes"

                  Also, "the new and modern SOchanges the answer to WHAT question, not to HOW when we talk about services. For example, traditionally, if an application/module/component implements useful functionality, developers just put a Web Service interface on it and test how this interface reacts to the invocation. Nobody verifies whether the application code is thread-safe. When I say 'now, service is an application with a suitable interface, and I am, as a consumer, is interested in the business functionality and results provided by this application in respond to my multiple invocations' the developers have to recognise that I did not say anything about how to make this application reachable - via Web Services or not - but I was interested in the outcome of multiple requests. This will point the attention on the application operational behaviour and, among others, to issue of protection from the concurrent access will surface.

                  B(u)y my book, flexibility (FLX) may be specified (it is not definition yet) as: 
                  "max (FLX) = min { ∑(T2M+INV+IMP) where the T2M stands for time-to-market; the INV is how much the realisation of this change costs the organisation, and the IMP is the cost of adjustment of existing systems/solutions caused by realisation of this change"

                  - Michael

                  Sent: Sun, February 13, 2011 11:06:13 AM

                  Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                   


                  On Feb 5, 2011, at 8:54 PM, Michael Poulin wrote:

                   

                  Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

                  Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and operational domains and is accepted by non-IT people and not defined by IT professionals?

                  Im currently researching the topic of differences between the point-of-views of Non-IT and IT/engineering, so any new developments are of interest to know. One reason for this is that there seems to be a number of SO artifacts that Non-IT professional dont understand or really understand. Im interested in what can be improved.



                  The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

                  Now this is where you loose me. What are the chains of logic/causality from SO to "actual" flexibility and adoption to market changes? 
                  Of course a flexible IT solution is supporting/contributing but there appears to be lots of aspects that influence a flexible organinsation and a contribution of an IT-part may drown in other influences.



                  So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

                  IT point-of-view: web services and REST. rather disinteresting from a Non-IT point-of-view.

                  Delegation on the other hand is of interest, and access to (information) resources.



                  When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple.

                  Now we are on the same page. IT solutions is a performer of work or used as a tool for other performers.


                  If you need an actual professional consultation, contact me via LinkedIn.

                  Unfortunately Im one of those that give advice and do research, so maybe we can share experiences instead ;)

                  cheers
                  /anders


                • Michael Poulin
                  Steve, may I quote minimising typing ?! - Michael ________________________________ From: Steve Jones To:
                  Message 8 of 13 , Feb 13, 2011
                  • 0 Attachment
                    Steve, may I quote "minimising typing"?!
                    - Michael


                    From: Steve Jones <jones.steveg@...>
                    To: service-orientated-architecture@yahoogroups.com
                    Sent: Sun, February 13, 2011 7:23:13 PM
                    Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                     

                    Oh boy, its hard to believe that in 2011 people are still not seeing SOA as a conceptual way of thinking about problems rather than as a bunch of web services.


                    The SOA RAF is looking great and I hope that people use it but I fear that we still live in an IT environment where people view implementation as being purely about lines of code and all "advances" in IT are based on an assumption of minimising typing.

                    Steve

                    On 13 February 2011 15:05, Michael Poulin <m3poulin@...> wrote:
                     

                    I think, it is not easy to read too many inclusions in the e-mail though inclusions provide for the context.

                    So, I hope your interest in the "the new and modern SO" may be satisfied to some degree by the OASIS SOA Reference Architecture Foundation to-be standard expected this spring (April-May). I tried to put there as many ideas of Steve Jones and mine as I could. OASIS SOA RAF states that the services exist and operate within a SOA ecosystem, and the quote I can give you now is:
                    "
                    1 Service Oriented Architecture (SOA) is an architectural paradigm that has gained
                    3 significant attention within the information technology (IT) and business communities.
                    4 The SOA ecosystem described in this document occupies the boundary between
                    5 business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither
                    6 business nor IT completely own, govern and manage this SOA ecosystem. Both sets of
                    concerns must be accommodated for the SOA ecosystem to fulfill its purposes"

                    Also, "the new and modern SOchanges the answer to WHAT question, not to HOW when we talk about services. For example, traditionally, if an application/module/component implements useful functionality, developers just put a Web Service interface on it and test how this interface reacts to the invocation. Nobody verifies whether the application code is thread-safe. When I say 'now, service is an application with a suitable interface, and I am, as a consumer, is interested in the business functionality and results provided by this application in respond to my multiple invocations' the developers have to recognise that I did not say anything about how to make this application reachable - via Web Services or not - but I was interested in the outcome of multiple requests. This will point the attention on the application operational behaviour and, among others, to issue of protection from the concurrent access will surface.

                    B(u)y my book, flexibility (FLX) may be specified (it is not definition yet) as: 
                    "max (FLX) = min { ∑(T2M+INV+IMP) where the T2M stands for time-to-market; the INV is how much the realisation of this change costs the organisation, and the IMP is the cost of adjustment of existing systems/solutions caused by realisation of this change"

                    - Michael

                    Sent: Sun, February 13, 2011 11:06:13 AM

                    Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                     


                    On Feb 5, 2011, at 8:54 PM, Michael Poulin wrote:

                     

                    Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

                    Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and operational domains and is accepted by non-IT people and not defined by IT professionals?

                    Im currently researching the topic of differences between the point-of-views of Non-IT and IT/engineering, so any new developments are of interest to know. One reason for this is that there seems to be a number of SO artifacts that Non-IT professional dont understand or really understand. Im interested in what can be improved.



                    The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

                    Now this is where you loose me. What are the chains of logic/causality from SO to "actual" flexibility and adoption to market changes? 
                    Of course a flexible IT solution is supporting/contributing but there appears to be lots of aspects that influence a flexible organinsation and a contribution of an IT-part may drown in other influences.



                    So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

                    IT point-of-view: web services and REST. rather disinteresting from a Non-IT point-of-view.

                    Delegation on the other hand is of interest, and access to (information) resources.



                    When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple.

                    Now we are on the same page. IT solutions is a performer of work or used as a tool for other performers.


                    If you need an actual professional consultation, contact me via LinkedIn.

                    Unfortunately Im one of those that give advice and do research, so maybe we can share experiences instead ;)

                    cheers
                    /anders



                  • DOLATRAY BAGARIA
                    Steve you are 1000% right. I know one of leading cable industry s software developer co loose them contract you know who gain all benefits with development who
                    Message 9 of 13 , Feb 13, 2011
                    • 0 Attachment
                      Steve you are 1000% right.
                      I know one of leading cable industry's software developer co loose them contract
                      you know who gain all benefits with development who can point out previous one did the job development without Architecture they just first design right Artchitect done.That cable industry so happy withot asking anything once them work smooths paid more then next job developer.




                      From: Steve Jones <jones.steveg@...>
                      To: service-orientated-architecture@yahoogroups.com
                      Sent: Sun, February 13, 2011 2:23:13 PM
                      Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                       

                      Oh boy, its hard to believe that in 2011 people are still not seeing SOA as a conceptual way of thinking about problems rather than as a bunch of web services.


                      The SOA RAF is looking great and I hope that people use it but I fear that we still live in an IT environment where people view implementation as being purely about lines of code and all "advances" in IT are based on an assumption of minimising typing.

                      Steve

                      On 13 February 2011 15:05, Michael Poulin <m3poulin@...> wrote:
                       

                      I think, it is not easy to read too many inclusions in the e-mail though inclusions provide for the context.

                      So, I hope your interest in the "the new and modern SO" may be satisfied to some degree by the OASIS SOA Reference Architecture Foundation to-be standard expected this spring (April-May). I tried to put there as many ideas of Steve Jones and mine as I could. OASIS SOA RAF states that the services exist and operate within a SOA ecosystem, and the quote I can give you now is:
                      "
                      1 Service Oriented Architecture (SOA) is an architectural paradigm that has gained
                      3 significant attention within the information technology (IT) and business communities.
                      4 The SOA ecosystem described in this document occupies the boundary between
                      5 business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither
                      6 business nor IT completely own, govern and manage this SOA ecosystem. Both sets of
                      concerns must be accommodated for the SOA ecosystem to fulfill its purposes"

                      Also, "the new and modern SOchanges the answer to WHAT question, not to HOW when we talk about services. For example, traditionally, if an application/module/component implements useful functionality, developers just put a Web Service interface on it and test how this interface reacts to the invocation. Nobody verifies whether the application code is thread-safe. When I say 'now, service is an application with a suitable interface, and I am, as a consumer, is interested in the business functionality and results provided by this application in respond to my multiple invocations' the developers have to recognise that I did not say anything about how to make this application reachable - via Web Services or not - but I was interested in the outcome of multiple requests. This will point the attention on the application operational behaviour and, among others, to issue of protection from the concurrent access will surface.

                      B(u)y my book, flexibility (FLX) may be specified (it is not definition yet) as: 
                      "max (FLX) = min { ∑(T2M+INV+IMP) where the T2M stands for time-to-market; the INV is how much the realisation of this change costs the organisation, and the IMP is the cost of adjustment of existing systems/solutions caused by realisation of this change"

                      - Michael

                      Sent: Sun, February 13, 2011 11:06:13 AM

                      Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                       


                      On Feb 5, 2011, at 8:54 PM, Michael Poulin wrote:

                       

                      Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

                      Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and operational domains and is accepted by non-IT people and not defined by IT professionals?

                      Im currently researching the topic of differences between the point-of-views of Non-IT and IT/engineering, so any new developments are of interest to know. One reason for this is that there seems to be a number of SO artifacts that Non-IT professional dont understand or really understand. Im interested in what can be improved.



                      The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

                      Now this is where you loose me. What are the chains of logic/causality from SO to "actual" flexibility and adoption to market changes? 
                      Of course a flexible IT solution is supporting/contributing but there appears to be lots of aspects that influence a flexible organinsation and a contribution of an IT-part may drown in other influences.



                      So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

                      IT point-of-view: web services and REST. rather disinteresting from a Non-IT point-of-view.

                      Delegation on the other hand is of interest, and access to (information) resources.



                      When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple.

                      Now we are on the same page. IT solutions is a performer of work or used as a tool for other performers.


                      If you need an actual professional consultation, contact me via LinkedIn.

                      Unfortunately Im one of those that give advice and do research, so maybe we can share experiences instead ;)

                      cheers
                      /anders



                    • Masykur Marhendra
                      Yes, I also agree with that. Some people are still sees SOA as a system that have collection of services (usually as web services). This kind of understanding
                      Message 10 of 13 , Feb 14, 2011
                      • 0 Attachment
                        Yes, I also agree with that.
                        Some people are still sees SOA as a system that have collection of services (usually as web services). This kind of understanding that what I am trying to fix.

                        SOA is a conceptual solution; which will implemented specifically by vendors as a framework of solution. Hopefully, use the RAF as solution reference to get with.

                        Best Regards,

                        Masykur Marhendra S.


                        Sent from my BlackBerry® smartphone


                        From: Steve Jones <jones.steveg@...>
                        Sender: service-orientated-architecture@yahoogroups.com
                        Date: Sun, 13 Feb 2011 19:23:13 +0000
                        To: <service-orientated-architecture@yahoogroups.com>
                        ReplyTo: service-orientated-architecture@yahoogroups.com
                        Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                         

                        Oh boy, its hard to believe that in 2011 people are still not seeing SOA as a conceptual way of thinking about problems rather than as a bunch of web services.


                        The SOA RAF is looking great and I hope that people use it but I fear that we still live in an IT environment where people view implementation as being purely about lines of code and all "advances" in IT are based on an assumption of minimising typing.

                        Steve

                        On 13 February 2011 15:05, Michael Poulin <m3poulin@...> wrote:
                         

                        I think, it is not easy to read too many inclusions in the e-mail though inclusions provide for the context.

                        So, I hope your interest in the "the new and modern SO" may be satisfied to some degree by the OASIS SOA Reference Architecture Foundation to-be standard expected this spring (April-May). I tried to put there as many ideas of Steve Jones and mine as I could. OASIS SOA RAF states that the services exist and operate within a SOA ecosystem, and the quote I can give you now is:
                        "
                        1 Service Oriented Architecture (SOA) is an architectural paradigm that has gained
                        3 significant attention within the information technology (IT) and business communities.
                        4 The SOA ecosystem described in this document occupies the boundary between
                        5 business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither
                        6 business nor IT completely own, govern and manage this SOA ecosystem. Both sets of
                        concerns must be accommodated for the SOA ecosystem to fulfill its purposes"

                        Also, "the new and modern SOchanges the answer to WHAT question, not to HOW when we talk about services. For example, traditionally, if an application/module/component implements useful functionality, developers just put a Web Service interface on it and test how this interface reacts to the invocation. Nobody verifies whether the application code is thread-safe. When I say 'now, service is an application with a suitable interface, and I am, as a consumer, is interested in the business functionality and results provided by this application in respond to my multiple invocations' the developers have to recognise that I did not say anything about how to make this application reachable - via Web Services or not - but I was interested in the outcome of multiple requests. This will point the attention on the application operational behaviour and, among others, to issue of protection from the concurrent access will surface.

                        B(u)y my book, flexibility (FLX) may be specified (it is not definition yet) as: 
                        "max (FLX) = min { ∑(T2M+INV+IMP) where the T2M stands for time-to-market; the INV is how much the realisation of this change costs the organisation, and the IMP is the cost of adjustment of existing systems/solutions caused by realisation of this change"

                        - Michael

                        Sent: Sun, February 13, 2011 11:06:13 AM

                        Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture] Gabhart on Business-Driven Architecture

                         


                        On Feb 5, 2011, at 8:54 PM, Michael Poulin wrote:

                         

                        Anders, when I talk about SOA or the Concept of Service Orientation, I DO NOT mean IT or technical EA! This is the main point of difference between traditional IT and modern SO/SOA. 

                        Would be Interesting to see what has changed with the new and modern SO? Which parts comes from the economical, legal, accounting, sociological, policy and operational domains and is accepted by non-IT people and not defined by IT professionals?

                        Im currently researching the topic of differences between the point-of-views of Non-IT and IT/engineering, so any new developments are of interest to know. One reason for this is that there seems to be a number of SO artifacts that Non-IT professional dont understand or really understand. Im interested in what can be improved.



                        The letter is the Business concept, and the only business concept today that naturally includes flexibility and adoption to frequent market changes (widely used Value Chain, value streams and BPM are the left-overs of the steady production model where ANY changes are considered as risks to the quality of the final product). 

                        Now this is where you loose me. What are the chains of logic/causality from SO to "actual" flexibility and adoption to market changes? 
                        Of course a flexible IT solution is supporting/contributing but there appears to be lots of aspects that influence a flexible organinsation and a contribution of an IT-part may drown in other influences.



                        So, more frequently than not, "SOA" in IT is not service-oriented architecture at all but rather a traditional integration based on standardised interfaces (Web Services or REST). It is not a surprise that such "SOA" is "major reasons for halting the project": promises disconnected with capabilities.

                        IT point-of-view: web services and REST. rather disinteresting from a Non-IT point-of-view.

                        Delegation on the other hand is of interest, and access to (information) resources.



                        When you and your Business understand that what they do is the service to each other, they have to request the same style of relationships with IT - to serve, not support. Then IT become a service to them - bad service, we change the provider; that's simple.

                        Now we are on the same page. IT solutions is a performer of work or used as a tool for other performers.


                        If you need an actual professional consultation, contact me via LinkedIn.

                        Unfortunately Im one of those that give advice and do research, so maybe we can share experiences instead ;)

                        cheers
                        /anders


                      • Jason.Baragry@gmail.com
                        Is work still happening on the RAF? http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-cd-02.pdf I d like to think that I have a decent understanding of it.
                        Message 11 of 13 , Feb 15, 2011
                        • 0 Attachment
                          Is work still happening on the RAF?
                          http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-cd-02.pdf

                          I'd like to think that I have a decent understanding of it. But one problem I face is how to get that way of thinking out to others in my org - esp. those who aren't interested in the question, "what's the best way to codify all the aspects of service orientation?".

                          Is the oasis tc (or other) producing examples or templates that people can use as a starting point? I realise I can hand out the infoq book, but few people have time for books. They just want the simplest thing possible to get started. Examples and templates are a nice way to get started that can lead to discussion and converged understanding.

                          thanks
                          jason


                          --- In service-orientated-architecture@yahoogroups.com, "Masykur Marhendra" <masykur_sn@...> wrote:
                          >
                          > Yes, I also agree with that.
                          > Some people are still sees SOA as a system that have collection of services (usually as web services). This kind of understanding that what I am trying to fix.
                          >
                          > SOA is a conceptual solution; which will implemented specifically by vendors as a framework of solution. Hopefully, use the RAF as solution reference to get with.
                          >
                          > Best Regards,
                          >
                          > Masykur Marhendra S.
                          >
                          >
                          > Sent from my BlackBerry® smartphone
                          >
                          > -----Original Message-----
                          > From: Steve Jones <jones.steveg@...>
                          > Sender: service-orientated-architecture@yahoogroups.com
                          > Date: Sun, 13 Feb 2011 19:23:13
                          > To: <service-orientated-architecture@yahoogroups.com>
                          > Reply-To: service-orientated-architecture@yahoogroups.com
                          > Subject: Re: [service-orientated-architecture] Re: [enterprise-architecture]
                          > Gabhart on Business-Driven Architecture
                          >
                          > Oh boy, its hard to believe that in 2011 people are still not seeing SOA as
                          > a conceptual way of thinking about problems rather than as a bunch of web
                          > services.
                          >
                          > The SOA RAF is looking great and I hope that people use it but I fear that
                          > we still live in an IT environment where people view implementation as being
                          > purely about lines of code and all "advances" in IT are based on an
                          > assumption of minimising typing.
                          >
                          > Steve
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.