Back in 2006 I wrote a bunch of SOA Anti-patterns, with some additional help, and these are pretty much as valid then as now. I'd like to add a new one though that I've seen over and over again its related to the canonical model problem and its pretty easy to solve.
Name: Sharing Data like candy
Description
This anti-pattern comes from a desire to 'share' all the information between areas but instead ends up creating strong dependencies between areas because core information sets, for instance customers, products, locations, etc are thrown about all the time and need to be 'matched' across systems during the transactions. The information description for these core entities grows continually as different services want 'just one more field' in order to enable other services to get 'everything'.
Effect
The impact of this approach is simple, the schemas for the core entities aim to be 'complete' so all information from every services can be placed within these, this is stated that it aids 'sharing' but the reality is that as new attributes are added, or sub-entities, that different areas of the business begin to add the same attributes in different places and the testing impact of change becomes a significant issue as these core information sets are used in every single interaction. Services take to storing information from these interactions 'just in case' which leads to significant challenges of data duplication. The solution degrades into a 'fragile base class' issue and modifying the information model becomes a high ceremony, high impact, change. Development becomes slow, people look for 'back doors' to avoid using corporate approaches and local point solutions begin to proliferate.
Cause
The cause is simple, a failure to recognise what the purpose of the interaction is. If service A and service B both have information on customer X, with them being known as "fred bloggs, ID:123" by service A and in service B as "mr fredrick bloggs, ID:ABC" then passing 40 attributes about the customer is just designed to create confusion. It doesn't matter if Sales and Finance have different information about a customer as long as they have the information that is right for their interaction with them. Sharing all this information makes communication worse if its done in an unmanaged way. The problem here is that management of these core entities is a task in itself while the SOA effort has viewed them as being just another set of data entities to be flung around. The cause is also due to the SOA effort viewing everything as a transactional interaction and not thinking about the information lifecycle.
Resolution
What we need is the ability to exchange the mapping from service A to service B's ID and only the information which is specific to the transaction. This means that we need a central place which maps the IDs from one service to another and ensures that these represent a single valid individual, product, location, etc. This is the job of Master Data Management and it comes with a big set of business governance requirements. This approach has an added benefit of being able to synchronise the information between systems so people don't see different versions of the same data attributes and being able to extract information out of source systems to provide a single, transactional, source.
The resolution therefore is to agree as a business that these core entities are important and to start managing them, this reduces the complexity of the SOA environment, increases its flexibility and agility as well as removing issues of data duplication.
Name: Sharing Data like candy
Description
This anti-pattern comes from a desire to 'share' all the information between areas but instead ends up creating strong dependencies between areas because core information sets, for instance customers, products, locations, etc are thrown about all the time and need to be 'matched' across systems during the transactions. The information description for these core entities grows continually as different services want 'just one more field' in order to enable other services to get 'everything'.
Effect
The impact of this approach is simple, the schemas for the core entities aim to be 'complete' so all information from every services can be placed within these, this is stated that it aids 'sharing' but the reality is that as new attributes are added, or sub-entities, that different areas of the business begin to add the same attributes in different places and the testing impact of change becomes a significant issue as these core information sets are used in every single interaction. Services take to storing information from these interactions 'just in case' which leads to significant challenges of data duplication. The solution degrades into a 'fragile base class' issue and modifying the information model becomes a high ceremony, high impact, change. Development becomes slow, people look for 'back doors' to avoid using corporate approaches and local point solutions begin to proliferate.
Cause
The cause is simple, a failure to recognise what the purpose of the interaction is. If service A and service B both have information on customer X, with them being known as "fred bloggs, ID:123" by service A and in service B as "mr fredrick bloggs, ID:ABC" then passing 40 attributes about the customer is just designed to create confusion. It doesn't matter if Sales and Finance have different information about a customer as long as they have the information that is right for their interaction with them. Sharing all this information makes communication worse if its done in an unmanaged way. The problem here is that management of these core entities is a task in itself while the SOA effort has viewed them as being just another set of data entities to be flung around. The cause is also due to the SOA effort viewing everything as a transactional interaction and not thinking about the information lifecycle.
Resolution
What we need is the ability to exchange the mapping from service A to service B's ID and only the information which is specific to the transaction. This means that we need a central place which maps the IDs from one service to another and ensures that these represent a single valid individual, product, location, etc. This is the job of Master Data Management and it comes with a big set of business governance requirements. This approach has an added benefit of being able to synchronise the information between systems so people don't see different versions of the same data attributes and being able to extract information out of source systems to provide a single, transactional, source.
The resolution therefore is to agree as a business that these core entities are important and to start managing them, this reduces the complexity of the SOA environment, increases its flexibility and agility as well as removing issues of data duplication.
No comments:
Post a Comment