MemorableURL.com

Taking Innovation to Market

Agile go to Market Preparation

What motivates people to buy enterprise software. I remember Mark Lewis from EMC asserting that there are only three reasons:

1. To make money
2. To save money
3. To stay out of jail

I am a huge fan of this assertion; it keeps you focused on what is really important but note what is intentionally missing from the list…sex and sizzle, glitz and glam, shiny new stuff, etc. Consumer software often sells on this basis and it will get people in the enterprise to sit up and listen, it might get you through the customer’s door but it won’t get them to buy consistently and once the tarnish sets in, they will not be renewing contracts.

With innovative solutions you have to be able to deliver enough of a combination these three motivations to overcome the barrier to adoption. Note that customers typically see higher barriers to adoption for innovative solutions. Why?

Innovation = Disruption

A replacement solution or an add-on to an existing solution will typically be much more manageable than bringing in a truly innovative solution. In the short term, innovative will often beget new infrastructure, a learning curve, reassignment of resources, etc.. The results are often extremely worthwhile but someone needs to deal with the discomfort during the transition.

Practically what does this mean?

So, I took some time to develop a presentation on this topic looking at successes and challenges from some of the innovation that I have worked on over the past few years and came out with the following list:

 

Looks great, doesn’t it? No one can argue that these are all things that you need to focus on when taking innovative products to market but then one of my smarter colleagues pointed out that this list was just Product Management 101…I couldn’t really argue with that but with innovation it’s just a bit more important, difficult and requires a lot more discipline so we added this.

 

So, why is it different when you are looking at innovation rather than regular product development?

Impatience

When you are innovating you are typically a lot more excited about getting the product out the door. You don’t want to wait for processes and validation...”everyone is going to love this, why wouldn’t they?”

This impatience is the driving force of a good team, everyone wants to succeed, they all want people to start using the product, they are drinking the Kool-Aid 16 hours a day. It’s easier just to move ahead and have ‘faith’ that it will all work out.

Balancing this blind enthusiasm and the discipline of understanding the customer problems that you are trying to solve is going to be the difference between success and failure.

Confidentiality

IMHO, this is typically just an excuse rather than reality. There’s the fear that if anyone else finds out what we are doing then we won’t be first to market; that the competition will message ahead of us. This is all true, but as Mike Madden likes to remind me frequently, “there's never a right time to release the wrong product”.

If you can’t share what you are doing with at least a few customers then you’re taking quite a risk.

Lack of a Defined Market

This one is more real. When we released a “Cloud Backup for the Mainframe” product recently we were not entirely clear of the TAM – is it the $64 quadtrillion cloud storage market? Probably not. Is it the 5,000 mainframe customers worldwide? Sure. Now consider the segmented addressable market estimate based on the different cloud service levels available: who will tolerate public cloud, what about data residency concerns, bandwidth in different geos, etc. The addressable segment when tied to one technology is not always quite as clear.

However, you should take an educated and realistic guess and spend time looking at how much of the market segment you can address with each proposed product and/or release set.

Lack of Existing Customer Base

For some companies, this is a real problem. Without customers to call on under NDA, it can be difficult to validate your assumptions and pre-build a community of early adopters. That said, if you do not have access to customers during ideation and development then what makes you think that you will have some once you release the product? BTW, building a product in the hope that you’ll be acquired before you have to start to sell is not a great strategy.

So what should you do?

Engage with customers early in the process and stay engaged

• In Agile we engage with customers during development to validate the features in real time. For innovation, this level of engagement needs to start during the ideation phase, not just the development period.
• Don’t just validate your ideas – get real customer engagement. Do sprint reviews for the ideas as they solidify, present back to customers with a regular cadence; this gets them to ante up some of their valuable time not just “blind enthusiasm”
• If your customers are not willing to sign up and attend monthly reviews agree to take early drops then drill down and find out why. Be realistic – is the software really high value? The target should be to have customers ready to sign a PO and take the code into production the day that you go GA.
• Identify who you will be selling to in the organization. If you really are innovating then there’s a good chance that you’ll have to bring new people into the room. The CTO might have an interest, it might take a cross-discipline team to implement, etc. Open those doors early and create those relationships.

Give your sales team concrete information and have them test it early

• This is not easy when you are playing in a new space but it is essential. You HAVE to be able to show a customer that this solution really will pull sufficiently hard on one or more of the Make-Save-Liberate levers to offset the disruption.
• Make Money
  • Your sales team have to be able to make a convincing case that the solution will help your customer to actually increase profitability. Arm them with the market analysis and financials that you’ve done and with references from the reference customers.
• Save Money
  • You have to start this equation with real data about the current cost model. Then you work back from that to show that your solution will save XX% and have a YY month ROI period.
  • In the spirit of Agile, don’t spend 6 months getting a massively complex model in place only to find that you missed the opportunity. Create a model based on ‘some’ real data and then refine this every time it is used. You might start with only 3 data points on to work from but you’ll build this up rapidly.
