The Nerd, The Suit and the Fortune Teller
I am currently being entertained by the nerd (Clemens Vasters), the suit (Rafal Lukawiecki) and the fortune teller (Pat Helland) on the last day of TechEd Europe. Fortune teller is reconciling nerd and suit by promoting service orientation as the thing that will bring business and IT together. Services represent aspects of the business, that decouple concerns at the technical level in line with how they have been separated at the business level.
The question that fortune teller has not answered is HOW we will decompose the business into maximally independent aspects? What are the rules of thumb to be used when analysing the business? During this conference there are some (Steve Cook, Pat Helland) who hint to people/business actors, their commitments to each other and conversations to reach these commitments as first-order concepts needed to start understanding (and model) business and the automated services that support the business. This is very much in line with my thinking, which has strongly been influenced by DEMO.
My advise would be to first determining the roles that are played by people in a business (using communication patterns). As a next step you can define a (candidate) service for each of the identified roles. Each service performs activities that are the responsibility of the people in this role but can be delegated to software.
The question that fortune teller has not answered is HOW we will decompose the business into maximally independent aspects? What are the rules of thumb to be used when analysing the business? During this conference there are some (Steve Cook, Pat Helland) who hint to people/business actors, their commitments to each other and conversations to reach these commitments as first-order concepts needed to start understanding (and model) business and the automated services that support the business. This is very much in line with my thinking, which has strongly been influenced by DEMO.
My advise would be to first determining the roles that are played by people in a business (using communication patterns). As a next step you can define a (candidate) service for each of the identified roles. Each service performs activities that are the responsibility of the people in this role but can be delegated to software.
1 Comments:
Hi Gerke,
I think the work you have been doing on comms patterns for identifying services is extremely important. DEMO is on my reading list because there is a serious dearth of information on how to do this. We should build an exemplar SO system using those ideas and write about it. And I can help do the evangelizing for you! :-)
One other thing that intrigues me is how comms patterns might relate to module maps? Do you have an idea?
- Arvindra Sehmi
Post a Comment
<< Home