The next big wave of IT is Software Development

I can smell a change coming, the last few years have seen cloud and SaaS on the rise and seen a fragmentation in application development (thanks in a large part to the appalling stewardship of Java) and a real focus of budgets around BI and 'vanilla' package approaches.  Now this is a good thing, both because I jumped out of the Java boat onto the BI boat a few years ago but also because its really helped shift the investment focus away from 'Big iT' towards 'Big It' - by which I mean the focus has shifted very firmly towards Information over technology.

Now however companies are waking up to the fact that as good as a Salesforce.com or SAP is it really doesn't matter if everyone in your industry is using it, these are not your differentiators.  Your differentiators are what matter in terms of accelerating growth and outperforming your competitors.

This is where software development comes back and I predict the following four waves

• Wave 1 - the personal developer
• Wave 2 - the team developer
• Wave 3 - the enterprise developer
• Wave 4 - back to the package

Big Data will drive the new Software Development explosion

Big Data is the hype today and it will be the foundation of this new era as information is the key, fast data will however rapidly become just, if not more, important than 'Big' which means that the ability to integrate into transactions and deliver differentiation will be critical.  This is why we'll see a resurgence in software development based on new approaches and new platforms but we'll see the same sort of consolidation phases that we saw around Java.  Maybe this wave will last 10 years, maybe 5, maybe 20 but what appears certain is that the wave is coming.

This isn't the older wave though, it never is in IT, its the same sort of thing but now applied to the next generation of problems.  This is about information and collaboration and digitization of organisations, its about taking all these vast amounts of internal and external information and driving better outcomes and crucially about collaborating between organisations.

Lets be clear: this is going to be hard.

Back with Java we had a Database, we had SQL, we had (eventually) an App Server... that my friends was a walk in the park compared with what is coming.  I'll write a new post shortly on what the new world could look like but suffice to say you need the following

1) An inherent understanding of what makes information work - Master Data, Big Data, Analytics

2) An understanding of how to drive impact - how to engage users

3) An understanding of how to work with people outside your organisation

You thought doing a Java project with offshore delivery and a bunch of legacy integration points was hard?  Hang on to your hats... 

Bling and ignorance - how cloudy thinking will screw up IT

Today it was annouced that Progress Software are going to 'divest' their BPM and SOA technologies and instead are going to focus on cloud technologies that don't really exist yet. This is indicative of a mentality I see around so first lets start with some credentials: 1) I worked with Google around a SaaS partnership in 2007 around Google Apps 2) I delivered an SFDC solution in 2008 3) I've worked with Amazon, VMWare and lots of other cloud based companies So lets be clear I think cloud and SaaS can be extremely useful things, the problem comes when people begin to think they are magic. Lets be clear SaaS is a software package pre-installed and configured that you can pay for on demand - the change isn't the software its the capacity and the charging model Cloud is an infrastructure play to provide old school tin in a virtualised manner in a way that can be quickly provisioned and paid for on demand. That really is it. The problem I see is that people take the new bling and forget the old lessons. So people say 'I'm am using SFDC and it is my customer MDM I don't need anything else'... in the same way that people said that about Siebel in 2000 and found out in 2002 that it wasn't true. They say 'its on the cloud so I don't need to worry about architecting for performance, I'll just scale the hardware' as people did around 'pizza box' architectures in 2000. I hear 'we don't need to worry about integration, its on the cloud'... like people did around SOA/ESB/WS-* in ... 2000. The problem is that the reality is the opposite. The more federation you have the more process and control you need. The more information is federated the more requirements you have for Master Data Management. Cloud solutions are not silver bullets and they are not always simple solutions to integrate with other systems, great on their own but not good with others. Rapidly people are building federated IT estates with federated data and no practice and process around integration which leads to a massive EXTERNAL spaghetti mess, something that makes the EAI problems of the 90s look like a walk in the park. Or to put in another way... isn't it great how people are making more work for those of us in IT.

How politicians could kill SaaS with stupidity

Back when I was doing SaaS a few years ago I raised the issue of the Patriot act as being a reason why cloud providers would be setting up in Europe.  The rule however appears even worse than I knew so now the Patriot Act impact US cloud sales directly as the hosting location doesn't matter its the rules.