• Stay out of Jail
  • I’d argue that fear is by far the most effective lever to pull…when you can. However, this is one area where you really do need to have subject matter experts in the process; you’d better understand the nuances of the regulations and risks if you are going to play this card.
• If you really don’t have concrete data then make an assertion to arm the sales with so they can at least start a conversation with a prospect – worst case, you will start to build out data and potential objections to address. Once armed with this – ask your sales team to commit to a quota for the product – this is the ultimate “bluff caller” for sales.

Train the sales team, get feedback, incorporate the feedback, rinse and repeat as necessary.

• If you can get a dedicate SWAT sales team who are (1) focused on the innovation technology and (2) only paid on the new solution then do this every time. It is costly because it is an overlay but it will speed up the sales processes by reducing barriers. Regardless, make sure that you have subject matter experts (SMEs) for the space you’re selling into. If they have a reputation in the space or come from a competitor in the space then all the better.

Provide a dynamic “objection handling” process.

• When a customer brings up an objection jump on it. Can it be addressed by agile engineering or not? If not then document the response and loop back to the sales team so they can proactively address it. Assess whether the customer is raising objections because they have a real issue or are just getting cold feet and looking for an out.

One softer aspect is the strategy for that product in relationship to your company or the market direction.

• There can be an advantage to being able to discuss how the innovation fits into a larger strategy for the market in general, how it fits into the customer’s company and how it fits into your vendor strategy.
• I’d say that generally this is not going to close a deal but NOT having it could easily stop a deal.

In all of these things create processes that can respond to change rapidly. Set expectations with the field that the message that you are giving them today WILL change as we get closer to releasing the product and that it will continue to change as we involve more customers.

The key to selling innovation is really no different to selling anything in the enterprise software space but the tolerance for missing the target is much lower.

Are all fingers thumbs? SaaS vs. Cloud as a delivery model.

I was reading a great Gartner article today about delivery of IT operations management tools and it has some very interesting observations related to the perception of SaaS vs. the Cloud. The question that got my attention related to whether SaaS and Cloud were the same thing. Of the respondents almost exactly one third selected yes, one third selected no and the remaining third went for “sometimes”. It’s rare that you see quite such an even distribution in any survey and it got me to wondering why it’s so ambiguous. The answer, it turns out, is actually found within the same article…

The definition is in the eye of the beholder

In my mind it is fairly clear – they are not the same. Let’s look at some examples:

• Both: Salesforce.com is software delivered as a service in the cloud. It has everything that you’d expect from a combination of these two things: software, pay as you go, self-service, elasticity, etc.
• Cloud only: Amazon EC2 is delivered via the cloud with the expected pay as you go, self-service, etc. but it’s not software…OK, it is software but it is platform/mid-tier software as opposed to consumer application software
• SaaS only: EMC’s Documentum OnDemand is a single tenant, hosted application managed as if it was a cloud solution but it doesn’t have those features generally associated with the cloud like multi-tenancy, self-service, etc.

Seems fairly straightforward when you see it written down doesn’t it? Except EMC touts OnDemand as a cloud solution and no one bats an eyelid, in fact as far as their customers are concerned they are getting Documentum “in the cloud”. Equally, consider that many people will deploy a standard instance of an EC2 environment and use the included middle tier applications, (e.g. the app servers and databases). To them EC2 is providing both SaaS and the Cloud.

So where is the confusion? It’s the same old chestnut that technologists fall fowl of consistently. From where we are standing the difference is startlingly obvious but from where the customer is standing the semantics are meaningless. I could argue until I am blue in the face that a single tenant deployment is neither SaaS nor is it Cloud, it is simply a hosted system but does a customer care about the subtleties? Typically the customer cares (or should care) only about one thing – meeting the terms of the service level agreement. They want a system off premise for very specific reasons and none of them should relate to the underlying technology details.

Let me illustrate this by defining the three models from the perspective of the service provider vs. the consumer of the service.

Term	Technologists say…	Consumers say…
Cloud	Multitenant, virtualized, self-service application with common, elastic infrastructure, pay as you go.	Cheap and cheerful
SaaS	Semi-standardized deployment of commercial application with partially shared services and centralized management and control.	Easy and customizable
Hosted	Single tenant, bespoke deployment of customized solution with dedicated services, storage, etc.	It’s mine, all mine

Seems like we are a little too focused on the technical details and missing the point…who cares? As the infrastructure and service providers we get all uptight about the semantics and we forget that the customer’s view is very different. We might was well advertise like this:

When the customer really wants to hear…

What should we do?

It is not breaking news that the reason that Apple have been so successful is not only that they listen to their consumers but that they present things in a way that grabs consumers’ attention. When Microsoft release a new hardware product they open with the specs of the machine…when Apple release a new product that hold it up and effectively say “ooh, ooh, it’s shiny and you want one” then they take your money, give you the product and THEN you work out what it is and how to use it.

I talk about the Mainframe as a platform for the Cloud (or SaaS/hosting if you want) but I need to remember to always return to the value that the ultimate end user of the system is actually interested in – it’s really, really reliable, it’s cheap and it’s fast. Odd though isn’t it? This description makes the mainframe sound a lot like a commercial for a Toyota Camry which is just not the vehicle you might compare a mainframe to normally.

