Tag Archives: Salesforce.com

Three questions you need to ask

There's three questions you need to ask yourself before you invest a large chunk of cash in some enterprise application:

  • Can I use something, rather than configuring something, rather than customising something?
  • How will the solution support the (social) community who will use it?
  • Is there a reason why I can't buy the solution ‘on-demand’ via SaaS?

Continue reading Three questions you need to ask

Is Salesforce.com already legacy IT?

The more I think about it, the more I feel that we need to rethink what “application” means.

The IT industry – and therefore “application” – has been defined by businesses’ need to acquire IT assets. The roles companies play in the industry have accreted around this need, as I’ve pointed out before{{1}}.

[[1]]Business models for the old rules of IT @ PEG[[1]]

The big shift we’re seeing in the market at the moment is a move from companies wanting to acquire IT, to a need to engage services enabled by IT. I know, for example, one airline that has externalised flight planning and pays per flight plan, rather than worrying about the tools need to support a team of flight planners. It’s a capability and process centric view, rather than a technology centric view.

If we follow this line of thought through then we quickly realise that the future of IT in business will be determined by the need to knit together a fabric of IT enabled services, many of which will be obtained externally. I don’t need a project portfolio management solution, I need a portfolio management capability backed by the tools and skills required to make it work. I don’t need a CRM solution (SaaS or not), I need a sales management and reporting methodology (Holden? Miller Heiman?) supported by technology to enable it to scale. It’s outside in thinking, rather than inside out.

What will the industry that accretes around this new need look like? If we look at many of the current on-demand / SaaS vendors, then they could best be described as enterprise software, but in the cloud!. Take the old model and make it multi-tennanted. We should probably call this Cloud 1.0 (where MySpace was social media 1.0). Cloud 2.0, however, will be something different and might be just over the horizon, rendering the current incumbents obsolete, legacy while they’re still young.

Have we reached peak SI

Have we hit the peak for systems integrators (SIs) (just as we appear to have reached “peak oil”), and it’s all downhill from here? While SIs are doing well at the moment, structural changes in the IT market suggest that the long term forecast is not all sunshine and roses as some pundits are predicting. With IT spend migrating from IT departments (the SI’s traditional buyer) into the lines of business, the ongoing shift to smaller projects delivering on-demand (rather than on-premesis) solutions, and the replacement of traditional support arrangements with outsourced and managed services, it’s hard to see how SIs will continue to grow when demand for their services seems to be tipping into decline. Globalisation, software as a service (SaaS) and cloud computer are reconfiguring the IT landscape and SIs look like they will be the big losers.

Predictions for the continued growth of the SI market are based on the understanding that companies are consuming more IT today than they were yesterday, and the assumption that increased IT consumption will result in tidy profits for SIs. Predictions are a funny things though, based as they are on historical trends. Guess that the market will continue to rise when you’re in the midst of a bull market and you’ll be right, most of the time. That is until something happens, something you didn’t anticipate, something that catches you unawares. The assumption that SI revenue is tied to IT consumption might no longer be true. New tools such as SaaS and cloud computing are enabling line-of-business leaders to step around the traditional IT department and engage with technology directly, bypassing the SIs traditional relationships in IT and providing them with fewer opportunities to sell their wares. At the same time the shift from on-premises to on-demand solutions – solutions which the business is happy to rent rather than own – is slashing the effort required to install, configure and integrate these new solutions, often by as much as seventy to eighty percent. On-demand solutions also have much lighter support needs relying on self-help wikis, users forums and power users, leaving the SI with little more than a small help desk to manage. With only limited access to this new class of IT buyer, dramatically smaller projects, and lower support revenue, the SIs role as IT enabler seems to be in decline. All good things come to an end though, and you usually only realise that the end has come after it has already passed. IT consumption might be going up, but there’s a good chance that SI revenue could soon be going down at the same time.

SIs are fundamentally sandwich shops{{1}}. When we don’t have the time or money to maintain our own kitchen or make our own sandwiches it can be more efficient to head over to the local sandwich shop to pick up what we need. Their margins are thin and revenue is largely tied to the size of the sandwich you just bought, so they’d really like you to buy a larger and more expensive sandwich. (Notice how sandwiches have grown so much bigger over the years, and everything is now gourmet?) And, of course, pre-made sandwiches are always a lot cheaper than special orders. This sandwich shop model is something that was established early on in the history of business IT. How else could companies afford to access the rare (and expensive) IT skills they needed to create all the systems they need? This might be a payroll system, or stock management, sales pipeline reporting, or the dreaded enterprise resource planning (ERP). Consuming IT used to mean hiring an SI to build and integrate something for you.