With the US Congress seeming to view China and the rest of the world with concern and talk of trade barriers being raised it isn't hard to see that the next four years could see a real shift in cloud and SaaS adoption, if for instance any European or Asian companies suffer publicly as a result of US policy with regards to their own information or non-US legislation (EU data privacy for instance) makes it impossible to be both Patriot Act and client complaint.

This challenge to US based vendors could lead to a flight from US shores for many of them or arms-length 'collaboration' agreements with European and Asian providers.  At worst it will lead to a collapse of these cloud providers as their markets are restricted to just the US borders while truly global players will be able to address emerging high volume markets.

If congress does start making more draconian legislation which means US companies are able to offer even less assurances to non-US organisations and non-US governments 'retaliate' by strengthening their own data privacy and retention legislation then we could very quickly find ourselves in a 'Cloud' based trade war, one governed not by tariffs but by policies because the adherence to those policies acts as a tax on the cloud provider, and if the provider is not able to obey both the US legislation and local laws then in effect that provider will have been barred from the country.

Trade wars in SaaS and Cloud will be fundamentally different, less about tariffs and taxes and more about policies and laws.  Right now Congress has firmly put itself on a trade war path.

Unfortunately I don't think they realise that.

SaaS integration - making the ERP mistakes on a bigger scale

One of the most frustrating things in IT is the totally amazing ability of people not to learn from past experiences. The following are all the sorts of things I've recently heard at conferences, vendor presentations, business presentations and in company architecture practices.

"We don't need an MDM solution as Salesforce is going to be our only customer repository"
"Integration is simple, its all just REST or Web Services, we don't need to worry about that"
"We are moving to SaaS because it doesn't require integration and dealing with IT"
"The business are on their own if they do SaaS, we just deal with the internal IT"

And a whole litany of others over the last few years. The general theme is that business folks are commissioning SaaS solutions and in collusion with the technically naive are setting up entire new estates beyond the firewall. Meanwhile the internal IT groups are often washing their hands of this deliberately and fighting against the change.

Lets start with the first statement, as its the one I've heard several times.

I don't need MDM, my SaaS CRM is my master


This probably wins it in my book for the least ability to learn from IT and business history.  This is exactly what folks did in the first CRM rush in the 90s and have spent the last 15+ years trying to recover from.  Fragmentation of customer information is a fact, even more so in these days of social media, so starting a strategy with the idea that an externally provided solution in which you have little or no say and which is set up to be good as a SaaS solution not as an enterprise source for customer matching, merging and dissemination is like doing a CRM project in the 90s by lobbing money at consultants and saying "build whatever you like lads".... really not a good idea.

If you are going to look externally for SaaS, and there are good business reasons to do so, then the first question should be how to create the unified information landscape that modern businesses require.  That is an MDM problem, which only gets bigger as you include suppliers, products, materials and all of the other core entities that exist.

Integration is simple, its just REST/Web Services
While the CRM one is a joint IT/biz error then its this one where IT really excels itself in ignoring the past.  Integration is a hard problem in IT, its made much harder if you don't have MDM style solutions, when looking at SaaS the fact that you have published interfaces helps slightly but you still have the challenges of integrating between multiple different solutions, mapping the information, mapping the structure and of course updating all this when it changes.  That however is of course just the technical plumbing.  Then you have to look at your business processes that span across SaaS solutions and the enterprise as well as where to add new services into that environment.

The spaghetti mass of ERP and enterprise in the 90s which EAI aimed, and mainly failed, to solve will be nothing compared to this coming morass of externally competing companies who have a real commercial reason to keep you locked to their platforms and approaches and have the actual ability to make things tough as they can change their platforms as they want without asking for permission.

We are moving to SaaS so we don't have to deal with IT
This is a common refrain that I hear, but its very short sighted, what it really means is that the current IT department is broken and not meeting the demands of the business and not even properly explaining to the business what is going on.  This really is just storing up problems for the future, or just delegating the problem externally to another group who will end up being your IT department in future, but probably harder to shift and change that your current group.

If the business do SaaS that is their problem, we just do internal IT
I like to think of this as the IT redundancy programme, its a wilful attempt to ignore the real world and it really is only going to end badly.

Summary
The point here is that moving to SaaS is actually a bigger challenge for integration and information management than the old ERP challenge, but most companies are entering it with the same wild-eyed wonder that companies entered the ERP/CRM decade of the 90s.  Leaping in and just assuming that historical problems of integration will disappear.  The reality is that companies need to be more structured and controlled when it comes to SaaS and the IT departments must be more proactive in setting up the information and integration infrastructure to enable this switch.