So all thumbs are fingers but not all fingers are thumbs which adds zero clarity to this article but I just watched that episode of the Big Bang Theory and it seemed to resonate!

Agile is a company mindset not a planning tool…Part 1

I’ve spent over 20 years developing software, most of the time I’ve used some derivative of the waterfall methodology (aka, light the blue touch paper, stand back and then hope and pray). In my previous professional incarnation we started to use what we called an “Agile Methodology”. With hindsight what we really did was empower just the project management team to adjust our delivery and review cadence. Engineering and Product Management didn’t really materially change their approach to development. I suspect that this is because we saw Agile as just a modification of the waterfall approach’s scheduling to include risk as a factor rather than it being a change of mindset for all involved.

In my new role we are more fully embracing Agile, among the plethora of tools, training and information I have been reading Mike Cohn’s book Agile Estimating and Planning. Rather than summarizing the entire book I thought that I might focus in on the key things that stand out as differences between Agile and the more traditional methods for delivering software. Hopefully this will be useful for other software development professionals as they move towards real Agile development.

Part 1- Planning

• Planning upfront for a minimal acceptable product. In the classic “plan everything upfront” methods of software development everyone knows that something will be cut from the end product but no one will admit it and hence no one plans for that eventuality. In Agile you start the process expecting not to get every part of the proposed solution; given that expectation you get to plan for what you are going to give up, way before it becomes a critical issue. This is done by defining the “minimal acceptable product” and then knowing that anything else that is prioritized outside of that will be a bonus. 
• I need to think this one through a little more because you could run the joint risks of either putting too much in the minimal acceptable product plan or having engineering think that delivering just that minimal product would be OK and not aiming for additional features.
• Prioritize by comparative story size. Don’t worry too much about what a story is but suffice to say that it describes a feature that a customer wants in the product. The key here is that rather than asking engineering to estimate the effort to build each and every story we just ask them to put them in order of effort.
  • Try it sometime. Ask someone to estimate the comparative size, weight or value of three things and then ask them to estimate the actual size, weight or value of each. Invariably they will do much better in the former exercise. I am guessing that “The Price is Right” would not be the marvel of intellectual brilliance that it is today if all the contestants did was to say whether a piece of consumerized junk was more or less valuable than some other miscellaneous detritus.
• Don’t think that you can plan away uncertainty. Agile promotes planning on a more frequent basis, having brief daily reviews, planning for just an iteration and only planning the overall, high-level objectives upfront. Let’s assume that you could in fact plan away all uncertainty; the entire team leaves the meeting room at 2:30 on Thursday with a comprehensive plan in place. As soon as any one of them does anything – starts to code, installs a component, talks to the customer – the reality changed and your plan is no longer complete; change (like death and taxes) is inevitable.
  • Consider a house builder. Building a house is relatively simple; there are a well-established set of things to do, they’ve been done in pretty much the exact same way for generations and there are regulations that govern how the end product should be built. Your builder will come to you with a set of plans and a schedule…this is based on his estimate for how long things will take and when they’ll start. Builders pretend that they have planned away uncertainty and that’s the reason that we are all disappointed with builders – it rains, the cement truck blows a tire, the electrician is sick on the Monday after the big game, etc.
  • If a house builder can’t do it with the relatively well-established and finite process of building a house how is it that we think we can do it with something as nefarious as software development?
• Plan for features not activities. Most software development companies are primarily driven by engineering and many product managers started out life as engineers so it is natural that we’d gravitate towards using activities as our standard currency. Engineers think in terms of activities on a day-to-day basis. Agile says that we should use features as our primary currency when planning and tracking because customers do not care about activities, they care about delivered features. This is one of the changes in mindset that I talked about. Engineering can code activities but they need to think in terms of features that a customer needs.
• This reminds me of the move to decimalization that happened in the UK, (before my time I hasten to add). You have to believe that everyone in the UK knew that it made no sense having 240 pence in a pound, 12 pence in a shilling (hence 20 shillings in a pound) and coins such as the "half-crown" (worth two shillings and sixpence, or one eighth of a pound). But they were used to this system and the idea of a change was logical but disruptive. We need to get the entire company to embrace the decimalization of software development.

• Failure to deliver is acceptable, failure to commit is not. This is so common in the non-Agile world. I am going to be uncharacteristically honest here, this one made my blood run cold because I have seen and done this way too many times in the past. When you see it in black and white it makes you wonder why you didn’t do a better job of fighting it.

• Here’s how it goes…your manager or the SVP of sales calls up and says, “When will the product go GA?” You explain that you don’t know yet because of the unknowns and you’re told, “Just give me a date so I can close the deal, it doesn’t matter if it changes later”.
• True to their word, it is OK when the product does not ship on time. I’ve seen products (not mine) with a 1 year schedule ship two years late and no one be terribly surprised. A consequence of not understanding the minimally acceptable product? Of upfront over planning without understanding the unknowns? Of building activities not features so never ending up with something shippable? Of not understanding who the real user of the system was and their needs?
• Probably a combination of all of these…