[[1]]Business models for the old rules of IT @ PEG[[1]]

The world has changed since then. Back when I started in the industry my home computer couldn’t hold a candle to the beast I was given at work. Today, however, my shiny new 17″ MacBook Pro makes the locked down Windows XP laptops I’m offered seem like a bit of a joke. A new breed of business manager has crept into the business while the world has changed, these are people who grew up with technology and are comfortable solving their technology problems on their own. They know that there are alternatives to the expensive solutions proposed by the IT department (solutions that IT will engage an SI to deliver), and they’re happy to use these alternatives. Why spend a seven figure sum and wait a year for the IT department’s perfect, enterprise-wide project portfolio management solution when there’s one that is good enough, one you can buy on-demand via a company credit card, and one which you know will be up and running in a couple of weeks? We might argue about the regret cost{{2}}, but the art of business is to make a timely decision and then make it work; it’s not to sit on your hands and wait for the perfect solution which will be delivered sometime in the distant future. While demand for new IT solutions might be growing, every time a business manager steps around IT to engage and on-demand solution SIs have one less opportunity to sell their wares.

[[2]]The price of regret @ PEG[[2]]

At the same time we find that these on-demand solutions – when SIs do get their hands on them – only provide a fraction of the revenue that a tradition on-premisis solution does. Time is money for an SI (literally, as most avoid risk by sticking to time and materials contracts) and fielding a SaaS solution takes only a fraction of the time required for a more traditional solution. There’s no hardware to commission with SaaS or cloud computing, nor are there disks to wait for or backup strategies to create. (You still need to worry about business continuity, but that’s another post.) There’s also little chance for customisation, and integration tends to be via standard APIs or pre-built adaptors. It’s not uncommon for a SaaS project to be eighty percent smaller than the more traditional solution. Fewer resources on ground and fewer billable hours means that that the SI can expect their revenues to head in the same direction: south.

We’re also seeing the erosion of SI support revenues. Support used to encompass both the application – in terms of application maintenance, patching and security – and the users – with training and a help desk. Many SaaS and cloud providers don’t want to provide traditional support services as it erodes their margins, margins based on huge scale and little human contact. One solution is to engage an SI to provide these services for them, either on a client-by-client bases or as part of some sort of alliance. A more attractive solution is to move – as much as possible – to a self support model where clients support each other via user forums or a Google search. We soon find that a much smaller help desk will suffice as it’s only required to be the point of last resort, or to support the more technologically illiterate users.

Taken together, these trends – reduced access to buyers, lower project revenues, and lower support revenues – seem to show that the future is not as rosy for the SIs as we first thought. Demand for IT might be growing, but growing demand for IT no longer implies growing demand for the services provided by SIs. The final nail in the coffin is the fairly recent move into SaaS by established IT application vendors. Microsoft has gone on record as wanting to capture a greater percentage of IT spend as license revenues, converting SI installation and customisation costs into licenses by providing clients with prepackaged configurations which can be turned on at the flick of a switch. Rather than pay for a SaaS CRM and then engaging an SI to configure it to your liking, you pay for the SaaS CRM along with a canned sales methodology (Miller Heiman{{3}}? Holden{{4}}?) which works out of the box (as it were). Integration between SaaS solutions is also being converted into a configuration option as SaaS vendors sign alliances – just as Google and Saleforce.com did with GoogleForce – enabling these alliances to offer complete application suites which work together out of the box.

[[3]]Miller Heiman: The Sales Performance Company[[3]]
[[4]]Holden International: Outsell You Competition[[4]]

Whichever way you look at it, now is not a good time to be a SI.

Taxonomies 1, Semantic Web (and Linked Data) 0

I’m not a big fan of Semantic Web{{1}}. For something that has been around for just over ten years — and which has been aggressively promoted by the likes of Tim Berners-Lee{{2}} — very little real has come of it.