Technorati Tags: SOA, Service Architecture

The IT department - first against the wall when the revolution comes

I had a thought today, what with all the SaaS stuff out there and the increasing technical proficiency of new users, who often out-strip their internal IT departments in how they use and apply technologies. Is there a point to an IT department?

What is IT? "Information Technology" is the term but the reality is that when we say IT we mean the "internal development of technology". This department made a lot of sense when IT consisted of a lot of arcane programming and complex networking, in a world where no-one understood what "integration" really meant or why it was important for transactions to be atomic and for people to understand what two phase commit actually meant.

But does that world exist anymore? In particular I mean is there a point to having a great big IT department with IT management and Enterprise Architecture in a world where businesses change and where technology is an integral part of any modern business strategy in the same way as staff are. Has anyone heard of an "HR Project Manager" who organises the resources for a project? I certainly haven't, I've heard of HR admin or support for a project but the project management is left to the leader of the project. Why isn't IT going that way?

We have cloud computing, SaaS and all these other bits so doesn't that mean that with Mashups and the like that the IT department of the past is doomed?

Now this should be where I say "no" and then explain why, but instead I'm going to say "yes".

You see when I go into most IT departments they are mainly self-sustaining beasts, they have philosophies and leadership all of their own and more often than not have a CIO who is as close to the leading edge of technology trends as the CFO they work for. The IT department drives customisations, by providing the ability for the business to do it without the explanation as to why they shouldn't. The IT managers and IT project managers are often so fixed on a particular technology that they are an active barrier to the company changing its approach.

Its the IT department and its holistic henchmen of Enterprise Architecture who provide the barriers to cloud adoption and who promote the use of internal solutions, solutions they control and customise, over external provision. As the business starts to take control of business architecture and lay out the financial model for IT rather than simply a wish list of requirements its hard to see what the point of traditional project managers or enterprise architects is in this new world. Particularly in a new world where the business can just look at a SaaS solution and say "yup, that'll do" rather than complete a long project of customisation and installation.

As infrastructure becomes completely virtual the need for "experts" who can buy and install "the right server" disappears.

So what is required in future IT, is there any need for IT professionals? Well yes of course there is for several reasons

1) Everything will never come in a package
2) You'll aways need to integrate stuff

The key point is that differentiation is what IT people should focus on and start handing over responsibility for the commodity stuff to the business departments that use them. Finance should take control of the finance packages, HR should run the HR packages both as integral parts of their business. Sales should take control of their CRM and marketing packages. This switch of control would help accelerate the move to SaaS and away from customised solutions where they don't add value.

I'm not arguing here for a decentralised IT department, I'm arguing for the externalisation of IT and its management by the business and not by IT professionals.Yes sometimes the IT department helps drive the change, but very rarely from what I've seen, as the business becomes more tech-savvy than the old school tech managers its time for the business to take control back.

So what is left in IT? Well for me its the bits of IT that really add the value, the bits genuinely concentrating on where the business sees potential for ROI. In other words its the solution folks in IT, the real technologists who pull together various pieces and add a touch of development to create something that really differentiates the company. I'd guess this would be less than 20% of IT spend today, so my proposal is simple.

So what does that really mean? Well it means that current IT back office systems are really going the way of networks, mobile phones, land-lines and the like and moving out of technology and into procurement. In future the business will procure SaaS for back-office rather than ask IT departments to deliver it. The old IT department will be left doing "just" the differentiating parts.

So in other words the end result of this revolution is going to be that IT spend is split between procurement of services via normal business challenges and the commissioning of differentiating services. This should mean that the IT department is more about custom build than about package delivery, which is a marked difference over today.

So yes the current IT department is going away, but its replacement is going to be focused on smaller and more specific areas of the business and focused where innovation delivers actual value. This is not something that most IT departments will be happy with as it commoditises much of their current work. This is why in the coming change there will be many IT departments where the change will be extremely traumatic.

I firmly believe this change will happen and that traditional IT departments will be the biggest barrier in their inability to recognised the difference between business value and IT cost.

So will you be first against the wall when the revolution comes?

Technorati Tags: SOA, Service Architecture

I don't care about cloud because I don't care about tin