Conclusion

This is only looking at the first section in Cohn’s book but it already points to the fact that in order to be successful with Agile you need to get buy-in (not just acceptance) from the entire company not just R&D – sales, senior management, marketing, etc. This is a change of mindset but one that truthfully embraces the pragmatic lessons learned from trying to use rigid planning and delivery techniques on a process that is so unpredictable.

In product management one of your new responsibilities it to communicate to the entire team what the customers looks like, what they are trying to achieve, what motivates them and makes them happy. I pretty much guarantee that if the engineering, marketing, tech pubs and especially QA teams do not understand the customer then they will not be able to code features effectively.

Stay tuned for part two – it is due next time we get a rainy day in New Jersey.

Developing Personas for Software Development

This entry is about using imaginary friends to help you develop better software.

I am reading “The Inmates are Running the Asylum” by Alan Cooper. It is not a new book but the particular parts that I am interested in are as relevant today as they were in 2004. Specifically, Cooper’s premise is focusing on “who” we are developing software for as the quintessential component of the design process.

The key tool is the development of personas. A persona is not a real person but is representative of a specific type of user for the product. The idea is to build a picture of a typical user in a specific role. Depending on the software you are building, you might end up with personas for the end user of the product, the system administrator, the IT coordinator and a C-level person.

For each of the personas you will describe them as an individual; the personal traits, age, marital status, their career path, their work goals. Cooper says that it is more important to be detailed in their description than it is to be absolutely correct. I think that the idea is to build out an image of a real person, even if that person is not absolutely indicative of the target user.

Having built them out you need to select one to be the primary persona. This is the user whom you will satisfy above all others. The general premise is that if you can meet 100% of one user’s needs you will be successful. This might seem counter-intuitive until you think it through…if 100% of your users get 30% of what they need then they’ll all be unhappy. If 30% of your users get 100% of what they need then they will love your system and will be on your side when evangelizing the use of the system. Remember, giving 30% of your users everything that they need does not mean that the other 70% get nothing at all.

Before we address how to use this practically let’s just address something that I found particularly difficult at first…the voyeuristic aspects of creating personas…

The Personal Lives of Fictitious People

The idea of building out all of the personal, seemingly superfluous, details of each persona seemed odd to me at first. In fact, in my first attempt I added comical traits and odd peccadillos rather than realistic hobbies etc. My British cynicism stopped me taking this seriously. However I realize now that the reason for adding non-work-task-related traits is to bring the personas to life. It is much easier to imagine a fictitious person’s wants when you can identify with them. It’s harder to identify with the one-legged, kite-surfing, amateur-def-poetry-reciting, head of cloud services that I described.

Practical Application

If you only did one thing with the personas it would be to stop anyone on the team using the word “user”. Have a swear jar for each time anyone says user(s)…instead be specific. Say “Bob” or “Doris”.

Why? If I say “a user might want to approve the requisition from a mobile device” then it is hard to argue that this is not realistic. It is true…some user, somewhere, sometime will want to approve something from the 10^th hole. The question is whether your primary persona, the person you are designing for would. If Bob represents a customer service function and is desk-bound in a call center then Bob has no need to have a mobile interface. The fact that other ‘users’ might want to is irrelevant.

With a clear primary persona you can have a well-formed discussion with the team without arguing your position – you are arguing Bob’s position.

There are two specific and related things to watch out for when assigning wants to a persona.

1. The first is what Cooper calls “elastic users”; in this case, you are “stretching” what the user might want. This might be because you really want to add something to the design and are trying to convince everyone that the primary user would want it. It might also be because you have not fully formed the user and there’s some wriggle room around their wants, needs and desires!

2. The second is building for the non-primary personas. It is OK to design something that a non-primary user might like but only if the primary user needs it.

I struggle with the second, supposedly immutable rule. It seems like there are a lot of times that a feature might appear to make a product easier to sell, easier to manage, easier to integrate, the feature might meet an internal, strategic initiative. If your primary user is the end user then they may not care about any of these but as the product owner it is hard to resist temptation to add “just one more” of this type of feature.

Authors typically write in absolute terms (or should I say that they always write in absolute terms) but really the personas should be a guiding principal not an immutable truth. As a tool to get everyone focused then I think that personas are very valuable.

Bottom line, I’d commend the use of personas across the entire R&D team to any software (or hardware) developer.

Book review: Inspired by Marty Cagan

Book reviews are not my normal type of content but I just finished reading a great book on product management and thought that I'd share some of the highlights.  The book is called "Inspired" by Marty Cagan; I'll list some actual highlights below but the main reason that you should read this is that Mr. C actually has opinions and expresses them clearly, no pussyfooting around with if, buts and maybes. He does this in a fairly concise way, the entire book is only ~200 pages but it covers a huge amount of content. You could easily knock this one out in a coast-to-coast flight or even during the delay before boarding depending on your choice of airline.