Taxonomies, on the other hand, are going gangbusters, with solutions like GovDirect{{3}} showing that there is a real need for this sort of data-relationship driven approach{{4}}. Given this need, if the flexibility provided by Semantic Web (and more recently, Linked Data{{5}}) was really needed, then we would have expected someone to have invested in building significant solutions which use the technology.

While the technology behind Semantic Web and Linked Data is interesting, it seems that most people don’t think it’s worth the effort.

All this makes me think: the future of data management and standardisation is ad hoc, with communities or vendors scratching specific itches, rather than formal, top-down, theory driven approaches such as Semantic Web and Linked Data, or even other formal standardisation efforts of old.

[[1]]SemanticWeb.org[[1]]
[[2]]Tim Berners-Lee on Twitter[[2]]
[[3]]GovDirect[[3]]
[[4]]Peter Williams on the The Power of Taxonomies @ the Australian Government’s Standard Business Reporting Initiative[[4]]
[[5]]LinkedData.org[[5]]

The technologies behind the likes of Semantic Web and Linked Data have a long heritage. You can trace them back to at least the seventies when ontology and logic driven approaches to data management faced off against relational methodologies. Relational methods won that round — just ask Oracle or the nearest DBA.

That said, there has been a small number of interesting solutions built in the intervening years. I was involved in a few in one of my past lives{{6}}, and I’ve heard of more than a few built by colleagues and friends. The majority of these solutions used ontology management as a way to streamline service configuration, and therefor ease the pain of business change. Rather than being forced to rebuild a bunch of services, you could change some definitions, and off you go.

[[6]]AAII[[6]]

What we haven’t seen is a well placed Semantic Web SPARQL{{7}} query which makes all the difference. I’m still waiting for that travel website where I can ask for a holiday, somewhere warm, within my budget, and without too many tourists who use beach towels to reserve lounge chairs at six in the morning; and get a sensible result.

[[7]]SPARQL @ w3.org[[7]]

The flexibility which we could justify in the service delivery solutions just doesn’t appear to be justifiable in the data-driven solution. A colleague showed my a Semantic Web solution that consumed a million or so pounds worth of tax payer money to build a semantic-driven database for a small art collection. All this sophisticated technology would allow the user to ask all sorts of sophisticated questions, if they could navigate the (necessarily) complicated user interface, or if they could construct an even more daunting SPARQL query. A more pragmatic approach would have built a conventional web application — one which would easily satisfy 95% of users — for a fraction of the cost.

When you come down to it, the sort of power and flexibility provided by Semantic Web and Linked Data could only be used by a tiny fraction of the user population. For most people, something which gets them most of the way (with a little bit of trial and error) is good enough. Fire and forget. While the snazzy solution with the sophisticated technology might demo well (making it good TED{{8}} fodder), it’s not going to improve the day-to-day travail for most of the population.

[[8]]TED[[8]]

Then we get solutions like GovDirect. As the website puts it:

GovDirect® facilitates reporting to government agencies such as the Australian Tax Office via a single, secure online channel enabling you to reduce the complexity and cost of meeting your reporting obligations to government.

which make it, essentially, a Semantic Web solution. Except its not, as GovDirect is built on XBRL{{9}} with a cobbled together taxonomy.

[[9]]eXtensible Business Reporting Language[[9]]

Taxonomy driven solutions, such as GovDirect might not offer the power and sophistication of a Semantic Web driven solution, but they do get the job done. These taxonomies are also more likely to be ad hoc — codifying a vendor’s solution, or accreted whilst on the job — than the result of some formal, top down ontology{{10}} development methodology (such as those buried in the Semantic Web and Linked Data).

[[10]]Ontology defined in Wikipedia[[10]]

Take Salesforce.com{{11}} as an example. If we were to develop a taxonomy to exchange CRM data, then the most likely source will be other venders reverse engineering{{12}} whatever Salesforce.com is doing. The driver, after all, is to enable clients to get their data out of Salesforce.com. Or the source might be whatever a government working group publishes, given a government’s dominant role in its geography. By extension we can also see the end of the formal standardisation efforts of old, as they devolve into the sort of information frameworks represented by XBRL, which accrete attributes as needed.

[[11]]SalesForce.com[[11]]
[[12]]Reverse engineering defined in Wikipedia[[12]]

The general trend we’re seeing is a move away from top-down, tightly defined and structured definitions of data interchange formats, as they’re replaced by bottom-up, looser definitions.

