We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Why We Ran after bin Laden for So Long

user-pic
Vote 0 Votes

Security service as any another service consists of the business goal, business functionality, interfaces and body, i.e. implementation. As we know, business goal, business functionality, and interfaces are specified in the Service Description for the service consumers - if you are not a service developer, Service Description is for you.

Well, our practice shows that mentioned common perception about Service Description is not necessary correct. If service developers are driven by something else instead of specified goal/objectives, the service body may be not really about announced business functionality. This is the problem #1 with wrappers - they promise one thing but realise another one.

Our colleagues from the USA are very familiar with the security regulations aiming to screen customers against the lists of potential terrorists or Sanctions Lists. The UK has joined this movement and the UK FSA started to fine companies that had not implemented related screenings. Governments of several other countries such as Canada, Singapore, Australia and the whole EU have issued their own Sanctions Lists as well. So, what could be a better business case for the Sanctions Security service?

All right, dealing with services, we start with the service goal. Guess what service goals were set in the majority of cases: identify a potential terrorist (via Sanctions Lists) and stop any business with this person/organisation or satisfy local regulation? You are right, the service goal and related functionality were set in spirit of "provide the most effective systems and processes to avoid significant fines and severe reputational damage".

From the theory of Cluster Analysis it is known that to categorise an entity into several groups with minimal mistakes the grouping has to be done based on the most informative attributes of the entities (informative for particular grouping nature). This analysis is not a common knowledge but vendors of the screening engines reasonably suggested that the name of the entity is the thing to be screened against the Sanctions Lists. So, we have a sort of the service body - the screening engine. How about the interface?

The interface is simple - the name of entity has to be provided via manual or programmatic means. If this is so simple, why I am writing about it? Because, the entity name is a not enough informative attribute of its own, especially for matching to the Sanctions Lists from different countries, languages and alphabets. If the name would be used together with 'address', at least, this will be much more unique and informative combination but... typing an address is so boring, plus, it is another opportunity for typo and misspelling. Because of presented problems, the screening engines have to master an art of linguistic pattern recognition, which is not that easy. Probably because of this, the majority of the screening engines in the market have limited themselves to the name-only matching. The fact that 'false positive' matches were coming in thousands was handled in the same manner as the service itself - if too many 'false positive' matches appeared and the cost of investigation of each case was more than the business wanted to pay, the matching threshold was lifted to the level where only explicit matches surfaced. However, would you expect a terrorist to tell you, the merchant, his/her exact name to help you with an explicit matching? So, a matching or an absence of matching with Sanctions Lists means almost nothing but the service works hardly to... meet the regulation requirements.

How described implementation fits with the service goal of "avoid significant fines"? Perfectly! And does anybody but Marketing talk about "the policies and procedures used by the business to minimise the risk of the firm being used to further financial crime" any more?

We see that such important security service has been used and realised from the perspective of "solutions have to be simple". Einstein warned against not making things simpler than they needed but this part of his famous expression is unpopular. In reality, we have a service that follows user "convenience" requirements instead of business rational and we have a service body, which does some screening to show compliance rather than to secure us from the terrorists. Apparently, this is one of the causes why "UN confirms that bin Laden will remain on sanctions list" being deceased.

There are dozens of serious reasons why this all is happening but it is not a fault of SOA or service orientation. This is the fault of business/society management (sometimes the Sanctions List are issued without addresses but with people titles). Service orientation cannot help security if its framework does not set in the way that encourages business to cut the deals with potential terrorists; it is known that business people are used to the risks and the risk of being fined is just one of them. This is a classic example of an anti-pattern of service orientation.

In SOA ecosystem, we have to pay a lot of attention to WHAT we do and WHY we have to do it. You curious why we talk about SOA ecosystem suddenly, don't you? It is simple - the most of the things we do in our life are nothing else than serving others (and ourselves), i.e. the service orientation is our nature (not a technology or architectural methodology). Therefore, the only what we still have to do is to LEARN how to express our real goals and realise them via services. The services have to be as complex or simple as their goals or business/society needs are, not simpler.

IlearnfromBuTechCon.JPG

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more

Subscribe

 Subscribe in a reader

Recently Commented On

Categories

Monthly Archives

Blogs

ADVERTISEMENT