If you are cheap, short of time and manage enterprise software then pop into B&N, grab a cappafructousino and read just chapters 38, 40 and 41 before sheepishly returning the book to the shelf...or maybe buying it.

The focus of the book is definitely on the up-font planning processes rather than the actual delivery. He does cover the move into general availability but with less detailed chapters, still relevant but not as packed with good advice as the planning section is.  This seems fair given that it matches the balance you should have in the product lifecycle.

Key messages:

• Try not to be put off the real goal of the product by one-off customer requirements or shiny things. As he quotes..."the main thing is to keep the main thing the main thing".
• Keep innovating, before you finish up the current release start planning the next release and include innovation before the backlog fills up with bug fixes, refactoring and customer-specific requirements.
• You need all of these but as Bill Gates said to FOCUS magazine in 1995 "We don't do a new version to fix bugs. We don't. Not enough people would buy it. ... You won't get a single person to say they'd buy a new version because of bugs. We'd never be able to sell a release on that basis."
• User design is key to success
• He doesn't say it explicitly but this didn't used to be the case for enterprise software where we got away with some appalling looking but functionally brilliant solutions...at least I did anyway).
• Personally, I'm not sure where to go with this in my new mainframe home where most people still think that the VT220 was a major step forwards in UI design because it added green or amber text to the previous white-only choice of the VT100 (yes I am old enough to remember this).
• In the spirit of user design you should identify distinct fictional characters and build the solution to suit their specific needs.
  • Learn from my mistake, choosing Dr. Sheldon Cooper, Martha Stewart and the Dali Lama was probably over ambitious. Go for people representative of those with a budget and a business need instead.
  • Seriously though this is good advice, base them on real target customers and then validate your modeling.
• The #1 trait to look for in your product managers is passion...this is not a segue to a 50 shades of grey book review but an indictment of the role of a product manager as the CEO of the company (Chief Evangelizing Officer)
• Interestingly he does not advocate the need for product managers to initially be experts in the technology that they delivered products for. He feels that passion, intelligence, integrity, etc. are more vital.
• Having just moved into a role working with alien technology I can see both sides of this. There's a huge learning curve when transitioning but your mind is completely unfettered by nasty things like facts or history!

Specifics

• Marty's a big proponent of not spending huge swaths of time writing detail documents  (that nobody reads). He likes the agile approach, prototyping and early engagement with real customers.
• Don't confuse the following roles although to be fair I've worked with some product managers who add a lot to these adjacent disciplines.
  • Product management and product marketing. 
  • Product management and project management. 
  • Product management and user experience design
  • Product management and engineering
• One great idea in the book is to have product management give engineering a 20% "budget" every release cycle to spend as they see fit. This gives them control over what refactoring etc. that they want to include and managed well will stop the situation when an entire release cycle is given over to nothing it refactoring (customers hate that btw). It's a nice idea but you have to trust that engineering won't over allocate.
• Marty seems to advocate the use of NPS to measure product success. I like the NPS system but would caution that the company's NPS is greatly affected by many factors outside of the direct control of the product management role: tech support, field facing staff, etc.

The only areas where I'd like to see Marty expand is around use of data and facts, not opinions. This is absolutely the best advice but is very hard to do especially as you plan for innovative products heading into unchartered territory.

He also advocates allowing key people to spend 20% of their time thinking about innovation if you work in a large organization where innovating is more difficult. I'm not sure that I entirely agree with the premise behind this. I've worked in some huge organizations and none of them have been anti-innovation. In smaller companies everyone is innovating for sure but they are typically so stressed out innovating on their "one big thing" that they don't have the luxury to spend time on other innovation.

Bottom line is that the book is definitely worth reading and probably even using as a reference on an ongoing basis. 

Session Abstract - Lessons learned from addressing the inevitable.

I was asked to submit a topic for a cloud-related conference, I'm thinking of "Lessons learned when moving enterprise software from a conventional deployment model to a cloud-based model." Obviously I'll need a snappier title like "What were we thinking?", "Please Lord make it stop." or maybe “Lessons learned from addressing the inevitable.”

Specifically the session will relate to companies selling enterprise software and are going to start offering their solutions in the cloud or service providers looking to sell 3^rd party enterprise applications in the cloud.

I’ve attended these “lessons learned” sessions in the past and prefer the ones that basically list all of the things that you need to watch out for with general lessons learned. In the world of enterprise software knowing the specifics of one company’s experiences is not always germane to other deployments. To that end I’m going to focus on the actual issues and some hints on how to avoid them. Here's my outline...I'm going to blog on each of these over time to help me to solidly my thoughts. I’ll add to this as I go.

Internal issues to address

I'm starting with “internal issues” because IMHO these are far more difficult to deal with than the technical ones.

• How will you compensate the field when you move to a SaaS model?
  • Any subscription-based pricing looks less attractive in the short-term to the people being paid on revenue.
• Re-educating the field on what a move to SaaS means.
  • Don’t underestimate the effort in undoing all of the “big sale” indoctrination that you’ve instilled in the team.