I'll start with an admission, I've worked with cloud providers for quite a few years now and the reason is not because I'm excited about elastic scalability of compute and storage... its exactly because I don't care about elastic scalability of compute and storage. I've said before that Tin Huggers are a major blocker to cloud adoption... but now I wonder if cloud itself is actually part of a broader problem...

Cloud is just tin, virtual tin it doesn't actually have a point, it doesn't actually do anything...

Great cloud services such as Amazon AWS are great not because they provide a bunch of tin, but because they provide a set of services which enable the virtualisation of tin. You aren't buying tin its the service, but all the service provides is virtual tin.

SaaS however is different because SaaS provides you with some business capabilities, you are buying a set of business services and you are buying them "as is". Cloud is in one sense just a revision of current IT models where you are building your stuff on virtualised infrastructure, sure its a bit more dynamic but at the end of the day you are still building your own stuff the only difference is that rather than it being hosted in a data centre you never visit but on tin you've bought its hosted in a data centre you don't even know where it is on tin you are renting.

So my point is that cloud is in one sense dull, its the same reason I don't care about the telephone infrastructure, sure I make phone calls and I'm glad its all there, but its the phone and the services I care about, the infrastructure can go hang. This doesn't mean cloud or the phone infrastructure aren't important building blocks for lots of things and clearly SaaS builds on cloud, but equally clearly SaaS is the point that (in the words of the OASIS SOA RM) delivers the real world effect while Cloud just forms part of the execution context.

Lots of cloud marketing and words out there is really just old style IT with a minor bit of lip gloss applied by using "cloud", but does that actually deliver a better service to the business? Sure sometimes the dynamism is good, but sometimes you'd be better off just buying a SaaS service and people are using Cloud interchangeably with SaaS to deliberately muddy the waters and pretend that by doing Cloud they are in fact really doing SaaS and being more business centric.

Cloud is IT centric, SaaS is business centric.

And that is why I care about SaaS and don't care about Cloud. I want to know what services the business can run not how "dynamic" or "scalable" the tin is, I've heard those conversations all my career and they've always bored me. Software is scalable, tin just gets bigger (horizontally or vertically). Cloud is a diversion, sometimes its a successful diversion but in 80%+ of cases SaaS is the true revolution and confusing it with virtual tin isn't helping move us forwards.

Clouds are boring, because Clouds do nothing, its what you run on Clouds that counts and most of the time SaaS is better than old style custom build but on a shinier set of tin.

Technorati Tags: Cloud, Service Architecture

In praise of vendor shipped AMI's and virtual machines

Roman Stanek is one of those guys who consistently gets things right and his point around AMIs and Virtual Machines not being SaaS is absolutely 100% spot on. These aren't SaaS solutions they are PaaS solutions and they do indeed leave a huge amount of work for the developer to do. Part of the problem is of course that the name Software as a Service is of course wrong its really Service as a Service that you are buying.

So that said I do disagree with him that shipping AMIs is just the same as shipping DVDs for one very very big reason

AMIs and Virtual Machines must run

This for me is a big leap forward from vendors as while it still means that I have to build my application I don't have to spend days or even weeks trying to install software that quite clearly has never been tested from the DVD or downloads that they have on the site. Some wonderful pieces I had in the past include

• A software & hardware manufacturer whose software worked on competitors operating systems but not their own
• A software vendor whose instructions for connecting their two products had never been tested... I know this as it did not work at all
• Spending 2 weeks installing from DVDs and downloads from a vendor and eventually having them on-site trying to do it for themselves, failing and then "getting back to us" a week later with an installer than actually worked
• A single software vendor whose two products that were required to work together required two differently patched versions of the Java runtime
• A vendor whose installation DVD was missing some core jar files, which they denied at firt but the old "Class not found" exception was a bit of a give away

So I'd like to praise AMIs and vendor delivered virtual machines for the basic progress that at least now it is spectacularly hard for a vendor to ship a non-working image. It might be an ugly image with lots of hacky patches required, but at least they've had to do all that dirty work and not you.

So don't con yourself that you are doing SaaS, you aren't you are doing PaaS at best. But do rejoice in that vendors are at last forced to prove that the software runs before shipping to you. Having a vendor delivered AMI or virtual machine that doesn't run really would set a new low bar in the sorts of quality that they expect customers to put up with.

So I say hail this new move away from DVDs and towards images, because personally I'm sick and tired of debugging their installers.

