The Laws of SOA

Skip to end of metadata
Go to start of metadata

To succssfully implement a service oriented architecture you should:

1. Forget WS* and products
  • SOA is design and architecture. The WS-* standards is not much more than candidate technology for decorating your service endpoints...
2. Establish service categories and service universe.
  • Without defining/typing your services, you are building your SOA universe with simple blocks. We have different types of building blocks for building houses, why not in SOA..
    See SOA - Service Categorization
3. Find and decompose services
  • Focus on the responsibility aspect of your services.
  • Split and rule. Remember to satisfy both explicit and implicit consumer expectations.
4. Establish service ownership and Key Performance Indicators for your services
  • SOA is challenging on an organization, and as services should provida business value, its a dead giveaway to visualize this value in a graphical dashboard.
5. Establish design rules for your service categories up-front
  • Basically design-time governance...
6. Start limited and controlled
  • Start with a vertical, stay 100 % faithful to your architecture and design rules.
  • Use mocks/adapters when you have to take shortcuts.
7. Establish lean and agile deployment routines
  • Goal: from test to production-test, and from prod-test to production in less than 20 minutes.
  • his is a major change, which will take a lot of effort, but you have to plan for 10 times as many deployments, so there is really no option
8. Security is not optional in SOA
  • You basically need to pass a Security Token with each service invocation. On pre-invocation you do the normal access control, of post-invocation you need to filter the data-values (i.e. remove sensitive data if the security token does not have the right access. This is necessary, since we no longer have any single point of control, or trying to establish a single point of control will break the agility and time-to-marked values of your SOA.
9. Reflect and work strategically against SOA Maturity Model.
To be merged with content above

Intro

Service Oriented Architecture is all over us. And after several years with SOA we still have an extremely high rate of failure in SOA projects. SOA architects have no clue of what a service is, development leads spend all their time on making product workarounds, developers create silo services, and BPEL/BPM gurus use most of their time scrolling the enormous models, application management waste most of their time trying to restart parts of the SOA, and so on and so on...

This can not continue forever - there is a new sheriff in town! And this sheriff will shoot to kill.

In this presentation, the sheriff will introduce a set of SOA laws which, when followed, will guide your SOA effort from certain failure to the nirvana SOA promises and when ignored lead to certain death.

The laws...

0. Forget about focusing WS and products*

  • SOA is design and [architecture]. The WS-* standards and ESBs are not much more than candidate technology for decorating your service endpoints...

By this we mean that all SOA projects which focuses on the protocol (WS-) or the middleware (ESB) seldom have any success. If you on the other hand focuses of the atom of SOA, namely the services and how you build from these building blocks you are much more likely to have success. How the services collaborate can then happen in a myriad of ways. Both movable services (like in Jini/JavaSpaces) in-process services with a collaborating backbone, REST-endpoints and WS- endpoints all become a matter of deployment - and we usually have several endpoints with different protocols for each service.

1. Establish service categories and service universe

  • Without defining/typing your services, you are building your SOA universe with simple blocks. (We have different types of building blocks for building houses, why not in SOA..)

2. Find and decompose services

  • Focus on the responsibility aspect of your services. Divide and conquer. Remember to satisfy both explicit and implicit consumer expectations

3. Establish service ownership and Key Performance Indicators for your services

  • SOA is challenging on an organization, and as services should provide business value, it is a dead giveaway to visualize this value in a graphical dashboard.

4. Establish design rules for your service categories up-front

  • Basically design-time governance...
    • SOA Center of Excellence - [Policy Advisory Board]
    • Do not forget pre-production service QA

5. Start limited and controlled

  • Start with a business vertical, stay 100 % [faithful] to your architecture and design rules.
    • Use mocks/adapters when you have to take shortcuts

6. Establish lean and agile deployment routines

  • Goal: from test to production-test, and from prod-test to production in less than 20 minutes.
    • This is a major change, which will take a lot of effort, but you have to plan for 10 times as many deployments, so there is really no option

7. Versioning is not optional in SOA

  • See section for design rules for services and details about Evolving Service Endpoint pattern and strategies.

8. Security is not optional in SOA

  • You basically need to pass a Security Token with each service invocation. On pre-invocation you do the normal access control, of post-invocation you need to filter the data-values (i.e. remove sensitive data if the security token does not have the right access. This is necessary, since we no longer have any single point of control, or trying to establish a single point of control will break the agility and time-to-marked values of your SOA.

9. Reflect and work strategically against SOA Maturity Model.

Gartner humor - To the CIO, CEO, CFO, CTO and shareholders
As a result of the following I can now only deduce that SOA is a failure and any attempts at SOA will result in failure. Under my direction:
  • I have failed to associate our SOA initiatives with our business needs, therefore I cannot show any value for the hundreds of services we have created ,
  • I have failed to properly create and support an SOA Center of Excellence, Steering Committee or Competency Center,
  • I have failed to enlist the executive staff as true supporters and evangelists for our SOA efforts.
  • I chose to buy an ESB prior to truly understanding our SOA infrastructure needs (In reality this wasn't my fault, the vendor said it was super duper necessary)
  • I have failed to provide my developers incentives to reuse artifacts,
  • It was not my responsibility to follow what was going on next door where there was a separate team dealing with BPM, I mean they are two different initiatives,
  • I firmly believe that SOA is nothing more than fancy CORBA or COM.

Despite all of the things I have NOT done, SOA has failed. My additional failure to recognize and implement best practices that have been proven successful in many other companies worldwide also play into the failure of SOA.

Oh well, we should move on and try something new. On the bright side 70% of our initiatives fail anyway. The failure of SOA is SOA's fault not mine.

Thanks for understanding and I'd like to declare in advance that Cloud Computing, Virtualization and SaaS will be failures under my direction as well.

Quoted from: http://blogs.gartner.com/frank_kenney/2008/11/12/ahh-shucks-soa-is-a-failure/

As you can see, if you fail to follow the laws of SOA, you are getting yourself into trouble..

Terminology

[The laws of SOA FAQ]

Labels:
featured featured Delete
publication publication Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

10 Comments

comments.show.hide

  1. Sep 27, 2008

    Johannes Brodwall

    I like the fact that the list starts with "0". That'll keep the non-geeks away.

    Re: the points:

    • 0: Does this mean that you recommend against WS-, that you think different approaches should be used for different projects, or that you should use WS-, but this doesn't affect the design?
    • 0: WS-* can lead to function oriented services, while REST can lead to a resource oriented architecture (that is: pretty URL as a design heuristic). These are different approaches. Are both SOA?
    • 1, 2: Does this mean that you recommend small, fine grained services? Are these services usually distributed, or should they more often be local interfaces in the system? Should the "laws" say anything about this to make sure we're all on the same page re: what is a service?
    • I don't think I understand what's meant with 4 and 5 (I understand the words, but not what you want people to do and when)
    • I totally agree with 6 and 7. And I think I agree with 3, but an example of a KPI would be helpful. I think I agree with 8, but I don't understand what you mean by it yet.

    1. Sep 28, 2008

      Thor Henning Hetland

      "0: Does this mean that you recommend against WS-, that you think different approaches should be used for different projects, or that you should use WS-, but this doesn't affect the design?"

      By this we mean that all SOA projects which focuses on the protocol (WS-) or the middleware (ESB) seldom have any success. If you on the other hand focuses of the atom of SOA, namely the services and how you build from these building blocks you are much more likely to have success. How the services collaborate can then happen in a myriad of ways. Both movable services (like in Jini/JavaSpaces) in-process services with a collaborating backbone, REST-endpoints and WS- endpoints all become a matter of deployment - and we usually have several endpoints with different protocols for each service.

      "WS-* can lead to function oriented services, while REST can lead to a resource oriented architecture (that is: pretty URL as a design heuristic). These are different approaches. Are both SOA?"

      A SOA consists of resources (your data - ref EDR-MDS) and functions (executable processes), so the short answer is yes.

      "1, 2: Does this mean that you recommend small, fine grained services? Are these services usually distributed, or should they more often be local interfaces in the system? Should the "laws" say anything about this to make sure we're all on the same page re: what is a service?"

      Have a look at Service Manifest, and yes - the services have the same characteristics as all reusable code - they focus on a single responsibility. Services which tries to do too much, gets bloated with environment and start to expose the characteristics of both their clients and their implementation, and provide horrible service

      "I don't think I understand what's meant with 4 and 5 (I understand the words, but not what you want people to do and when)"

      Example design rules for services are linked, and might help you get an understanding

      "I think I agree with 3, but an example of a KPI would be helpful"

      For a CustomerRepository service, you might establish a set of data quality KPI. I.e. how many of the customers which have been updated within the last 3 months. The completeness of addresses, email and phone numbers on the customer base, the collaboration between organizational usage and ownership of a customer segment and the like. Technical KPI like response time, availability and the service SLA/contractual parts are also easily exposed and helps the organization to maximize the value of their SOA strategy.

      "I think I agree with 8, but I don't understand what you mean by it yet."

      You basically need to pass a Security Token with each service invocation. On pre-invocation you do the normal access control, of post-invocation you need to filter the data-values (i.e. remove sensitive data if the security token does not have the right access. This is necessary, since we no longer have any single point of control, or trying to establish a single point of control will break the agility and time-to-marked values of your SOA.

  2. Sep 28, 2008

    Johannes Brodwall

    "We have different types of building blocks for building houses, why not in SOA."

    Because a software system isn't a house?

    Physical construction uses many instances generic parts. In software, if you have one instance of a class or a million makes no difference to the construction cost. Software construction uses one instance of each of very specific parts. Having "a customer service" isn't enough. We need the correct customer service.

    Enterprise Address Book FTW!

    1. Sep 28, 2008

      Thor Henning Hetland

      If you look at service categories, you might get the picture we are talking about, or?

      1. Sep 28, 2008

        Johannes Brodwall

        I get the picture, but I'm not convinced that you're right. At least you house-building metaphor seems misguiding. Houses are mostly made out of wood and bricks, but is software mostly made out of services?

        Is my customer the same entity as your customer? Is my product list the same as your product list? In which situations?

        1. Sep 28, 2008

          Thor Henning Hetland

          A SOA need to support both models: i.e.

          • My customer is the same as your customer (except data-filtering might remove som sensitive info depending on the Security Token), but we typically have Context-Mapped Customer-entities which add/change some of the behaviour. This is done as aggregated core services, building on top of the CustomerRepoService (EDR or EDR-MDS) The core services are the repos, and are responsible for ID strategies and CRUD.

          1. Sep 28, 2008

            Johannes Brodwall

            To use an example from my own domain: Is a customer (payment card holder) the same as a customer (internet bank user), the same as a customer (card terminal owner), the same as a customer (entity we bill)? Or for that matter the same as a customer (phone company subscriber) if you're Grameen?

            I don't worry (much) about data mapping. I worry that we might be confusing together concepts that really aren't the same.

            I don't know how common this is outside my own experience, though.

            1. Sep 28, 2008

              Thor Henning Hetland

              "To use an example from my own domain: Is a customer (payment card holder) the same as a customer (internet bank user), the same as a customer (card terminal owner), the same as a customer (entity we bill)? Or for that matter the same as a customer (phone company subscriber) if you're Grameen?"

              Most companies define this as the same customer, with the same customerid. If the customer has the same id, it is the same entity/resource. The different clients to this resource might have a different view on the entity, i.e. which fields they consider interesting and such.

              On the other hand, some companies might define this as different entities, which results in it beeing different resources (most often for legal reasons), and then the different customers are 100% separated, even if they have the same state (except for the customer id)

  3. Sep 28, 2008

    Thor Henning Hetland

    Pushing SOA in the right direction?

    1. Sep 28, 2008

      Johannes Brodwall

      Priceless.

      That looks just like an ESB, doesn't it?