• Deciding which customers/use cases to go after first.
  • If you elect to go “cloud” not “managed service” then you are going to have to apply restrictions on how your customers use the systems. How will that change your GTM model?
• Deciding when/if you'll stop supporting new conventional deployments and existing conventional deployments.
  • Will you continue to sell a non-cloud version of your software? This is not a trivial question, the timing is especially important.

Technical issues to address

I'm intentionally not addressing HOW to get your non-multi-tenant solution into the cloud, that's the topic of many other sessions. I'm focusing on the other issues that you'll need to address after you've done it.

• Migration offering for existing customers.
  • Don’t just think about data, think about processes, policies, monitoring, integrations, etc.
• Convincing your customers that your offering is secure, performs well, will integrate into their existing systems, etc.
  • “Confidence”…your customers know how enterprise software deploys today. They may not like it but they understand it. You need to convince them that a move to “less hassle but less control” is going to be a benefit.
• Service levels
  • Customers will have preconceived ideas of what your service level objectives are. Up-time, high availability, data replication, location of primary and backup data centers, performance, etc. These cause work for legal, the deployment teams, the ops teams, pre-sales, etc.

Things you never thought of

• Contracts...you might have enterprise agreements for software and services today but I'll bet that they will not work for your cloud customers.
  • Don't underestimate this one; it is where all of the other issues come to the surface. Why? Because not someone needs to sign a piece of paper that says that what you are offering them will meet all of their needs…and that’s scary.
• Managing the transition from conventional to enterprise.
  • How are you going to manage the transition to a cloud service provider? Will you go "all in" and rebrand yourself as cloud supplier (alienating your current customers), be low key with your cloud offerings at first (letting your competition take the lead), will you start a new organization for the cloud solutions (creating internal strife and completion)?
• Delineation of responsibilities - who exactly is responsible for what?
  • You will have a contract to supply a service to your customers but there will always be a grey area. You will run the servers and they will consume the service. Easy, yes? But who will create users, who will do end-to-end performance optimization, who will monitor usage, etc.?
• Selling…internally.
  • There will be resistance to a move to the cloud and not just from the customer base and the field. You might get push back from engineering, senior management, internal operations, etc. You need to spend an equal amount of time getting buy-in internally as you do selling to your customer base – at first that is.

Objections that you need to be able to handle

• Security. This is the number one objection that you need to be able to answer. How can I be sure that my content is protected and will not be lost?
  • One specific question - who has access to the data and where will it physically reside? This might relate to compliance as some data needs specific levels of protection, (e.g. UK health data, German tax data.) but in many cases this is actually just “justifiable paranoia”.
• Latency. You are moving a service out of a customer’s data center and they’ll want to know how that will affect performance. In my experience it is actually often better – latency is a minor tax on performance in comparison to the gains in having a well-managed, optimized service running on a major piece of hardware.
• Enterprise connectivity. If the customer has systems inside their firewall that need to connect into your service – public, private or hybrid then they will need to know how that’s going to work…and how well.
• Customization support. If the customer has “special” needs that involve making a change to their base environment then how will you handle this, if you will even allow it. 

Cloud Computing Business Considerations - The single most important document

We are doing some advanced training for the field this week on how to sell ECM in the cloud now that all of the pieces are in place and customers are using it for real. At least that's how we advertised it internally: "advanced training". As I was sitting in the United lounge in DC waiting for my 6 hour delayed flight to Atlanta I got to thinking about the "advanced" part of that.

It seems that 12 months ago when we were embarking on this crazy plan I had this huge list of potential issues. I started to blog about them to bring clarity to the tasks. I was considering pricing, services, deployment models, geo-location-related issues, delineation of responsibilities, etc. 

Now I struggle to remember what exactly the mystery was. We just educated a room full of experienced account managers with all of the things that they need to understand it in 2 hours. In fact, the only issue that seems to cause anyone any heartburn relates to reconciling the contract for the cloud services to the other contracts that customers have. The rest of it seems so straightforward now.

So what made it simple all of a sudden? IMHO, it was the completion of one document –  the services brief. This is a document that explains all of the things included in the cloud offering. The components of the system, security considerations, connectivity into existing systems, the initial build information, roles and responsibilities, how upgrades are handled, details of HA and DR, support management, service level objectives, etc., etc.

All of the technical issues turned out to be things that we needed to solve but that our customers don't need to worry about. Once we created implemented everything in the services brief everything just fell into place.

• Return on Investment: we use the services brief to show the customer what they are getting for their money. They use this to compare the cloud costs to their internal costs.
• Contracts: we attach the services brief to the contract to show what is included.
• Security: the services brief shows all of the components related to security, DR/HA, audit, reporting, etc.
• Delineation of tasks: if it's not in the services brief then it's your problem Mr. Customer.
• SLOs (Service Level Objectives) : most of this is covered in the services brief although the contract forms a key part of the SLO because it is an official agreement.
• License ownership: ditto...you get the idea.

