I am off to Dallas again this week to help with a software sales ROI presentation to the executive team. I was browsing some other ROI sites and found Glenn Clowney’s articles particularly interesting. His articles on the topic are right in line with my experience. Among his findings:
- 81% of buyers expect vendors to quantify the business value of their product or service, meaning 60% more projects are likely to be approved (Information Week).
- According to an Ernst & Young study, only 2% of the buyers say vendors are exceeding their expectations for ROI justification during the sales cycle. This means 98% of the time sales professionals miss an opportunity to win the deal.
I hope we fall into that 2%. Keep up the good work Glenn.
I love the recent article by this title on CBR online. It quotes Gartner’s Michele Cantara as saying that companies who are prepared to ramp up their BPM investments now will be better poised for growth when the economy recovers. A recent Gartner surveys show spending on BPM is expected to increase by 5% more over the next 12 months. Gartner believes BPM has been a top CIO priority for some years, but that lately its importance has been elevated because BPM projects “act as a catalyst for cutting costs, improving productivity, accelerating business performance and bringing business and IT together.”
Cantra recommended that organizations consider BPM by prioritizing existing projects, and determining how any suspended or new projects should be prioritized, sequenced, funded and staffed for the return of business growth.
I agree. Start with a strong business case and BPM projects become an easy investment to justify. I am currently working to document ROI for two large BPM projects. It looks like the first will have a payoff in less than 6 months and the second even faster. In a time when many companies are deferring IT investments, these two companies are committing to invest in BPM to gain savings and competitive advantage. The business case is too compelling to defer commitment.
My brother sent me an email the other day asking the above question. As I thought about my reply, I really did not know how to answer him. I think he was asking where I host my business web site, but I use the cloud for such a variety of things today and the offerings continue to grow each day. With that thought in mind, I am posting an updated version of a strategy paper I did a few years ago. This is expanded from an original post by Marc Andreessen. (I miss his excellent blog.)
He suggests that there are three different levels of web “Platforms.” Platforms are: “Any system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate… If you can program it, then it’s a platform.”
I’ve modified his take on the levels to include from web offerings that do not quite meet the “platform” definition to those that go beyond his definition. I will discuss each in more detail:
- Level 0: Stand alone Applications – Applications that run on the web to provide functionality limited to what is coded by the application provider.
- Level 0.5: Mash-ups – Let developers gather web information for publishing to other applications without using a formal API.
- Level 1: Access API – Provide access to functionality using an access protocol such as SOAP. The developer’s application code lives outside the platform and calls into the platform via the API to draw on data and services.
- Level 2: Plug-in API – Lets developers build new functions that are injected, as a “plug in”, to the core system and its user interface. Again, the applications run elsewhere, but functionality displays on the platform via a plug-in API to their interface.
- Level 3: Runtime Platform – Provides a framework for developers to build and run applications on the web. A developer’s application runs online, inside the platform itself.
- Level 4: Infrastructure Services – Provides resources through the web to be used for computing power.
Over the last couple years, these levels have blended and many offerings have components that blur the lines. I think it is still useful for users, developers and platform providers to consider these levels and how they can push offerings to higher levels when appropriate.
0 – Stand Alone Applications:
I talk about this category to demonstrate what a platform is not. Stand alone or Software as a Service (Saas) applications do on the web what desktop apps did in the past. They are used to write a letter, calculate an equation, store files, track time and money, etc. They may have some configuration, but for the most part, they do what the developer told the application to do when it was created. Some of the popular stand alone applications I have used are shown below and there are many, many more.
The interesting thing about stand alone applications on the web is that most of them allow you to work not alone. While the desktop can be a tricky place to share and collaborate, the web naturally lends itself to sharing. So, these applications often allow for multiple users or the ability to invite others to look in or work along side of you. Some exist for the sole purpose of allowing collaboration.
Pros:
- Access from anywhere
- Collaborate easily
- Can often upload and download data and docs
- No need to install or support software
Limitations:
- Limited configuration
- Customization & new features only through provider
- No integration capabilities
- If company dies, so does application & potentially data
0.5 – Mash-ups:
I added this category to allow for building platforms that interact without any formal API provided by the platform provider. The applications using this approach run outside the host environment and extract information from the platform application. I put REST and RSS in this category because they don’t require coding by the provider to expose and share information. Screen scraping is another technology widely used when formal API’s don’t allow information sharing. Applications and development environments to streamline creation of secondary applications using these approaches take advantage of these techniques.
Pros:
- Creates access to web information without customized API’s
- Allow for data portability across the web
Limitations:
- Building the application structure is left to the developer
- Or, need a reader, other web platform or custom code to render and run
- Distribution largely left to developer
- Can be brittle
- Limited capabilities
1 – Access APIs:
Access API’s allow third party developers to call into a platform and request specific information or execute functionality on the platform. This was the first and is still the most common way to access platforms on the web. More and more applications are exposing API’s to share their functionality (often called web services.) The exposed functionality can be very rich. When third party sites use PayPal to settle payments, share shipping information from UPS, show custom data on a map, or share pictures from Flickr, an API is being used.
Pros:
- Makes useful functionality available to 3rd parties
- Easy to access platform
- May provide coding assistance through Software Development Kits (SDKs)
Limitations:
- Building the application structure is left to the developer
- Running the application infrastructure is left entirely to the developer
- Burden of distribution with the developer
- Aside from the API structure, no standards for the developer
2 – Plug-in APIs:
Plug in API’s are Windows for the web. The display side is managed by the platform, but what runs behind those windows are run by the application. Facebook is perhaps the best know early example of this type platform. While Facebook makes some access API’s available to its developers to share social information, it has also gone a step further to provide the presentation for the applications that use those API’s so that they show alongside of native Facebook functionality. They also provide a distribution capability that aids with finding and installing the applications running on the platform. Beyond that, the applications are hosted and supported by the developer. Other examples are found on the recently released Ning apps (though they aspire to be a platform service themselves) and the numerous widget platforms across the web.
Pros:
- Get common look and feel
- Assistance with distribution
- Some standards applied through SDKs
- Can create code sharing
Limitations:
- Building application structure is responsibility of the developer
- Running the application infrastructure is left to the developer
- Application is not available if platform dies
3 – Run-time Environments:
Run time environments are the most complex platform available on the web. Sometimes called Platform as a Service (PaaS) some run-time platforms offer extreme configuration flexibility focused on a specific horizontal. Others are coding environments with all the flexibility of desktop Application Frameworks. Perhaps the best know of this type platform is Salesforce.com’s. While their core offering focuses on Level 0 CRM application, the force.com platform is a complete runtime environment that extends that capability. Platforms, by their nature must offer all the levels shown below their Application Exchange: 
The Application Exchange extends the platform by offering a distribution and revenue generating mechanism for the applications created on their platform. Other run-time platform examples are shown below. My favorite is 2nd Life – though it requires a fatter client, it meets are the requirements of a cloud runtime environment.
Pros:
- Provides development tools and framework
- Provides infrastructure
- Provides runtime environment
- Can assist with distribution (marketplace/exchange)
- Can assist with code sharing/templates
Limitations
- Difficult to build as a provider
- Difficult to run as a provider
- Standards are still young and changing
- Can be complex to learn
- Configuration and code control is challenging for developer
- If platform dies, so does application & potentially data
4 – Infrastructure Services:
Infrastructure offerings (Infrastructure as a Service or IaaS) provide only the back end computing power of a platform. Services provided includes CPU, load balancing, DNS, bandwidth, memory, file storage, and database. These offerings differ from managed services in that they typically use virtualization to easily scale the infrastructure capacity provided based on user needs. They typically service multiple clients from a single facility using a scalable cost structure. Coding stays locally managed in a client environment and then code is deployed to the cloud infrastructure to run. My web hosting provider is a mid-range provider of Infrastructure Services while Amazon was early to offer them on a enterprise scalable level. Other examples are shown below.
Pros:
- Provides scalable infrastructure
- Can be configured for almost any use
- Cost effective to scale from small to large
- Code is typically independent of the provider (though some services now use special protocols)
Limitations
- Can be complex to learn
- Configuration and code control are developer’s responsibility
- Can have hidden complexities to manage
Cloud computing has been held up as the next great leap organizations should take. Yet, I see few using these offerings for other than standard applications, pre-built features and some non-critical and departmental applications. Customized enterprise applications and those that offer competitive advantage are rarely built in the cloud today.
The draw of the cloud are many. In George Reese’s book, Cloud Application Architectures published this April, he draws the following comparisons:
From this, he concludes:
The one obvious fact that should jump out of this chart is that building an IT infrastructure from scratch no longer makes any sense. The only companies that should have an internal IT are organizations with a significant preexisting investment in internal IT or with regulatory requirements that prevent data storage in third-party environments.
Everyone else should be using a managed services provider or the cloud.
And, after more analysis:
If we exclude sunk costs, the right managed services option and cloud computing are always financially more attractive than managing your own IT.
If you have an application that you know has to be available 24/7/365, and even 1 minute of downtime in a year is entirely unacceptable, you almost certainly want to opt for a managed services environment and not concern yourself too much with the cost differences (they may even favor the managed services provider in that scenario).
On the other hand, if you want to get high-availability on the cheap, and 99.995% is good enough, you can’t beat the cloud.
Certainly, 99.995% availability is greater than most internal or even managed service organizations achieve. So, what will it take for enterprise IT to fully embrace the cloud as a development architecture? Let’s look at a few counter points to Reese’s analysis that cause friction.
Many organizations see the perpetuity cost model as unfavorable. While total cost of ownership within the first 3 or 4 years usually wins for the cloud, many organizations don’t like the longer-term analysis that often favors traditional models. Accounting rules also penalize pay as you go models.
Security concerns and concerns over the cloud provider’s reliability and viability make enterprises uncomfortable with relinquishing control of their critical data and unique functionality even if permissible by regulations. Examples show that data privacy may be at risk. Data can be lost. Downtime can be unexpected and prolonged. While all of these are possible with other architectures, the perception is that they are greater in the cloud. And, if a provider does go away, the entire infrastructure could need to be recreated quickly at very high costs.
Reese skirts perhaps the biggest issue – sunk costs. He mentions this from a financial perspective, but the sunk costs are many and are hard to over come. Enterprises have sunk costs in terms of legacy software, legacy data, legacy skill sets and existing infrastructure. Many enterprises start with packaged applications which do not fit well into the cloud as the basis for their customized offerings. Even if package conversion was easy, enterprise applications typically have many custom features that need to be re-recreated for the cloud. Organizations also often need to convert their existing data to new formats to use these applications. Cloud architectures are poorly understood and few resources know how to work with them when creating applications. New skills are needed, even if by fewer resources, to manage, configure and customize cloud applications. These are in addition the the main sunk cost: using still available, depreciated assets can be too enticing to make the leap.
The cloud will one day be a force for enterprise IT. Early adopters have show benefits with non-critical applications and we see many examples of architectures taking the first steps by exposing and utilizing web service API’s to extend offerings. Many start-ups have benefited from the low entry costs for building new businesses. But, it seems to me, that until the benefits become more magnified, or the counter points to cloud architectures are minimized, larger-scale enterprise adoption will be slow for core applications. Someday, everyone may program in the cloud, but the friction that exists today pushes that date further into the future.
I hear many businesses that are interested in ‘doing something with SharePoint.’ That is kind of like saying I’d like to deploy a Swiss army knife. Depending on what the goals of the business are, SharePoint can be a lot of different things. This post tries to explore what those are.
First, let’s start with a few definitions for SharePoint:
An integrated suite of server capabilities that can help improve organizational effectiveness by providing comprehensive content management and enterprise search, accelerating shared business processes, and facilitating information-sharing across boundaries for better business insight. Additionally, this collaboration and content management server provides IT professionals and developers with the platform and tools they need for server administration, application extensibility, and interoperability.
-Microsoft www.microsoft.com/sharepoint/prodinfo/what.mspx
Wow that’s a mouth full. And Microsoft has been working to simplify this over the past few years. What about Wikipedia – surely they have a simple definition:
A collection of products and software elements that includes, amongst a growing selection of components, collaboration functions, process management modules, search modules and a document-management platform. SharePoint can be used to host web sites that access shared workspaces, information stores and documents, as well as host defined applications such as wikis and blogs. All users can manipulate proprietary controls called “web parts” or interact with pieces of content such as lists and document libraries.
- Wikipedia en.wikipedia.org/wiki/Sharepoint
OK, still a lot to digest. Let’s look at each of the components that make up this beast in a little more detail before drawing any conclusions. Acknowledgements to Gartner for the included magic quadrant analysis…
Enterprise Content Management:
Allows the management of an organization’s unstructured information (content and documents related to organizational processes) wherever that information exists. It includes technologies to:
- Capture (OCR, email, video, etc.)
- Manage
- Document management (check in/out, versioning)
- Collaboration (or collaborative software, groupware),
- Web content management
- Records management (indexing, archive and filing management)
- Workflow (capture, reviews, approvals, publishing, expiration)
- Store (repositories, libraries, media)
- Deliver (transform, secure, distribute)
- Preserve (backup, recovery)
While I often hear that SharePoint is difficult to use toward this goal, especially if the primary objective is web content management, it has the features to address all these needs. Gartner’s ranking bears this out.
More after the break… read more…
As I prepare today to create a training course that I will be presenting on how to demonstrate ROI on BPM projects, I found Tom Perry’s post timely. In it, he applies lean concepts to creating presentations. Among his suggestions:
- Splitting large things up into small batches for focus
- Applying the “5 Whys” to drill down to the important details requiring the attention of the audience.
- Applying 5S: Shine, Sort, Standardize, Systematize, Sustain (go read his explanations.)
Thanks Tom. Now off to my presentation.
OK, I couldn’t stop laughing at Jon Miller’s post taking a creative look at the 60 year history of Kanban. It is as instructive as it is funny. To get a flavor, here’s an excerpt:
Kanban Gains Superpowers
Pokayoke has the power to prevent mistakes. Jiodka frees people to run machines intelligently, rather than be run by them. Heijunka has the power to take choppy demand and smooth it out. Kaizen has the power to make infinite small improvements. All of these players and their many friends bring order and harmony to a production system. Yet one stands above them all: kanban.
Kanban was endowed with three major powers. First is the the power to instruct the production of goods. Within the Toyota Production System and its imitators, only kanban has the power to cause things to be made. Second is the power to instruct the movement of goods. Like its first power, kanban can cause things to be moved. Third and perhaps most important, kanban can motivate people towards continuous improvement by reducing its own size. Within a kanban system, the less kanban there is, the more improvement is needed. Like a true hero, the power of kanban increases as it diminishes its own presence. Amazing.
Dean Leffingwell has a great post up with the above title. His approach and conclusions fit well with my Laws of Development. I realize I’ve never summarized them on this blog, so I will do that in the near future. In the mean time, here’s a summary from Dean’s great work which is very practical:
He offers that by replacing the word ‘software’ with ‘solutions’ in founding agile principle statements, they can apply broadly to other knowledge work like: training development, IT infrastructure administration, marketing communications, and HR management. He also recaps Lean concepts from manufacturing that apply more broadly such as: focus on value, reduce work in progress, reduce cycle time, build in quality, cell based work and continuous improvement.
He then suggests the following ten practices for broad knowledge work application:
# 1 – Develop and empower, self-organizing, self-managing teams. Energize with vision, mission and time pressures. Provide requisite creative chaos, care and support.
# 2 – Plan work in short (one or two week) iterations. Teams plan together and commit to value delivery objectives in these increments.
# 3 – Focus on value delivery. Apply user story form (“as a <user role>, I can <do something> so that I can <business value>) to help assure value delivery.
# 4 – Develop, single prioritized backlog of work for the team. Establish product owner (or product owner team equivalent) roles to manage and prioritize backlog.
# 5 – Apply, daily 15 minute standup meeting as a primary form of communication and commitment. (What I did yesterday. What I’m doing today. Whether I am blocked or not.)
#6 – Minimize work in process to increase productivity. Develop work in process limits to task and stories. Minimize multiplexing within time boxes.
#7 – Plan for delivery of larger enterprise initiatives in larger (release) time boxes. Engage stakeholder in periodically (approximately quarterly) planning, visioning and commitment setting. Make vision, objectives and commitments visible and public.
# 8 – Provide total, real time visibility. Build big visible chart to show work in process and individual and team responsibilities. Speak directly to facts and issues. Publish iteration and release objectives.
#9 – Develop shared knowledge. Institutionalize knowledge by pairing on tasks, projects and stories. Avoid over-specialization so work force can flex to backlog and resource bottlenecks.
#10 – Apply work physics and agile planning. Estimate and track time completion by story and task. Establish and apply team velocity (capacity of work achievable in a time box).
I’ll briefly comment on this list here, but again look for my summary of the laws coming soon. The most obvious thing I think he has overlooked as a practice is applying continuous improvement and reducing variability. Scrum uses the retrospective which could easily be added as a broad practice perhaps to #7. He combines two concepts in #6, limiting work in process and reducing variability of job functions or multiplexing. Addressing each of these head on might uncover additional value. I also believe the use of Kanban for #6 as a method for accomplishing the work in process reduction, a lean tool, is overlooked and should be considered for more multi-disciplined work. Instead he suggests a more agile approach of iterations in #2 with story point limits through a backlog and PO in #4 to limit work.
ABPMP Denver put on a great panel discussion on Tuesday evening on the topic of the state of project work in the current economy. First thanks to the great panelists for sharing a collective generation of great insight: Bill Gilbert, EVP and COO, Statera; Donald Davidoff, Group VP Strategic Systems, Archstone; and David Neitz, VP Solutions and Innovation, Fiserv Investment Support Services.
I’ve been ruminating on a lot of the topics covered, but the one I keep coming back to is the answers to the question ‘what are companies investing in in today’s economy.’ The answer from the panel was basically, ‘It’s all about risk mitigation in 2009.’ While I get that, it seems like conventional wisdom perhaps goes against best wisdom in this case.
Conventional wisdom states that:
- In good time, companies invest in growth
- In bad times, companies invest in savings
- In really bad times, companies invest in risk reduction
I suggest this should be turned around:
In good times, irrational exuberance suggests that companies might spend more time and effort looking for their blind spots and focus on reducing any risks that could displace what is working today or could work against them when tides turn. Especially the recent history of Enron and Leman Brothers has shown that blindly chasing the greatest new ideas can be catastrophic.
In really bad times, companies have the luxury to investigate new opportunities more rationally. They can take their time in developing, and perfecting new offerings, and take advantage of lower costs and more resource availability to grow. There is a lot of recent buzz about great companies founded in recessions.
In all times, companies should be able to use well justified business cases to invest in savings and continuous improvement of current business processes.
David Anderson at Agile Management has two new blog posts that got me thinking. The first is How to Start with Kanban which lays out how to implement Kanban for software development in 10 easy steps (I like its simplicity.) The second is Blogosphere Buzz about Lean & Kanban which is a comprehensive review of blog articles coming out of the Florida Lean & Kanban conference. All this Lean Kanban talk got me thinking about what really is the difference between all these terms. My conclusion in summary is: Lean and Agile are concepts that allow for more flexible, lower cost development or production – Kanban and Scrum are two approaches for implementing these concepts for software development.
My Laws of Development try to show how Lean (and Six Sigma) are the foundation for Agile and are adopted from the first book I studied on lean and applied in my early consulting days, Factory Physics, Foundations of Manufacturing. When first introduced to Lean as a software development concept more broad than Scrum through Mary and Tom Poppendieck’s book and an Allan Shalloway conference, my reaction was something like: yes, but both use the same concepts at different organizational levels. The fact that lean concepts extend into the scrum cycle by ensuring that there is a limited amount of focused work at the development team level is often overlooked. My reaction to Kanban has been similar over the past couple years as it has gained popularity. While Scrum and XP use story points or ideal man days to limit WIP, Kanban borrows a more direct tool from lean manufacturing to accomplish the same objective through the Kanban (simply meaning ‘card’ in Japanese) itself.
Agile and Scrum, while while they can be more broadly applied, have grown primarily as a result of lean (originally manufacturing) concepts being used to improve software development. Kanban will always be more broad than software development; though, there appears to be movement to capture the term specifically for software development.
I guess, I still go back to the founding principles of lean. If we understand the principles, it allows for adoption to specific needs across a wide spectrum of verticals and organizational levels without taking sides on the latest terms and tools to emerge from applying them.
