Location Centric packages - don't buy a 1990s package

One of the big problems with package solutions is that they are very database centric. Changing the data model is basically suicide for a programme. Adding a few new tables is dodgy but sometimes required and adding columns is reasonably okay but modifying the core data model is always going to get you in hot water.

One area that I've seen consistently as a problem over the years though is down to how the package vendors have thought about physical and electronic addresses. When the packages were created there were really only one set of important addresses, physical addresses. Phone numbers were pretty much fixed to those premises and email was a million miles away from the mind. This means that the data models tend to look at electronic addresses as very much second class citizens, normally as some form of child table rather than as a core entity.

The trouble is that as packages are being updated I'm seeing this same mistake being made again with some of the new technology models being used by vendors (AIA from Oracle appears to make the mistake). The reality is that the model is pretty simple

That really is it. There are two key points here

1. Treat all actors as a single root type (Party) then hang other types off that one
2. Do the same for Locations

The reason for doing this is pretty obvious. These days mobile phone numbers and email addresses are much better communication tools than physical addresses. As you want to send e-statements, e-invoices, and other elements to customers like SMS delivery notices, then you want to be able to channel shift customers much more simply. If a customer switches their delivery address for a book to an email then that is fine as long as you can ship them an e-book.

Now I know that anyone from an OO background is going to go "well duh!" but it does amaze me how in package land the database centric mindset still dominates and people just don't seem to want to revisit the assumptions they made in the 1990s when their hacks to put in electronic addresses seemed like a safe bet, after all email and the internet weren't considered as future strategies.

Its now well into the 21st century and I'd really advise people buying packages to look long and hard at the data model and ask yourself "is this a 1990s view of business or a 21st Century view" if its the former then be aware that you will have pain.

Technorati Tags: SOA, Service Architecture

Business SOA and package delivery

I've been rather quiet this year, mainly due to being full out on a rather large programme delivery effort. Package and Data (MDM) rather than my normal SOA work but still very much around the Business SOA approach, and more in future on how to do Business SOA for a package and have a really strong governance approach to ensuring a successful package delivery.

But I thought I'd give a brief over view here.

1. Detail the Business Services - including the "nearby" Business Services that aren't in your scope - this tells people at a high level what you are, and aren't, doing
2. Create a "Business Catalogue" that details the fine detailed capabilities that the programme will be delivering.
3. Map the catalogue to the Out of the Box (OOTB) functionalities in the package
4. Create a strong governance approach around managing changes to the catalogue
5. Document the capabilities using use cases. This gives you the explicit definition of scope that you need the enterprise to accept. These use cases are documented based on the OOTB what the package does, rather than being requirement gathering exercises

That is the high-level view and there will be more to come

Technorati Tags: SOA, Service Architecture

SaaS and the Cloud a development challenge

A while back I blogged on how to do ERP with a middleware solution. The point was to leave the package untouched while adding your customisations in an environment that was better suited to the challenge. It made upgrades easier and also would help to reduce your development timescales.

Well the world is moving on and now I'm looking at a challenge of SaaS + cloud. A standardised package delivered as SaaS where we need to extend it using a cloud solution to enable it to scale to meet some pretty hefty peaks. So how to meet this challenge? Well first off lets be clear I'm not talking about doing APEX in Salesforce I'm talking about treating the SaaS solution in the same way as I'd treat an ERP, namely as the service engines that provide the transactional functionality. What the cloud part would need to do would be to do the piece on top, the user interaction, pulling in some other web delivered elements in a late integration piece.

Model wise its the same


We've got a bunch of back-end services with interfaces (Web Services mainly) and we need to build on top.

The first new challenge is that of bandwidth and latency. "Build for the web" is all very well but there is nothing quite like a gigabit ethernet connection and six feet of separation. Here we have the information flowing over the web (an unreliable network performance wise) and we need to provide a good responsive service to the end user. So clearly we need to invest a bit around our internet bandwidth. Using something like Amazon clearly helps as they've done a lot of that already but you do need to keep it in mind and it becomes more important to make sure its not "Chatty" as those latency hops really add up.

The next piece of course is that we need to cache some information "Use REST" I hear people cry, the trouble is that even if I used REST (or rather if the SaaS provider did) then I'd still have to over-ride the HTTP Cache headers and build some caching in myself. Why? Well the SaaS solution has a per transaction model in certain sections and a per user in others, this means I need to limit users until the point at which they REALLY have to be known to the SaaS solution and I need to cache transactions in a way that reduces the money going to the SaaS vendor. So here the caching is 20% performance and 80% economic. Its an interesting challenge in either REST or WS-* as you are going against the policy that the service provider would set.

So the objective here is to build proxy services on the cloud side which handle these elements. These proxies are going to be reasonably dumb, maybe a basic rules engine to control pieces but are there to make sure that the "web" doesn't get in the way of performance. These proxies will however have a database that enables searching across sub-queries as well as the matching of exact queries (e.g. "find me all letters between A and Z" should enable the query "find me all letters between M and U" to be done as well without a SaaS hit) not sure yet whether we will go for a full database or do some basic pieces ala Amazon.

"Build for the web" is a mantra that many people are supporting these days, and there are good reasons for making your services available via that channel. But combining solutions and still delivering high performance is a significant challenge particularly when economic contracts can rule approaches such as the basic REST approaches redundant.

So when looking to build for the web think about the structure of your application and in particular the impact of latency and bandwidth on its performance as you look to consume other web applications. If you do have a financial contract in place with a SaaS vendor be very clear what you are paying for.

Technorati Tags: SOA, Service Architecture

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: SOA, Service Architecture