Inter Service Dependency Model

In any SOA ecosystem, there are bound to be numerous services. Some of the services in will be core services which will be used by most of the services. If this interdependency is not maintained, it may result in spaghettiof services. To have an ordered SOA architecture, one must rely on proven layered architecture which ensures robustness and independence of non adjacent layers.

To measure inter dependence of services, I have developed a simple but effective model, which I call Inter Service Dependency Model. This model is inspired by DSM (Design Structured Matrix.

In this model, services are viewed from provider and consumer perspective and emphasis is on maintaining layered based architecture principles in SOA ecosystem.



The matrix is divided into three distinct areas. The Solid BLACK region is the demarcation between RED and GREEN. One should fill value in GREEN and RED region cells to illustrate inter dependency of services. This dependency strength generically can be defined as



In a well designed SOA eco system following conditions should exist:

1. Matrix is populated only with Zero and Positive numbers
2. RED region is populated with Zero
3. Black region must not be populated ( pretty obvious)
4. GREEN region should be populated with positive numbers.

Above mentioned conditions still not address adjacent layer dependency only. To address that one should be able to figure out structure of GREENs and may also club services into layers.

Reference:

1. http://www.dsmweb.org/
2. http://ausweb.scu.edu.au/aw08/papers/edited/mehboob/paper.html
3. http://www.stsc.hill.af.mil/crosstalk/2005/11/0511SangalWaldman.html
4. http://www.lattix.com/technology/whatisdsm.php
5. http://en.wikipedia.org/wiki/Dependency_Structure_Matrix

Composite Services Complexity Measure

While evaluating a service complexity, I developed few of the measure. One of the measures is Complexity Measure which considers depth of service or we can say composition depth of service.

For this measure composite services were divided into four types:

1. Sequential Composite Services
2. Co-ordination Composite Services
3. Recursive Composite Services
4. Complex Composite Service



So Complexity Measure for:

Sequential Composite Service:

Composite Service Depth, CSD = Distance to the farthest service in sequence

Co-ordination Composite Service:

Composite Service Depth, CSD = Arm Count

Recursive Composite Service:

Composite Service Depth, CSD = (Optimistic recursion count + Pessimist recursion count)/2

Complex Composite Service:

Composite Service Depth, CSD = Sum of (Composite Service Depth in terms of Sequential, Recursion and Co-ordination manner)

For a good implementation CSD should not be more than 3 to 5. But in reality, most of the time consumer of a service is not aware of complete service tree.

Recursive composite service must be avoided.

As a good practice, each service should publish its CSD count.

Process Catalogue Template

Few posts back I have published a process template. In continuation here is now Template for process catalogue. Use it as you wish. Also let me know any changes you require.

Get this doc from:

Software Production

Recently I was at conference by leading software service provider from USA. Service provider making claims that they have developed a methodology which converts development of software is like any product in a factory. Before critical assessment of this claim let us see how production is carried out is a real factory.

In today’s world there are two dominant production methodologies:

1. Stationary Platform methodology
2. Assembly Line methodology

Stationary platform methodology is used only in highly complex and huge products like airplanes, space shuttle, etc.



Assembly line methodology is widely used and approximate covers all type of products – automobiles, household appliances, etc.



Stationary platform methodology also takes advantage of Assembly Line methodology via manufacturing of components in assembly line and then assembling on a stationary platform.

There is also third methodology which is followed by craftsmen, fabricators, highly customized goods, etc. I called it Craftsmen Approach.

Now come to software development. What approach does today’s software industry follows? My reasoning says Craftsmen Approach. In software industry we have lot of automation and sophisticated tools but still they just assist in fasten the process and managing the complexity of product (which is software). These tools do not bring any paradigm change in software development methodology. These tools are like replacing manual chisel and hammer by electrical driven tool set.

If you see both pictorial representations of Stationary and Assembly line methodologies, process is preexisting. It just gets applied during manufacturing. But software development results in formalization of process itself which has to be very flexible so that it can be changed in future if need arises. Also every production cycle of software results in unique product. This very similar to unique end product created by craft man.

Thirdly Assembly Line Methodology is good for mass production. Do we do mass production in Software development?

So do we still in pre industrialization phase viz a viz software development or software development will always be crafts man domain till machine intelligence is capable enough for creativity and innovation?

Process Design

In most of the cases BPM deals with existing process where process designer picks up the existing process, optimize it as per the given mandate and finish off his/her work. Does this expose him/her to best practices of process design?

So the steps of process design are:

1. Concept: The Idea  what do you want to do?
2. Form: The Process  The process and the result of process(product)
3. Content: The Meaning  Does form satisfies the concept?

In a well designed process cater to following class of changes:

1. Change in State: Transition to one state to another during the course of execution of process. For example in Quote to Cash process change in state of Quote to Order.
2. Internal Changes: Changes in other processes which are within the realm of enterprise/s to whom process is catering. For example change in price of an item while a Quote to Cash process is in middle of execution. Price change is another process.
3. Environmental Changes: These changes are most of time beyond control of participating enterprises. For example change in tax structure while a Quote to Cash process is in middle of execution.

In any process Class 1 changes are accounted for because they form the normal exertion path of a process. Class 2 changes are also accounted in most of well designed process either as Class 1 changes or exceptions or via versioning path. Class 3 changes are not taken care in most of the process design due to resultant complexity and thin chances of occurrence of these changes. Class 3 changes can be accounted either as Exception, using versioning or catastrophe. If Class 3 changes are not accounted in process design this may result in chaos.

To design a process following models can be used by various players of game.

1. Value Stream Mapping: This mapping technique is widely used by Six Sigma and Lean professionals.
2. Event Modeling: This technique is widely used by Process Reengineering professionals.
3. Object Modeling: This technique is widely used by software professionals to model software as real life objects. For details you can refer to OOPS and OOAD literature.
4. Data Modeling: This is one more technique which is widely used by software professionals to design data intensive software.
5. Process Interaction Model: This is the models which caters to intra and inter process interaction. This model is borrowing concepts from Control engineering and ARIS methodology. This model is under development and soon I will release more details about it.

Business and System Analysts use Value Stream Mapping, Event and Process Interaction Models to define, refine and model a process. Technical Architects and Designers use Object Model, Data and Process Interaction Models to come out with technical specifications and actual design.

Process Design Good Practices

1. Design for present but do not loose sight from future.
2. Take account of Class 1 events and Class 2 events.
3. Manage Class 3 events keeping complexity in full view.
4. Balance between automation and manual tasks to keep process simple.
5. Strive for perfection but watch out for complexity, so balance.

Reference
1. http://en.wikipedia.org/wiki/Value_Stream_Mapping
2. http://www.isixsigma.com/dictionary/Value_Stream_Mapping-413.htm
3. http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
4. http://www.ooad.org/
5. http://en.wikipedia.org/wiki/Data_flow_diagram
6. http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
7. http://en.wikipedia.org/wiki/Dataflow
8. http://en.wikipedia.org/wiki/Event_model
9. http://msdn.microsoft.com/en-us/library/ms533023(VS.85).aspx
10. http://www.actiontech.com/BPM/BIM.cfm
11. http://process-interaction-models.info/

Book Review: SOA Cookbook: Design Recipes for Building Better SOA Processes by Michael Harvey

ISBN #: 978-1-847195-48-7

SOA Cookbook may be considered one of the few books in SOA world which talk SOA as Process and further the argument with support of real life SOA platforms from leading vendors, namely IBM, Oracle, BEA and TIBCO.

SOA Cookbook is divided into nine chapters which encompass preliminary as well as complex aspects of SOA in seamless fashion. This book exposes architects and designers various aspects of SOA and BPM like Orchestration, Choreography, Event Handling, Change Management and services and processes, etc. It is advisable to understand basics of BPEL before hand. Chapter 4 onward, BPEL plays major role in understanding of the book.

With its entire good things book leaves some loopholes to be covered, like distinction between BPM and workflow, usage of B2B in inter enterprise integration, difference in EAI and process integration, etc.

This book is must in any software architects’ book collection to keep reminding basics of SOA and its practical implementations.

SOA Cook book is available here.

Book certainly gives lot of pointers for new thoughts.

Orchestration & Choreography

I generally encounter discussions and questions from various Architects, Designers and Business Persons discussing Orchestration and Choreography. It seems to me that these two topics hotly debated and misunderstood in the context of SOA. I also want to add my voice to the noise.

I understand Orchestration and Choreography from their dictionary meanings.

Orchestration:

1. Noun: To arrange something carefully, and sometimes unfairly, so as to achieve a desired result (Cambridge Advanced Learner's Dictionary)

2. Noun: The arrangement of a musical composition for performance by an orchestra; also: orchestral treatment of a musical composition (Merriam-webster’s online dictionary)

Orchestration Examples:

1. In a concert conductor is giving instructions to players of violin, piano and other instruments to modulate pitch and volume to create music. Conductor is essentially passing instructions at the time of actual performance.
2. A road crossing at which vehicles are following traffic rules in the presence of traffic police personnel. In real time depending upon traffic flow in different directions, traffic policeman takes action and ensures smooth flow of traffic.

In both the cases there is a central body which controls the performance of participants (performers and vehicles) for successful execution of a task

Choreography:

1. Noun: the skill of combining movements into dances to be performed (Cambridge Advanced Learner's Dictionary)
2. Noun: the composition and arrangement of dances especially for ballet (Merriam-webster’s online dictionary)

Choreography Examples:

1. Sandeep Soparkar choreographed a dance sequence Britney Spears stage performance. In this scenario Sandeep has defined every step of dance well ahead of the performance so Britney and her stage co-performers are just enacting the same.
2. A road crossing at which vehicles are following traffic rules without presence of traffic light or traffic police. These rules are defined in advance. Each vehicle is just following them for smoother and safer movement.

In both cases the participants (performers and vehicles) are following some predefined rules for successful staging of drama.

In SOA context, I will carry forward the argument and define the Orchestration and Choreography on same lines.

Orchestration:

1. It is done at run time.
2. There must be some central body, which controls the flow of the message and behavior of each participating service. This central body may be logical entity or set of rules/protocol.

Participating services are not aware of each other and even they are not aware of their involvement in orchestration.

Choreography:

1. It is done at design time
2. There is no logical entity to control the behavior of participating services but a set of rules/protocol exists which controls interaction of services.
3. Participating services are aware of each other and know when to execute their operations



So, how in real life Orchestration and Choreography played out in SOA universe.

In real life SOA implementation of services are done in the form of small business processes, which are state aware. In these processes services remain stateless but not the whole process. Individual services are not aware of their involvement in any process. This is the case for Orchestration. The central hub/rules/protocol decides how different services will interact. Most of the routing is content aware and depends upon result of execution of participating services.

Choreography can be thought of integration of small business processes, which are directly made up of services. The resultant grand business process might involve workflow. So in this grand process smaller constituent business process need not to expose all of its functionality beyond boundaries of itself. Small business processes have some private functionality and some of publicly exposed. Publicly exposed functionalities are exploited to integrate them and reach at grand business process where no central hub is defined so no run time decision. All decisions have been made at design time.