Added by karl.inge.roll, last edited by Thor Henning Hetland on Nov 24, 2008  (view change)

Labels:

publication publication Delete
featured featured Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

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

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

Comments  (Hide Comments)

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.
Posted by Johannes Brodwall at Sep 27, 2008 20:52

"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.

Posted by Thor Henning Hetland at Sep 28, 2008 13:36

"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!

Posted by Johannes Brodwall at Sep 28, 2008 13:31

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

Posted by Thor Henning Hetland at Sep 28, 2008 13:39

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?

Posted by Johannes Brodwall at Sep 28, 2008 13:49

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.
Posted by Thor Henning Hetland at Sep 28, 2008 13:54
View the rest of this thread. Most recent comment: Sep 28, 2008
2 more comments by: Thor Henning Hetland, Johannes Brodwall

Pushing SOA in the right direction?

Posted by Thor Henning Hetland at Sep 28, 2008 13:42

Priceless.

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

Posted by Johannes Brodwall at Sep 28, 2008 13:45