Coupling processes loose - a mess if not done right

Another great example how processes can sometimes be coupled in such a way that you can create a mess for the people in the process (tight coupling):

As posted in my previous post, I am using a chip-card for the Dutch Public Transport. This card acts as a travel pass and allows loading products onto it which act as tickets for public transport. More information can be found here.

One of the ways for travelling with the card is by loading credit products onto the card which act as a virtual wallet. You can do this manually, or you can load a product onto it which behaves in such a way that if your credit on the card drops below a certain threshold, it automatically does a debit transaction on your bank account and recharges the travel card. For this to work you need to purchase the product online and link it to the bank account of your choice.

I had almost activated the product on my card until I noticed the following phrase in the description of the product: "Always make sure sufficient money is in your bank account. If we cannot obtain the money from your account the card will be blocked. Unblocking the card can be done at a service desk."

Now here's the problem: two processes exist which are mixed incorrectly here:
- travel authorization
- debit transactions

Specifically the scenario when travelling with insufficient credit on the card and a low bank account balance causes issues: why would anyone want to block the entire travel card if I had insufficient balance?

There are a number of reasons why this is wrong and additionally there is one specific reason why this is fundamentally wrong:

- Travelling is registered/credit is consumed by checking in and out of the travel registration system by keeping the card close to a registration point (the card uses near-field-communication to communicate with the travel management system

- Insufficient credit for this travel does not mean that there is insufficient credit for all travel. It should be sufficient to deny check-in for this travel only.
- Insufficient bank balance still allows me to recharge the card from another bank account - so why block the entire card?

Fundamentally wrong:
- Many train stations and most bus stations do not have a service desk. To get to one I would need to travel!? Blocking the card does effectively restrict me from getting to a service desk.

What is documented here is an unnecessarily tight coupling between two distinctly different processes with distinctly different purposes. A better solution would have been to check at every check-in time anew whether or not I had to recharge the card. If the bank account balance was insufficient I would be denied that particular check-in.

Needless to say I did not activate that auto-recharge-card-credit-product on my card. You never know what happens and I do not intend to get stuck in the middle of nowhere just because an architect made a mistake (imho) by tightly coupling two disparate processes and by doing so shuts me down completely (travel-wise).

Wonder how long this situation will exist now that the government and the transportation companies are trying to get rid of the paper travel tickets...

- Roger

Transportation service compared to SOA service (over)specialization

Sometimes service over-specialization can truly hinder reuse in a sense that multiple implementations of similar logic are necessary to achieve the same functional goal for another purpose (agnostic).

I live in the Netherlands where recently an electronic public transportation ticket system was introduced to manage travel tickets electronically. A chip card with NFC is used to 'carry' digital tickets while travelling. You could see the travel pass as a digital purse in which you can keep single/return trips, monthly and yearly subscriptions as well as some money to use while travelling.

Now I'm new to this system and finally I decided to try the 'ticket recharged' way of travelling: the public transportation chip card instead of a paper ticket.

In order to be able to travel, I need to meet a number of preconditions:

1. I need a (personalized) travel card - this is the actual chip card with NFC communications

2. I need to put money on it

3. I need to activate "travel" on it with the appropriate transportation company.

Ad 1): I already had the card a little while, so I did not need to worry about it: precondition 1 is met.

Ad 2): For charging the card with money intended for travelling, a two-step approach must be followed:

a. Purchase travel credit - this would perform a direct debit on my bank account

b. Load the credit product onto the card

Ad 3): Similar two-step approach:

a. Order the "travel by virtual travel money" product with the dutch railway company

b. Load the product onto the card that allows using the credit on the card if available

Step 2a can be done via the public transportation chip card web site

Step 3a can be done via the dutch railways web site

So now I needed to find an NFC charging point so I found one of the terminals for public transportation at the train station.

Now here's the problem:

The machine to load products onto the card would only allow me to find the pending product for step 3a. This  means I can load the product to spend the virtual money with, but I cannot find the product that represents the virtual money I had ordered to spend in the first place.........?

So the "Load product" service on the terminal was only able to load travel products but no credit products. What was wrong with building a load "product"???

I ended up finding another machine outside the railway station to load the money product onto the chip card...

So I had to load products in two physically separate (and distant!) places...

Typical example of a non-agnostic service... :(

Published the Context Normalization Standardization pattern candidate

Hi all,

I just posted the pattern candidate for (Process) context normalization standardization.

If you have done this before and agree this is a good approach to solve cross-company process and technology alignment, please testify on the soapatterns.org web site using the candidate pattern feedback form.

Thanks,

Roger

Agnostic/non-agnostic revisited

I got the feedback that the previous article I wrote on what agnostic/non-agnostic is was too complex. So I am revisiting the subject to make sure that I explain a lot simpler than in the post I described last year.

To explain as easily as possible what agnostic/non-agnostic is:

• agnostic services are not aware of the context in which they are being called, nor are they aware of how the service is implemented, which platform, technology etc.
• non-agnostic services can have one or more forms of coupling or context (ie. process functional context).

Result of these two statements is that agnostic services have more reuse potential than non-agnostic services.

An example of the difference can be identified by discussing a "PrintInvoice" service capability.

This is a service capability which can be described as the logic exposed to print an invoice. When trying to classify the service it is pretty obvious that this is a non-agnostic service, as it has capabilities to print invoices and nothing else.

When applying the principles of service design, we should give a service a defined logical (functional) boundary, which defines the context in which the service operates.

When redesigning the implementation of this service, we could split the service into two services:

• Print
• Invoice

These are two agnostic services: print service capabilities are bothered with the capability to print "stuff" and Invoice service capabilities deal with invoice related "stuff".

Having made this separation, I just lost my capability to print invoices. To resolve this problem I can create a third service which combines the two services in one service capability which can deal with the mechanics of printing invoices, which results in the following service-inventory:

As you can see the agnostic services are being composed by the non-agnostic PrintInvoice service. This allows for the invoice and the print service to be used for other purposes, of which I have depicted a few potential examples below:

As we can see, it's the agnostic services which are being reused, not the non-agnostic services.

If this separation of concerns would not have been applied, instead of ie. reusing the print functionality, for the printletter functionality, the printing part would have been redeveloped and tailored for the printing of letters. This would have created some unnecessary/redundant/duplicate logic.

The current PrintService would take any range of different document types that it would support. This would greatly enhance the reusability of the agnostic print service.

Published Rule Layers candidate pattern

Hi all,

I just published the Rule Layers candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out here at soapatterns.org.

- Roger

Published Rules Normalization candidate pattern

Hi all,

I just published the Rules Normalization candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out here at soapatterns.org.

- Roger

Make sure it's not too CLOUDy...

This post addresses some of the concerns that companies might have when dealing with cloud services in general, specifically when dealing with sensitive data in a hosted environment. Where cloud computing in intended to increase the quality of service, the quality of "privacy" is not a generally recognized factor when services are hosted. The environment naturally protects its applications because that's what the hosting environments provide.

With cloud computing, the deal changes with respect to traditional hosted services in ie. a colocated hosting environment for which you know where it is hosted. When services are hosted in a cloud, ie. the service's storage resource is hosted in redundant locations, you can not be sure with a (public) cloud where a service or its resources are hosted. In fact, some of the more innovative cloud service providers have dynamically hosted resources in 'cooler' locations on the planet to save cost by requiring less power for cooling. This means that the services are hosted across multiple continents and in many countries, which naturally leads to the conclusion: what happens with my customer data, what happens with my client data?

Businesses or governments storing data in a cloud may inherently be exposing the data into countries which have different privacy policies or legislation than required for their purpose. For example, if data of a European company is stored outside the European Union, which means that data of customers may not be protected by the privacy laws of Europe.

In the example, a cloud consumer should stick to cloud providers for which he knows the privacy policy, and for which the hosting environments are only located in Europe. Alternatively a cloud consumer should build a private cloud or use a community cloud which has controlled access.

Similar approaches apply for different reasons and for different countries, but the essence stays the same: make sure it's not too cloudy...

Core service logic and auxiliary service logic

Here's a nice scenario I have encountered recently:

Customer management wants every activity performed by a customer and every customer contact logged in the customer data store.

For this purpose, every relevant service and process in the service inventory is fitted with auxiliary logic to create customer logs in the CRM system.

Historically, this has worked for several years, but recently the system administrators started complaining about the sheer amount of data in the system and how it is becoming very hard to keep the system displaying these logs to the CM agent without running expensive (long-running) queries.

To cut a long story short, they want to reduce the amount of data logged for a customer by creating a new policy which only logs significant activities on a customer record.

For this to work, the initial request was to remove the logging logic from certain service capabilities.

In the service inventory, a whole bunch of services has, besides the relevant core service logic, some hard coded auxiliary CRM logging logic which will use a utility service to push the logged data to the CRM system.

As it is impacting many different services which are used in different contexts, removing the auxiliary logic as requested may not be the best way to go about this. Not only does this cost a lot of effort and regression testing, but also does it not solve the issue that the same service should log to the CRM system in one context, but not in another.

An alternative, perhaps more flexible way of changing the system's logging logic, is to change the utility service or apply a policy to this service which acts as a filter, deciding for all services whether or not to execute the actual CRM system update.

This means that the logging logic can still stay in the services as auxiliary logic, and the decision whether or not to perform the actual update will happen in the CRM system can be managed (declaratively), external to the core service logic of the services needing the logging, and external to the actual logging service itself.

This can work only if the context of the service call is also recorded with the logging message.

An alternative to this approach can be that all services log messages to the CRM system per default, but publish the message into a queue or topic and selectively process messages based on business rules in a business rules engine or similar.

SOA Pattern Publishing - why?!

Hi all,

Recently I have been posting a lot of candidate patterns on soapatterns.org, the pattern-related site of soasystems.com.

I was a matter of time before someone might ask "what are you doing and why are you doing it?". Well, it happened. Anyway, the reason why I wrote this post is because people ask why use soa patterns, why document soa patterns and there's only one simple reason for me doing this.

SOA patterns are proven solutions for common problems. Some of the candidate patterns I have documented may seem like open doors or a shot at an empty goal - but that's a good thing actually. What it means is that people recognize a certain solution for a problem, to actually be a good or at least a viable solution. And if people recognize the structure of the solution, does that not mean that they have just recognized a pattern in what they are seeing?

SOA patterns are not rocket science. SOA patterns are not smart or unique solutions. They are merely a common way of fixing a problem that we've encountered more than just once.

Does that mean it should not be documented? I don't think so. By documenting it, I hope to save other people's time and effort; because if someone recognized a documented soa pattern as something that can be applied to their problem, with or without modifications, that particular goal is reached.

Why am I publishing candidate patterns and not patterns? Well, it's in the definition of the soa pattern. For it to be a pattern it must be proven - as in - used in the field by more than one person. A site like soapatterns.org manages exactly that. This is also why I'm asking with every candidate pattern published by myself, to get others to testify that they have used the same pattern or a similar approach for real too. Because only if a group of people would testify they use it, it can be considered a pattern instead of a candidate pattern.

Keep watching this blog for a couple of more patterns to come. Presently finalizing patterns on rules normalization and rule layers and a couple of more service inventory related patterns. And if you've done something similar to what's described in one of my pattern candidates - or any others in the list - be sure to let the people at soapatterns.org know that you did. This way you, the community, can contribute to the field.

Regards,

-Roger

Published Reference Data Distribution candidate pattern

Hi all,

I just published the Reference Data Distribution candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out here at soapatterns.org.

- Roger