It's not the only document that you'll need, it does not cover everything…the system setup, pricing, terms of sale, etc. but once you have it everything else falls into place pretty quickly.

This document also serves as an important reminder that as a customer you don't need to worry about the "how", just the "what" you get. Armed with the services brief, a contract and a price you are good to go. Maybe there's some minor network config work, some setup or migration but basically the services brief is the core to your agreement with the provider.

Now I'm going to work out how to index my articles without the god awful table of complexity that I used back when this all seemed complicated. My next article..."Why on earth would anyone implement ECM on premise for a new deployment?" ;-)

Cloud Computing Business Considerations - Pricing Models

Some people think that the difference between "a cloud deployment" and "a hosted service" is how the payment plan is structured. They imagine that if you have no capital outlay and just pay a SaaS usage-based monthly fee then you must be using the cloud. If only the definition of a cloud solution were that simple, there's a lot more to it than that including any definition that suits a vendor wanting to milk the current gravy-train.

This SaaS pricing seems like a nice model but it is pretty much the same model as leasing or renting a car. When you buy a car *you* are financing the capital cost of the car and you own it outright. When you lease or even rent a car someone else is financing the car and you own nothing at the end of the term, also you are eventually covering the cost of the third party financing it.

In many cases this is a great model but for enterprise software running in the cloud you might want to consider alternative models before getting out your credit card.

First let's assume that the software you are looking for is available to purchase in a conventional (non-cloud) model. Some systems are only available as SaaS offerings so you have what folks in the UK call "Hobson's Choice". If you can purchase the software licenses then there might be advantages to you buying the software outright and paying a lower fee just for the cloud hosting piece. Why?

• You may already own licenses to the software so why pay twice? Of you've already paid for the software then it might be more cost effective not to take SaaS pricing.
• It might be less expensive over the life of the project if you purchase the software outright rather than allowing the cloud provider to finance it.
• What if you want a hybrid deployment where you have some systems in the cloud and some on-premise? You'll need regular licenses for the latter anyway. This is a business case that I am seeing more frequently than I'd expected. It is driven by legacy deployments, schedule issues, geographic constraints, regulatory issues, etc. 
• What if you decide to back out out cloud and want to move the entire system on-premise? This is low probability and might just be addressable "if and when".
• You might prefer Capital Expenses over Operating Expenses, (really...some US federal agencies have CapEx budget but don't have OpEx!).

Conclusion

Sometimes there's no option but to purchase a solution with SaaS-pricing. In the future the SaaS model might be ubiquitous but today as we transition to Cloud delivery you might want to give this some thought to the options before jumping in.

IIG’s Acquisition of Syncplicity for Sync and Share. What’s that all about then?

So I am sure that you have heard by now [Press Release] that EMC IIG (the group that brings you Documentum) has acquired Syncplicity which is a company that provides a SaaS-based ‘sync and share’ solution.

OK, so here’s what I know…and my interpretation of what’s going down. Remember that this is reflects my personal thoughts on the announcement not the official line. Also note that I was given advanced notice of this acquisition but not much notice!

Firstly, in line with the rest of the IIG products the key audience is not the consumer market; it is the core Enterprise market. The offering is differentiated from the other 20 or so Sync/Share solutions out there because it seems like it was engineered with the features that IT, the businessand end users ask for. For example, I know that a lot of the more consumer solutions out there are actually blocked by corporations’ IT departments because they don’t provide the control or security that IT and the compliance groups need.

At first I was a bit confused how this acquisition aligned with our definition of “ECM” but then I realized that by specifically selecting Syncplicity it aligns pretty well with the three key focus areas of the business. You might know that the IIG strategy for the last few years has been the move to the Cloud, a focus on the New User, business transformation and pervasive governance. Syncplicity’s focus on an enterprise approach to Sync/Share actually aligns with all four of those focus areas.
So what do I mean when I say that this is an ”enterprise” solution as opposed to a more consumer solution? From what I know, the Syncplicity solution adds a lot of the elements that the IT and compliance groups need:

- More security,
- Bandwidth throttling,
- Some serious encryption
- Remote wipe
- SSO
- Ability to scale
- Support for a wide selection of platforms
- Customer controlled policies

It also integrates into a lot of the enterprise suites in play today and seems to work without actually changing the way that the other solutions work leaving the files on the desktop or file server just as they are today – SalesForce, SharePoint, Google Apps and Google Docs don't change for the end user at all. I am going to wait for more official communications have been crafted before I comment on how this might affect the core Documentum suite but I think that it can only be positive for the business.

Interesting times indeed…

Cloud Computing Business Considerations - Dealing with Data Center Placement

In this article I will consider where geographically you might want to host your cloud-based systems. The world’s a big place and for many organizations deciding where to host systems is a complex issue - with or without the cloud. For commercial convenience organizations tend to break the world down into three areas – the Americas, EMEA and APJ; I'll use that same model.

Coverage in the Americas

It is fair to assume that if you placed a data center into the central USA then you’d be able to offer decent coverage to 80% of the commercial opportunities in the Americas region. You would not be geographically central but you would be close to the majority of the opportunities in the region; that’s the reality of the distribution of commerce across the landmass. Place 2 or 3 datacenters throughout the region and you will have pretty much the entire area sown up.

From a compliance perspective many customers in Canada and Mexico are willing to tolerate a US-based data center when their local regulations allow.

Coverage in EMEA

For EMEA you have a similar model; place a data center in mainland Europe and you can probably offer your service to the majority of the region’s commercial opportunities. Again, distribute 2 or 3 data centers in EMEA and for sure you have cornered the market. I get that Johannesburg is a good 6,000 miles from Helsinki but commercially the key opportunities are centralized around mainland Europe. The EU has also passed a number of regulations to manage the distribution of content between countries. 

Coverage in APJ

APJ brings its own set of challenges. Like EMEA and the Americas it covers a vast area from the southern hemisphere to the north. However unlike in the the other regions, in APJ the distribution of commerce is more even. So placing data centers in 2 or 3 locations does not give you the 80/20 coverage that you might see in the other regions.

More of an issue than the geographical distribution of commercial opportunities is the lack of unity between the countries. In the European Union there are laws that allow for the sharing of protected data between member countries, in many cases this might allow for a centrally located data center to host systems used across many countries. In APJ the story is very different:. A company based in one country may legitimately refuse to have their data stored in any neighboring country because they want to have certainty around who has access to the data and they cannot control another country’s laws/administration.

I started writing this article on a flight back from Hong Kong. Hong Kong is part of China albeit they call it a SAR (Separately Administered Region). I asked whether the customers based in Hong Kong would use a China-based data center. The answer was “absolutely not”. I asked whether Taiwanese customers would use one in a China or Hong Kong – “nope”. Japan using Singapore? India using Australia? Australia using New Zealand? No to all… The only concession that I heard was that some of the customers based in southern China regions might consider using a Hong Kong-based data center but not those based in the northern regions ;-)

