Start on the road to SaaS with SPUD

Lots of companies are leaping onto SaaS in the manner of a drowning man grabbing onto a tiger shark in the vain hope that all will be fine. The problem is that they haven't really thought about what they want and what it takes to properly adopt SaaS so what they do is take the same old approach to package adoption

1. Work out what you want to do
2. Buy a package/SaaS solution to do some of it
3. Customise the package/SaaS solution to a point where its specific to your business
4. Act surprised when it goes over budget, over time and turns out to be a nightmare to maintain

SaaS can actually be worse in the 4th point that traditional packages as at least if you do the truly dumb of changing the database schema under Oracle or SAP then you have the choice of not upgrading something that just isn't possible with SaaS where all of your customisations and specific developments have to be upgraded when the SaaS vendor says you do.

The right way to adopt SaaS is really the right way to adopt packages. Its not rocket science and comes down to a very a simple point

You've chosen to use a package as you don't see this area of your business as differentiating

If you do think its differentiating then why on earth are you picking something that all of your competitors can buy? If you think its "10%" differentiating then you are probably kidding yourself and in reality its a case of its 100% non-differentiating but there is something you should be building on-top of the package that could add something. In otherwords you've got something extra that differentiates, not something different.

Anyway so once you've faced the reality what is the obvious conclusion?

Package implementation is about changing the business to fit the package not the other way around

So you need to focus on fitting the business to the best-practice that you've purchased from the package vendor and delivering a Standardised Package (SP) as quickly as possible. Not unsurprisingly companies that do this tend to find their package implementations hit time and budget much more often and they tend to deliver greater operational efficiencies as it challenges locally held truths that turn out to just be historical relics. The point here is that in reality you are undertaking a business programme that is just enabled by IT and the package vendor is providing the business processes.

Now the next question is of course how do you pay for this sort of solution? Well its now not about differentiation so its really about cost to serve which means that what you want to do is pay based on the business utility that is being provided. Implementation aside this means that the running of the solution should scale up and down in-line with that utility. The utility could be number of staff, number of transactions, value of transactions or anything else that represents what the business is actually paying for. This means that the package needs to be utility delivered (UD).

Hence the best way to adopt SaaS is really to look at it as just one delivery mechanism the core is really around two key decisions, the first is the business decision

• Standardised Package (SP)

The second is the economic decision

• Utility Delivered (UD)

Hence the best way to adopt SaaS is to ignore SaaS and concentrate on what you are trying to achieve as a business, which is SPUD. SaaS is the UD part of SPUD but to make it successful you need to do the SP bit as well.

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

Change the business not the package

I've spotted a bit of a worrying trend around SOA and package delivery namely that people seem to be thinking that SOA magically means that you can now customise packages safely. The goal becomes once again "fit the package to the business" this unfortunately is the road to ruin. It doesn't matter what the package is, whether Finance, ERP, niche or even a small off the shelf thing for a point solution the basic rule remains the same. You are going package because it doesn't differentiate you, it isn't an area where you will gain competitive advantage and if everyone in your sector ran the same package, it really wouldn't matter.

This is a critical starting point. If you want to use a package solution you have to accept that this means you have chosen to take a non-differentiated route. If your content is the thing that is your USP then this doesn't mean that you shouldn't use a CMS it just means you should recognise that it is the content that is the USP, not the publishing and managing of the content.

Too often people go through extensive requirements gathering before selecting a package and then try and find the "best fit" to those requirements. The project kicks off and they try and implement the remaining requirements. This is suicide, don't do it.

First off start with a set of objectives and principles that will guide the package selection. One of these principles must be that the goal will be to change the business approach to fit the selected package. Then choose the package. The next state is then to ask "how can I cope with what the package does" this leads to the understanding of what business change can be done.

So how does SOA help in this process? Well first off you can use a Business Service Architecture to understand the drivers and interactions at a high level, this really helps to clarify where the package will be used and to make clear the broad business context in which it fits. So if you are looking at packages across multiple areas you should still be thinking about the different areas based on their different business context and drivers, one size doesn't fit all.

So SOA doesn't mean that you can customise the package anymore today that you could before. There is a rough calculation that I've seen a few times around package implementations (the numbers vary a bit but the thought is important)

So basically the more you customise the more likely you are to fail. Now while it looks okay down the bottom end, don't be fooled.

Now these aren't hard and fast numbers, indeed they could be under playing the impact of customisation.

SOA doesn't help in terms of package customisation. A decent BSA can help you understand how the package will work (if at all) and the boundaries that it will have, but the same rules on customising the box remain.

There is however a new choice when it comes to adding differentiation into a business service which is partly implemented using a package.... but not in this post.

Technorati Tags: SOA, Service Architecture

How much would you pay for a process?

I've been looking at some SaaS solutions recently some have been niche vertical elements, others have been more "traditional" ERP type solutions that are delivered over the web, like Salesforce.com and Oracle OnDemand and it got me to thinking on some conversations I had with a chap called Paul Luckett. Namely if you have an infrastructure that can execute processes and you have some form of semantic mapping of your data to the format that the process requires then why would you not just by processes rather than applications?

The next logical step is then to not have the infrastructure but to "rent" processes based on how much you actually use them. Now for certain areas the argument can be made that there is too much competitive advantage for SaaS to really take off, but for lots of current ERP areas, such as Finance and HR, is there really so much value in customising things like employee onboarding, training approval, invoice creation or accounting? The answer is pretty much always "no" when it comes to putting in an ERP so why, if you have a middleware with the characteristics above wouldn't you just "buy" the process from someone who has formalised and optimised it already.

If however it is one of these commodity things that really don't add value would you really want to pay money to operate it yourself? Wouldn't you prefer to consider it as a utility in the same way as people have outsourced payrolls and telephones? I'd argue for a strong "yes" on that, and I'd even go a stage further. If you have an extremely common process, say creating an invoice, why wouldn't you actually just 100% standardise that via something like OASIS (like an ebXML that is light enough to work) and then have companies compete to be the most reliable hosting for that process.

I'm talking here about the back-end processes where ERPs currently dominate the market. But with the rise of SaaS, Semantic Web and process standards is their really a future for building your own HR, CRM or Finance solution? Isn't Oracle's OnDemand exactly the way the world needs to go?

So what is an invoice worth? 1 cent a time? 2 cents? its not going to be much. The commoditisation will rise up another level and more processes will be put into packages, but I think its reasonable to expect that in 5 years time you'll see the majority of new back-end processes being either downloaded and run or just rented. This gives whole new challenges around data security and retention to be solved but it does sort of argue that the vertical solution direction that SAP and Oracle are taking is the right one and that the new "cheap" ERPs on the block might be arriving after the bus has left.

Technorati Tags: SOA, ERP,SaaS