Business Utilities are about levers not CPUs

"As a Service" is a moniker tagged against a huge number of approaches. Often it demonstrates a complete marketing and intelligence fail and regularly it just means a different sort of licensing model.

"As a Service" tends to mean utility pricing and the best "As a Service" offers have worked out both what their service is and what its utility is. Salesforce.com have a CRM/Sales Support service (or set of service) and the utility is "people". Its a pretty basic utility and not connected to the value but this makes sense in this area as we are talking about a commodity play and hence a simple utility works.

Amazon with their Infrastructure as a Service/Cloud offer have worked out that they are selling compute, storage and bandwidth. Obvious eh? Well not really as some others appear to confuse or mesh the three items together which doesn't really drive the sort of conservation behaviour you'd want.

The point about most of these utilities though is that are really IT utilities. SFDC measures the number of people who are allowed to "log on" to the system. Amazon measure the raw compute pieces. If you are providing the base services this is great. But what if you are trying to then build these pieces for business people and they don't want to know about GB, Gbps, RAM or CPU/hrs? Then its about understanding the real business utility.

As an example lets take retail supply chain forecasting, a nice and complex area which can take a huge amount of CPU power and where you have a large bunch of variables

1. The length of time taken to do the forecast
2. The potential accuracy of the forecast
3. The amount of different data feeds used to create the forecast
4. The granularity of the forecast (e.g. Beer or Carlsburg, Stella, Bud, etc)
5. Number of times per day to run it
   

Now each of these has an impact on the cost which can be estimated (not precisely as this is a chaotic system). You can picture a (very) simplified dashboard