Reducing costs is not the only benefit of cloud computing & SaaS

The wisdom of the crowd seems to have decided that both cloud computing and its sibling SaaS are cost plays. You engage a cloud or SaaS vendor to reduce costs, as their software utility has the scale to deliver the same functionality at a lower price point than you could do yourself.

I think this misses some of the potential benefits that these new delivery models can provide, from reducing your management overhead, allowing you to focus on more important or pressing problems, through to acting as a large flex resource or providing you with a testbed for innovation. In an environment where we’re all racing to keep up, the time and space we can create through intelligently leveraging cloud and SaaS solutions could provide us with the competitive advantage we need.

Sameul Insull

Could and SaaS are going to take over the world, or so I hear. And it increasingly looks that way, from Nicholas Carr‘s entertaining stories about Sameul Insull through to Salesforce.com, Google and Amazon‘s attempts to box-up SaaS and cloud for easy consumption. These companies massive economies of scale enable them to deliver commoditized functionality at a dramatically lower price point that most companies could achieve with even the best on-premises applications.

This simple fact causes many analysts to point out the folly of creating a private cloud. While a private cloud enables a company to avoid the security and ownership issues associated with a public service, they will never be able to realise the same economies of scale as their public brethren. It’s these economies of scale that enables companies like Google to devote significant time and effort into finding new and ever more creative techniques to extract every last drip of efficiency from their data centres, techniques which give them a competitive advantage.

I’ve always had problems with this point of view, as it ignores one important fact: a modern IT estate must deliver more than efficiency. Constant and dramatic business change means that our IT estate must be able to be rapidly reconfigured to support an ever evolving business environment. This might be as simple as scaling up and down, inline with changing transaction volumes, but it might also involve  rewriting business rules and processes as the organisation enters and leaves countries with differing regulation regimes, as well as adapting to mergers, acquisitions and divestments.

Once we look beyond cost, a few interesting potential uses for cloud and SaaS emerge.

First, we can use cloud as a tool to increase the flexibility of our IT estate. Using a standard cloud platform, such as an Amazon Machine Image, provides us with more deployment options than more traditional approaches. Development and testing can be streamlined, compressing development and testing time, while deployed applications can be migrated to the cloud instance which makes the most sense. We might choose to use public cloud for development and testing, while deploying to a private cloud under our own control to address privacy or political concerns. We might develop, test and deploy all into the public cloud. Or we might even use a hybrid strategy, retaining some business functionality in a private cloud, while using one or more public clouds as a flex resource to cope with peak loads.

Second, we can use cloud and SaaS as tools to increase the agility of our IT estate. By externalising the the management of our infrastructure (via cloud), or even the management of entire applications (via SaaS), we can create time and space to worry about more important problems. This enables us to focus on what needs to happen, rather than how to make it happen, and rely on the greater scale of our SaaS or cloud provider to respond more rapidly than we could if we were maintaining a traditional on-premises solution.

And finally, we can use cloud as the basis of an incubator strategy where an organisation may test a new idea using externalised resources, proving the business case before (potentially) moving to a more traditional internal deployment model.

One problem I’ve been thinking about recently is how to make our incredibly stable and reliable IT estates respond better to business change. Cloud and SaaS, with the ability to shape the flexibility and agility of our IT estate to meet what the business needs, might just be the tools we need to do this.

What we’re doing today is not what we did yesterday

Telxon
Telxon hand unit

The business of IT has changed radically in the last few years. Take Walmart for example. In the 80s Walmart laid the foundations for its future growth by fielding a supply chain data warehouse. The insight the data warehouse fueled their amazing growth to become the largest retailer in the world. However, our focus has moved on from developing applications. More recently Walmart fielded the Telxon, a barcode scanner with a wireless link to the corporate back-end. This device is the front end of a distributed solution which has let Walmart devolve buying decisions to the team walking the shop floor.

For a long time IT departments have defined themselves by their ability to deliver major applications into the enterprise. CRM, MRP, even ERP; all the three letter acronyms. For a long time this has been the right thing to do. Walmart’s data warehouse, to return to our example, was a large application which was a significant driver in the company’s outlier performance for the next couple of decades.

