Requirements Landfill - the challenge of central services

Enterprise Services of any type from Business Services like procurement through to technical infrastructure services such as Identity management are all at risk from a threat of pollution. I call this threat the requirements landfill.

One of the key principles of SOA in operation has been the ability to have services which are used across the enterprise. These single services represent a single point of truth and a single functional boundary that ensures enterprise consistency, it is their goal to shift away from fragmented sytems towards Services which represent the single way of accomplishing a technical or business objective.

This is great and good but I've been seeing something more and more over the past few years. Its that these enterprise class services, particuarly when successful, suffer from being the easy place to add new requirements rather than always being the right place to add those requirements. The basic problem is simple

These services sit at the junction between multiple elements, some are nice new service programmes, some are hacky service programmes, some are old legacy systems and others are just systems owned by people who don't have much budget or are rather grumpy.

So what happens is that you get a big and complex requirement. About 50% of this requirement really does belong in the central service but the other 50% is a combination of elements

1. 20% requirements that should be done in the originating systems
2. 20% requirements that are around data storage and access that should be in another system
3. 10% requirements related to business process that are completely beyond the scope of the central service

Now the problem is that to implement this new set of requirements therefore requires a much broader set of changes if it is to be done properly. Initially the discussions might start out talking about doing it the right way but then someone will say the immortal line

It would be easier if we just put all of this is the enterprise service

While the enterprise service team will scream at the prospect this will make perfect sense to everyone else as they won't be doing the work. Unless there is a set of concrete governance processes around then the normal "democratic" decision process will result in the compromise decision being made. The first time this gets done its seen as a compromise that just had to be made. The second time onwards its just replicating the same approach as that is what we normally do. Rapidly therefore the enterprise service goes from being a single clearly defined entity with a defined business purpose to being the requirements landfill for all those requirements that people are either too lazy or too scared to try and do properly. This leads to the service getting ever slower to react to change and eventually being seen as a failure due to its transformation from a business service into a traditional old style application.

The point here is that governance and escalation are essential to maintain a clear set of enterprise wide services and to ensure that requirements are not simply dumped into areas due to them having budget, talented people or just because they are at a central point.

Most of the time I see requirements landfills its because IT owns and manages the services and thus they have no direct link to a specific business owner. This means that business people don't care about keeping them clean as it isn't their problem. One of the first steps in a solution therefore is to ensure that your enterprise services are clearly aligned to the business areas where they matter and thus ensure that they have an in-built desire to keep the services aligned to their area and not blurred across technical and organisational boundaries.

Favourites for requirements landfills are also centrally provisioned IT "enabling" solutions such as ESBs which almost stand up to the business and say "dump crap here and then point the finger of blame here when it goes wrong".

So have you got a decent policy to prevent requirements dumping? Do you have a refactoring and recycling programme to take dumped requirements out of the landfill and put them back where they should be? Or are you just hoping that you'll be able to convince people that its not your fault that you allowed the illegal dumping?

Technorati Tags: SOA, Service Architecture