So in this case a very rubbish forecast (one that doesn't even take historical information) costs less than its impact. In other words you spend $28 to lose $85,000 as a result of the inaccuracy. As you tweak the variables the variables the price and accuracy vary enabling you to determine the right point for your forecasts.

The person may choose to run an "inaccurate but cheap" forecast every hour to help with tactical decisions and run an "accurate and a bit expensive" forecast every day to help with tactical planning and run a weekly "Pretty damned accurate but very expensive" forecast.

The point here is that the business utilities may eventually map down to storage, bandwidth, CPU/hrs but you are putting them within the context of the business users and hiding away those underlying IT utilities.

Put it this way, when you set the Oven to "200 C" you are choosing a business utility. Behind the scenes the power company is mapping this to a technical utility (kW/h) but your decision is base on your current business demand. With the rise of smart metering you'll begin to be able to see what the direct impact is on your business utility decision on cost.

This is far from a simple area but it is where IT will need to get to in order to clearly place the controls into the hands of the business.

They've paid for the car, shouldn't we let them drive?

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

Religion as a Service

Okay a few weeks ago I had a brain-wave for a new business. What do you really need for a business to take off in the "as a Service" space?

1. It needs to be 80%+ commodity
2. You need a large customer base
3. You need the end customer to add their own differentiation

Above all I wanted a business that would be a much higher margin one than simply a SaaS business, which meant including the actual business process work as well.

Hence the idea for "Religion as a Service". Focusing initially on the Abrahamic religions (where lets face it around 80% of the rules and processes are the same) this would expand to enable a more active selection of deity (or alien race) and a greater degree of customisation around the rules of your newly created faith.

Religion as a Service goes far beyond simply providing you with a customised version of your "one single book that has all the truth in it" to actually providing you with a modern industrialised solution to your religion's needs. This includes

1. A multi-language call centre to handle donations
2. A set of "white-labelled" preachers who can be branded to your own faith (for cheaper religions this can be mutualised if the demand isn't there yet)
   
3. An "avoid damnation" generic TV show including presenter with amazing hair that can be tailored to your religious target market
4. Believers on Demand - a set of white labelled individuals from your core demographic to create the impression of an already thriving faith
5. iPhone versions of your sacred text
6. Place of Worship in a box - a high value service that converts buildings into a faith centre, in a similar manner to the successful "Irish pub in a box" model
7. PR support to help you claim discrimination and subjugation
   

All of this is backed by a robust IT and BPO solution that handles training, indoctrination, HR, payroll, finance and accounts.

Because "Religion as a Service" isn't limiting itself to a single religious ideal it will be able to offer dramatically cheaper costs than establishing your own religion from scratch. For people looking to establish a new evangelical Christian sect for instance you can be up and running in a matter of hours and proclaiming yourself to be the 2nd coming of Christ without all of the massive overheads that this normally entails.

People with more demanding needs, for instance wanting to create a full church for the flying spaghetti monster, are still able to leverage the underlying resources and staff of RaaS but will need to invest more in the customisation of the central "core text", as this is however simply a reference volume and our staff are supported by the very latest holy knowledge management tools even the most esoteric demands can be met and scaled. This means that your local Cargo cult can rapidly be turned into a world wide phenomenon.

Religion as a Service's ability to leverage knowledge and resources across multiple faith channels means that it can offer new religions a much more efficient manner of scaling its followers and help a sect turn into a profitable business much more effectively.

Now all I need is a VC to fund it and I'm away.

Technorati Tags: SOA, Service Architecture

Single Canonical Form? Only Suicidal Dinosaurs need apply

Now I said a while ago that Single Canonical form wasn't for SOA well now I've been doing some SaaS projects and I've realised with traditional modesty that not only am I right, but that people who are still pushing it as an approach can be described as suicidal dinosaurs.

If SaaS is anywhere in your future, and it will be unless you are a military secure establishment and even then it might me, then GIVE UP NOW on the idea that you can mandate data standards in applications and create a single great big view that represents everything. It isn't going to happen, you are now back in the wild old world of multiple different systems each with their own specific exchange formats and....

you have to cope with it

Moaning about it or trying to push back on it because it doesn't meet your "corporate data model" isn't going to get you very far, its liable to get you heading out the door in fact.

Single Canonical Form is for people who believe in the great big database in the sky theory of architecture, it didn't work for SOA but some people still tried to force it in. Now the love child of SOA and the Cloud is coming to destroy it completely. The only sensible policy is to look at an "active" MDM strategy and a brokerage approach to communication between systems ideally based around a federated data strategy that leaves information its its source systems but provides references between them.

The brokerage challenge and active MDM challenge will only grow as SaaS becomes more common. There is no ability to inflict, and I choose the word advisedly, your Single Canonical Form on SaaS providers so you have to actually take a sensible solution oriented approach to data consistency and visibility.

Single Canonical Form is a dinosaur like approach but it was one which some people still managed to get away with proposing as a way to create a career. Well SaaS is the meteorite heading towards their earth and the choice is evolve or die.

Technorati Tags: SOA, Service Architecture

The challenge of "build for the web" to SaaS economic models

Build for the web is a strong meme. Most of the time people focus on the technical elements of this and the end user elements. What I haven't seen people talk about much is the impact that this has on the current financial models from SaaS vendors. SaaS can give great benefits for companies by enabling an OpEx rather than CapEx model but the solutions today do assume that a person is using them. Working on the system I'm looking at right now its clear that this model is okay in most cases in 2009 but won't be the case for long.

Think about a world where you are looking to combine a SaaS CRM provider (user based licensing) with a Logistics solution (shipment based) and an analytics solution (user based) and create a new unified sales/marketing and shipping solution.



All fine. But now lets say you get clever and you realise that from the CRM solution what you are really interested is tracking every interaction you have with customers. Your internal people aren't interested in the various options the CRM solution has, they just want to be logging what is going on but using the analytics to provide them with visibility of what they should be upselling and what are the current globally successful products.

Looking forwards as SaaS vendors shift towards different utility models which address their financial demands (e.g. what is a "user" if a remote service or other SaaS solution is accessing it?) the complexity of information sharing is liable to increase, both in terms of licensing ("you shall not cache or store information from XaaS outside of the system except for your own individual use, it shall not be loaded into another application where users other than yourself can access it") and in terms of efficient financial management.

The transactional model, shipments, however remains valid and is very difficult to get around. Sure you can be more efficient on the bundling but you are always going to pay for the actual transaction. This presents both a challenge and opportunity for user based licensing solutions, they can move away from it towards a more transactional based approach, e.g. accounts/prospects/campaigns/etc for CRM, and start providing a business with a more direct measure of the actual value they get from an IT system.

The SaaS revolution has a long way to run and its economic shift is only just starting.

Technorati Tags: SOA, SaaScloud

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

Trains and QoS

One of the challenges of designing a service is understanding the Quality of Service (QoS) both in terms of what it is, and importantly in how it is measured. The point about QoS is that it should be from the perspective of the consumer rather than from the producer. Historically people have ignored pieces like the network connectivity and latency but this is rapidly becoming a nonsense as people look at cloud computing and SaaS as standard parts of an IT infrastructure.

To use an analogy. I live about 30 miles or so from the office in Soho, Mike Morris lives in south london about 10 miles away. Now to open the door to get into the office takes about 10 seconds, and historically this is the SLA that would be given and the QoS would be measured from the point of standing outside the door to inside, a whole metre.

Now both of us are on train networks within walking distance at both ends, myself on the overground system, Mike on the underground. So in other words we both have network connectivity to the office.

Now here is the point, despite the fact that I live significantly farther away than Mike it takes us about the same time door-to-door because my train moves miles faster and stops much less than his underground train. This means from a QoS perspective our normal QoS is pretty much the same. This is where most people stop if they bother at all, measuring the end-to-end normal performance. However to really understand QoS and especially in a more critical area its important to look at what happens when things go wrong.

For Mike he has a couple of alternative routes if the main one fails, these take a bit longer (lets say 20-30% longer) and in the worst case scenario he could walk there in about 2 hours (a 120% increase), this means that from a disaster recovery perspective its not actually something that is over-worrying from a QoS perspective, its like switching from a dedicated commercial internet connection to ADSL or at worst to dialup, you can still get there but the performance sucks.

For me however we are in a different world of hurt, there are no alternative train routes so it would be either car (lets say at a 150% increase) or if that was buggered, for instance in the recent snow, then walking would take an impressive 11 hours or in other words it wouldn't work at all. Therefore I need an alternative solution, this comes in the form of home working where I have a duplication of the office environment (power, light, internet connectivity) and some additional software (VPN) to ensure I can continue working.

This is the point of QoS when looking at Cloud and SaaS and distributed SOA solutions. You've got to think about what happens if the main network routes fail, are there alternatives, can you put in an ISDN line for emergencies? What if the connection really is down and it can't be established. Can you have a local cache that will support minimal working? Can you degrade so you don't need to use that service?

The point about QoS is that you need to look at the failure conditions of the whole network not simply the last inch. Many of these elements might be out of your control and therefore you need to push back the QoS onto the consumer to make sure they are informed about what is their responsibility and what you will guarentee. This is what the cloud and SaaS providers do, but if your job is to ensure the business can use those solutions then you need to be looking at that end-to-end element and concentrating on the connectivity and caching more than thinking "the internet is always up and its always performant".

SouthEastern trains provide me with a great QoS on a good day and complete rubbish on rather a lot of days, if I was using a SaaS solution where the network issues were similar then my perception would be that it is the SaaS solution that is rubbish.

Perception is everything when rolling out new technologies and QoS is the rigour required to make sure the perception is positive.

Technorati Tags: SOA, Service Architecture

SaaS isn't software its service

I've said it before and I'll say it again. SaaS isn't about SOFTWARE as a service its about a SERVICE as a service.

Salesforce.com don't sell software, they sell a CRM solution. They also sell and INFRASTRUCTURE or DEVELOPMENT platform as a service but it still isn't the software that you are buying its the whole platform service.

This is the problem that the Middleware as a Service type vendors are falling into. Looking for a generic offer they appear to be going for the concept that just lobbing their software on the cloud and putting in some utility makes it more attractive. It doesn't.

Platform as a Service plays are (IMO) pretty niche but they happen to be the poster children at the moment because that is where the billions of investment have gone. These are plays for a large proprietary platform and the investment levels just make it unsustainable for smaller companies to compete and smaller PaaS offers are doomed to fail as they won't have the scale or buzz around them.

Within the SaaS space however you may well use a BPM or an ESB or a rules engine within a cloud infrastructure and require cloud licensing models. The point however is that you are USING the tool to deliver something more rather than simply offering the tool itself for rent. When building a SaaS offer then having a BPM or Rules layer for configuration and integration makes a lot of sense, this doesn't mean that you are delivering PaaS it means that you are BUILDING SaaS.

The critical bit is SaaS is the final delivered service you are selling, this service will include an SLA, licensing arrangements and most importantly an operational solution onto which users can be provisioned. This isn't software, its a service.

SaaS is service as a service, which sounds rubbish but is the reality of what a business will buy. Middleware vendors who think SaaS really means SaaS are either going to spend billions on a major market platform pay or be doomed wasting their cash.

Technorati Tags: SOA, Service Architecture

Amazon's cloud goes dull

Now you can get JBoss on EC2 cloud computing is clearly trying to ditch the sexy image and move into the old dull world of profitable IT. Having an OS on a cloud wasn't a big deal as after all its not the OS that people are after its the apps. This however will be interesting particularly if Red Hat make the investment to develop effective dynamic clustering and scaling (up and down) approaches which can take advantage of a cloud environment.

With Google playing with Python and Salesforce wanting you to use their own proprietary dev environment it appears that Amazon are most clearly going for the traditional data centre. With Google (as it is now) and Salesforce you have to make a decision that the cloud is the thing and then develop for that given cloud environment. With this move Amazon & JBoss have basically announced a strategy where you can take your existing applications and move them into a cloud environment.

The operating system play was mildly interesting but saying to a CIO "move your Linux OS onto a could" is a sort of pointless play, saying "shift your Java App onto the cloud" make much more sense and critically doesn't sound as scary. After all you deploy the app remotely anyway so why not just deploy to a cloud.

This won't be for everyone but it does mean that cloud computing now has a data centre offer that will make it very interesting for people in the SMB hosting market.

Technorati Tags: SOA, Service Architecture

Le Tour SOA - why support services are critical, but not important

One of the biggest mistakes that IT makes is confusing "critical" with "important". What I mean by this is that IT often thinks that just because the failure of a service or application has major ramifications for the business that the application is also important to the business.

There are lots of applications and services that fall into this sort of category and the way to understand whether something is "important" or just "critical" is to look at what happens when it goes away

When a critical service fails, or is removed, then it has a massive impact on the operation of other services, work arounds are needed and contingency plans are brought in. People really notice it when it isn't there.

Important services however are noticed when they are there they are the reason that the other services exist. If the Important service goes away then there is no point the other services continuing.

In other words Critical is about operations and Important is about business value.

To take this further I'll use the Tour de France which yesterday popped through the UK as an example of the difference.

About 1-2 hours before the race comes through the village there is the "caravan" these are the sponsors cars which dish out freebies to the crowd and are basically engaged in advertising. These are clearly support services, they aren't important to the race... well except that the sponsors give money and without the money the tour would be a much smaller event. So here we have a certain level of criticality for a support service, it clearly has an impact on the overall system but no-one would argue it is "important".

Next up comes the police, camera men and assorted random cars that must have some support job, but again its only support.

Then came the leading bunch of 5 riders, with a Brit in it, followed 5 minutes later by the pelaton. This is the important bit, without those riders then all of the other services, no matter how important, are pointless. There is no tour de France without the riders.

Following them are the teams with the spare bikes, liquids and the like, clearly these things are essential for any rider who wants to complete, let alone win, the race. If they went away then it would be practically impossible for a rider to compete, these are therefore critical support services. Their failure has a massive detrimental impact on the main business service (the riders).

In business the same applies, the phone system and electricity are "critical" to a modern business, but they are not "important", they are a relied upon commodity whose service level is important but which is not expected to create value. The same can be said of many things, HR, Procurement and often IT, and it is certainly true of IT systems. One of the big SaaS drivers is that these new solutions offer an answer to the "critical" question, while not requiring the costs of "important". Too often internal IT create critical systems whose costs far out weight the costs of truly important business services, indeed often these back-office critical elements suck the vast majority of the IT budget away leaving very little to deliver new innovation.

To really build a business case and deliver value from SOA its essential that IT takes an honest and pragmatic view on its current estate and differentiates the support service from the business services and the critical from the important.

So is that application you have been looking at one of the riders? The team support? Or just the people at the front giving away key-rings?

Technorati Tags: SOA,SaaS, Service Architecture

Software is redundant in Software as a Service

I've been having some chats in the last few days about how SOA and SaaS work together and how SaaS will actual pan out (as opposed to the hype) and one thing that has become really obvious is that SaaS isn't really SaaS. What I mean is that no-one is talking about buying Software when they buy SaaS, they are looking to buy a Service whether that is a word processor, Salesforce automation, invoicing, accounts or whatever. People are looking to buy a business service which they access, they don't care how that is created, the don't care at all about the technology its just the delivery to them that matters.

SaaS really is about Service as a Service, that is providing a business service whole and in itself in the way that you want. Software as a Service is the IT view, but it isn't IT that is buying SaaS.

Technorati Tags: SOA, SaaS, 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