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...
- SOA Center of Excellence - Policy Advisory Board
- Do not forget pre-production service QA.
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*
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
2. Find and decompose services
3. Establish service ownership and Key Performance Indicators for your services
4. Establish design rules for your service categories up-front
5. Start limited and controlled
6. Establish lean and agile deployment routines
7. Versioning is not optional in SOA
8. Security is not optional in SOA
9. Reflect and work strategically against SOA Maturity Model.
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] |
10 Comments
comments.show.hideSep 27, 2008
Johannes Brodwall
I like the fact that the list starts with "0". That'll keep the non-geeks away.
Re: the points:
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.
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!
Sep 28, 2008
Thor Henning Hetland
If you look at service categories, you might get the picture we are talking about, or?
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?
Sep 28, 2008
Thor Henning Hetland
A SOA need to support both models: i.e.
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.
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)
Sep 28, 2008
Thor Henning Hetland
Pushing SOA in the right direction?
Sep 28, 2008
Johannes Brodwall
Priceless.
That looks just like an ESB, doesn't it?