Similar issues also exist in EMEA and the Americas with specific content types and specific regulations where data needs to be kept locally but it is less common.

So, what’s the solution?

Change the laws/regulations/perceptions

The truth is that many of the regulations that we are trying to adhere to were not written with today’s distributed architectures in mind. No one was thinking about accessing systems from smart phones, desktop virtualization, delivering anything “?aaS”. In fact many of the regulations were focused on access to physical assets not electronic distributions. These laws need to be cleaned up and made relevant to today’s technology. We need laws that protect data adequately in a way that can actually be implemented and monitored at the scale that we see today.

Have local deployments

The reason that non-cloud deployments do not worry about these issues is that the systems, the data and the staff are typically all deployed within a single country. So, if your cloud service provider will guarantee that your systems and data are in a cloud data center in-country then you are no worse off than with a local deployment.

This is often not the case, especially with the larger more ’generic’ providers. However, some cloud service providers (I should in good conscience mention that the EMC project I am working on does support this model) will allow the systems to reside in a local datacenter or even in your own datacenter. You might wonder how this can be a cloud solution if it is not “out in the ether” in a multi tenant environment? A local, single tenant instance of a system certainly loses some of the features of cloud deployment but it can retain some of the key ones too. Assuming that you host the cloud solution on a shared physical stack you can still get elasticity associated with a shared infrastructure through virtualization. If the cloud service provider will still manage the system remotely and provide the system as a local “black box” then this might be a compromise worth considering.

Use technology to protect

Let’s take a different tack. What does the regulation really say, or really mean? Let’s say that the data was physically stored in a different country but could not be accessed by anyone there. Would that satisfy the intent if not the letter of the regulation. If you stored your data in an encrypted form and only allowed the decryption to be done by people within your home country then you might be able to meet the actual requirement. Digital Rights Management (DRM) would allow for this out of the box today.

Another advantage of DRM is that it protects data in the cloud but it also protects it when it is taken offline. If you download a DRM protected document to your smart device the local application could in theory still protect it…imagine, it could do a quick retinal scan to identify you, look at the GPS coordinates to see where you are and then decide whether to give you access. Orwellian or what?

Don’t use the cloud for that type of data

The reality is that today the cloud is not a panacea for all content, in all cases, in all locations. In five years it will be the de facto delivery system for most applications but maybe not quite today. You might decide to keep certain systems locally for now until things mature. My advice however is not to throw the baby out with the bathwater. Just because some systems might not move into the cloud today doesn’t mean that you cannot move others. In fact, take the opportunity to offload the less critical systems into the cloud and focus your management efforts on the remaining systems.

Conclusion

You are going to have to be creative and flexible if you are concerned about any of these issues. These boundaries exist because of infrastructure, physics, lawyers and politicians. Infrastructures will evolve, physics can be manipulated (we almost had Neutrinos traveling faster than light recently) but the lawyer/politician thing isn’t going to be solved any time soon.

Truthfully, this is just another indication that the cloud is still maturing. It is growing up much faster than the surrounding practices, laws, regulations and culture These growing pains are going to be a challenge for a while longer...