The world has changed a lot since that data warehouse went operational. First the market for enterprise applications grew into the mature market we see today. If you have a well defined problem—an unsupported business activity—then a range of vendors will line up to provide you with off-the-shelf solutions. Next we saw a range of non-technology options emerge, from business process outsourcing (BPO) and leveraging partnerships, through to emerging software-as-a-service (SaaS) solutions.

What used to be a big problem—fielding a large bespoke (or even off-the-shelf) application—has become a (relatively) small one. Take CRM (customer relationship management) as one example. What was a multi-year project requiring an investment of tens of millions of dollars to deploy a best-of-breed on-premises solution, has become a few million dollar and a matter of months to field SaaS solution. And the SaaS solutions seem to be pulling ahead in the feature-function war; Salesforce.com (one of the early SaaS CRM solutions) is now seen as the market leader (check with your favorite analyst).

Nor has business been standing still while technology has been marching forward. The productivity improvements provided by the last generation of enterprise applications have created the time and space for business stakeholders to solve more difficult problems. That supply chain solution Walmart deployed that was the first of many, automating most (if not all) of the mundane tasks across the supply chain. Business process methodologies such as LEAN (derived from the Toyota Production System) and Six Sigma (from GE) then rolled through the business, ripping all the fat from our supply chains as they went past. The latest focus has been category management: managing groups of product as separate businesses and, in many chases, handing responsibility for managing the category back to the supplier.

Which brings us back to the Telxon. If we’ve all been on the same journey—fielding a complete set of applications, optimizing our business processes, and deploying the latest, best practice, management techniques—then how do we differentiate? Walmart realized that, all things being equal, it was their ability to respond to supply chain exceptions that would provide them with an edge. As a retailer, this means responding to stock-outs on the shop floor. The only way to do this in a timely manner is to empower the people walking the floor to make a procurement decision when they see fit. Walmart’s solution was the Telxon.

The Telxon is an interesting device as it reveals an astonishing amounts of information: the quantity that should be on the shelf, the availability from the nearest warehouse, the retail price, and even the markup. It also empowers the employee to place an order for anything from a pallet to a truck-load.

Writer
Writer Charles Platt during his stint as a Wal-Mart employee in Flagstaff, Ariz.

As one journalist found:

We received an inspirational talk on this subject, from an employee who reacted after the store test-marketed tents that could protect cars for people who didn’t have enough garage space. They sold out quickly, and several customers came in asking for more. Clearly this was a singular, exceptional case of word-of-mouth, so he ordered literally a truckload of tent-garages, “Which I shouldn’t have done really without asking someone,” he said with a shrug, “because I hadn’t been working at the store for long.” But the item was a huge success. His VPI was the biggest in store history—and that kind of thing doesn’t go unnoticed in Arkansas.

Charles Platt, Fly on the Wall (7th Feb 2009), New Your Post

Clearly the IT world has moved on since that first data warehouse went live in Arkansas. Enterprise applications have been transformed from generators of competitive advantage into efficient sources of commodity functionality. Technology’s ability to create value should be focused on how we effectively support knowledge workers and the differentiation they create. These solutions only have a passing resemblance to the application monoliths of the past. They’re distributed, rather than centralized, pulling information from a range of sources, including partner and public sources. They’re increasingly real time, in the Twitter sense of the term, pulling current transactional data in as needed rather than working from historical data and relying on overnight ETLs. They’re heterogeneous, integrating a range of technologies as well as changes in business processes and employee workplace agreements, all brought together for delivery of the final solution. And, most importantly, they’re not standalone n-tier applications like we built in the past.

But while the IT world has moved on, it seems that many of our IT departments haven’t. Our heritage as application factories has us focused on managing applications, rather than technology, actively preventing us from creating this new generation of solutions. This behavior is ingrained in our organizations, with a large number of architects through project managers to senior management measuring their worth by the size of the project (in terms of CAPEX and OPEX required, or head count) that they are involved in, with the counter productive behavior that this creates.

In a world where solutions are shrinking and becoming more heterogeneous (even to the extent of becoming increasingly cross discipline) our inability to change ourselves is the biggest thing holding us back

The Value of Enterprise Architecture

Note: Updated with the slides and script from 2011’s lecture.

Is Enterprise Architecture in danger of becoming irrelevant? And if so, what can we do about it?

Presented as part of RMIT’s Master of Technology (Enterprise Architecture) course.

The Value of Enterprise Architecture