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
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
- No seriously don't
- If you have some differentiation then put it outside the package
- Consider the package as an integration point
- Don't customise the package itself
- Think of the business services to be exposed
- Remember that a business service can contain information and function from multiple IT systems.