Thursday, November 01, 2007

How to create customised Business Services on a package

Having said Change the Business not the Package, something I will stick by, there is the problem of what if that package only implements part of a business service? What if you have legislative elements that need to be done or local policies that need to be enforced? What if you need to add in Decision Support? Now the first thing to do if you think this is

STOP

Seriously, right now. Are you really sure that this is special to your business? Because the odds are that what you are really doing is just adding in some customisation for the hell of it. Can you change your business to fit the way the package works?


Now lets assume that you actually do have a good reason to have some differentiation in this area, how do you add in customisation? The answer isn't rocket science its simply
  • Treat the package as an integration point
  • Put customisation in.... a CUSTOM application
This is why SAP has Netweaver and Oracle has Fusion Middleware (I'm still surprised SAP aren't going after BEA) and of course why lots of other integration and middleware stacks exist.

So what you look to do therefore is to use the interfaces that exist on the package as the integration points for these new customised applications. A basic rule of thumb is always use mediation when communicating with the package, or between different services. Another good idea is to think of the business services that are exposed to the enterprise as not always being straight one-to-one mappings to those definitions from the package. This might be due to data schemas but most normally will be because the package has lots of interfaces that are fine grained and you only want to put some coarse grained services out there for the world to use.

The other bit on the diagram is that business service areas may combine information and function from a package with that from other applications either via a composite application or just by creating a facade over different applications to create a single consistent business view for the enterprise.

So the basic rules for package customisation are
  1. Don't
  2. No seriously don't
  3. If you have some differentiation then put it outside the package
  4. Consider the package as an integration point
  5. Don't customise the package itself
  6. Think of the business services to be exposed
  7. Remember that a business service can contain information and function from multiple IT systems.
So customise in the middleware, this is what these platforms are designed to be good at.


Technorati Tags: ,

1 comment:

James Taylor said...

Nice graphic and the right message. Let's hope SOA does not just change the kind of mistakes we make when we customize our processes and systems!
JT

James Taylor
The Smart (Enough) Systems blog
My ebizQ blog
Author of Smart (Enough) Systems