HP’s Ambitious Cloud Computing Strategy: Can HP Emerge as a Power?

To comprehend HP’s cloud computing strategy you have to first understand HP’s Matrix Blade System.  HP announced the Matrix system in April of 2009 as a prepackaged fabric-based system.  Because Matrix was designed as a packaged environment, it has become the lynch pin of HP’s cloud strategy.

So, what is Matrix?  Within this environment, HP has pre-integrated servers, networking, storage, and software (primarily orchestration to customize workflow). In essence, Matrix is a Unified Computing System so that it supports both physical blades as well as virtual configurations. It includes a graphical command center console to manage resource pools, physical and virtual servers and network connectivity. On the software side, Matrix provides an abstraction layer that supports workload provisioning and workflow based policy management that can determine where workloads will run. The environment supports the VMware hypervisor, open source KVM, and Microsoft’s Hyper-V.

HP’s strategy is to combine this Matrix system, which it has positioned as its private cloud, with a public compute cloud. In addition, HP is incorporating its lifecycle management software and its security acquisitions as part of its overall cloud strategy. It is leveraging the HP services (formerly EDS) to offer a hosted private cloud and traditional outsourcing as part of an overall plan. HP is hoping to leveraging its services expertise in running large enterprise packaged software

There are three components to the HP cloud strategy:

• CloudSystem
• Cloud Services Automation
• Cloud Consulting Services

CloudSystem. What HP calls CloudSystem is, in fact, based on the Matrix blade system. The Matrix Blade System uses a common rack enclosure to support all the blades produced by HP. The Matrix is a packaging of is what HP calls an operating environment that includes provisioning software, virtualization, a self-service portal and management tools to manage resources pools. HP considers its public cloud services to be part of the CloudSystem.  To provide a hybrid cloud computing environment, HP will offer compute public cloud services similar to what is available from Amazon EC2.  When combined with the outsourcing services from HP Services, HP contends that it provides a common architectural framework across public, private, virtualized servers, and outsourcing.  It includes what HP is calling cloud maps. Cloud maps are configuration templates based on HP’s acquisition of Stratavia, a database and application automation software company.

Cloud Service Automation.  The CloudSystem is intended to make use of Services Automation software called Cloud Service Automation (CSA). The components of CSA include a self-service portal that manages a service catalog. The service catalog describes each service that is intended to be used as part of the cloud environment.  Within the catalog, the required service level is defined. In addition, the CSA can meter the use of services and can provide visibility to the performance of each service. A second capability is a cloud controller, based on the orchestration technology from HP’s Opsware acquisition. A third component, the resource manager provide provisioning and monitoring services.  The objective of CSA is to provide end-to-end lifecycle management of the CloudSystem.

Cloud Consulting Services. HP is taking advantage of EDS’s experience in managing computing infrastructure as the foundation for its cloud consulting services offerings. HP also leverages its consulting services that were traditionally part of HP as well as services from EDS.  Therefore, HP has deep experience in designing and running Cloud seminars and strategy engagements for customers.

From HP’s perspective, it is taking a hybrid approach to cloud computing. What does HP mean by Hybrid? Basically, HP’s hybrid strategy includes the combination of the CloudSystem – a hardware-based private cloud, its own public compute services, and traditional outsourcing.

The Bottom Line.  Making the transition to becoming a major cloud computing vendor is complicated.  The market is young and still in transition. HP has many interesting building blocks that have the potential to make it an important player.  Leveraging the Matrix Blade System is a pragmatic move since it is already an integrated and highly abstracted platform. However, it will have to provide more services that increase the ability of its customers to use the CloudSystem to create an elastic and flexible computing platform.  The Cloud Automation Services is a good start but still requires more evolution.  For example, it needs to add more capabilities into its service catalog.  Leveraging its Systinet registry/repository as part of its service catalog would be advisable.  I also think that HP needs to package its security offerings to be cloud specific. This includes both in the governance and compliance area as well as Identity Management.

Just how much will HP plan to compete in the public cloud space is uncertain.  Can HP be effective in both markets? Does it need to combine its offerings or create two different business models?

It is clear that HP wants to make cloud computing the cornerstone of its “Instant-On Enterprise” strategy announced last year. In essence, Instant-on Enterprise is intended to make it easier for customers to consume data center capabilities including infrastructure, applications, and services.  This is a good vision in keeping with what customers need.  And plainly cloud computing is an essential ingredient in achieving this ambitious strategy.

Why is IBM in the horizontal solutions business?

Every year I attend IBM software analyst meeting. It is an opportunity to gain a snap shot of what the leadership team is thinking and saying.  Since I have had the opportunity to attend many of these events over the year, it is always instructive to watch the evolution of IBM’s software business over the years.

So, what did I take away from this year’s conference? In many ways, it was not that much difference in what I experienced last year. And I think that is good. When you are a company of the size of IBM you can’t lurch from one strategy to the next and expect to survive.  One of the advantages that IBM has in the market is that has a well developed roadmap that it is in the process of executing on.  It is not easy to execute when you have as many software components as IBM does in its software portfolio.

While it isn’t possible to discuss all that I learned in my various discussions with IBM executives, I’d like to focus on IBM’s solutions strategy and its impact on the software portfolio.  From my perspective,  IBM has made impressive strides in enforcing a common set of services that underlie its software portfolio.  It has been a complicated process that has taken decades and is still a work in progress.  The result required that all of the business units within software are increasingly working together to provide underlying services to each other.  For example, Tivoli provides management services to Rational and Information Management provides data management services to Tivoli. WebSphere provides middleware and service orientation to all of the various business units.  Because of this approach, IBM is better able to move to a solutions focus.

It’s about the solutions.

In the late 1990s IBM got out of the applications business in order to focus on middleware, data management, and systems management. This proved to be a successful strategy for the next decade. IBM made a huge amount of money selling WebSphere, DB2, and Tivoli offerings for SAP and Oracle platforms. In addition, Global Services created a profitable business implementing these packaged applications for enterprises.  But the world has begun to change. SAP and Oracle have both encroached on IBM’s software business. Some have criticized IBM for not being in the packaged software business. While IBM is not going into the packaged software business, it is investing a vast amount of money, development effort, and marketing into the “solutions” business.

How is the solutions business different than a packaged application? In some ways they are actually quite similar. Both provide a mechanism for codifying best practices into software and both are intended to save customers time when they need to solve a business problem.  IBM took itself out of the packaged software business just as the market was taking off.  Companies like SAP, Oracle, Seibel, PeopleSoft and hundreds of others were flooding the market with tightly integrated packages.  In this period of the early 1990s, IBM decided that it would be more lucrative to partner with these companies that lacked independent middleware and enabling technologies.  IBM decided that it would be better off enabling these packaged software companies than competing in the packaged software market.

This turned out to be the right decision for IBM at the time.  The packaged software it had developed in the 80s was actually holding it back.  Therefore, without the burden of trying to fix broken software, it was able to focus all of its energy and financial strength on its core enabling software business.  But as companies like Oracle and SAP cornered the packaged software market and began to expand to enabling software, IBM began to evolve its strategy.  IBM’s strategy is a hybrid of the traditional packaged software business and a solutions business based on best practices industry frameworks.

So, there are two components in IBM’s solutions strategy – vertical packaged solutions that can be applied across industries and solution frameworks that are focused on specific vertical markets.

Horizontal Packages. The horizontal solutions that IBM is offerings have been primarily based on acquisitions it has made over the past few years.  While at first glance they look like any other packaged software, there is a method to what IBM has purchased.  Without exception, these acquisitions are focused on providing packaged capabilities that are not specific to any market but are intended to be used in any vertical market.  In essence, the packaged solutions that IBM has purchased resemble middleware more than end-to-end solutions. For example, Sterling Commerce, which IBM purchased in August 2010, is a cross channel commerce platform.  It purchased Coremetrics in June, provides web analytics and bought Unica for marketing automation of core business processes.  While each of these is indeed packaged, they reach represent a component of a solution that can be applied across industries.

Vertical Packages. IBM has been working on its vertical market packaging for more than a decade through its Business Services Group (BSG). IBM has taken its best practices from various industry practices and codified these patterns into software components. These components have been unified into solution frameworks for industries such as retail, banking, and insurance. While this has been an active approach with the Global Services for many years, there has been a major restructuring in IBM’s software organization this past year. In January, the software group split into two groups: one focused on middleware and another focused on software solutions.  All of the newly acquired horizontal packages provide the underpinning for the vertical framework-based software solutions.

Leading with the solution. IBM software has changed dramatically over the past several decades.  The solutions focus does not stop with the changes within the software business units itself; it extends to hardware as well.  Increasingly, customers want to be able to buy their solutions as a package without having to buy the piece parts.  IBM’s solution focus that encompasses solutions, middleware, appliances, and hardware is the strategy that IBM will take into the coming decade.

What will it take to achieve great quality of service in the cloud?

You know that a market is about to transition from an early fantasy market when IT architects begin talking about traditional IT requirements. Why do I bring this up as an issue? I had a fascinating conversation yesterday with a leading architect in charge of the cloud strategy for an important company that is typically on the bleeding edge of technology. Naturally, I am not allowed to name the company or the person. But let me just say that individuals and companies like this are the first to grapple with issues such as the need for a registry for web services or the complexity of creating business services that are both reusable and include business best practices. They are the first companies to try out artificial intelligence to see if it could automate complex tasks that require complex reasoning.

These innovators tend to get blank stares from their cohorts in other traditional IT departments who are grappling with mundane issues such as keeping systems running efficiently. Leading edge companies have the luxury to push the bounds of what is possible to do.  There is a tremendous amount to be learned from their experiments with technology. In fact, there is often more to be learned from their failures than from their successes because they are pushing the boundary about what is possible with current technology.

So, what did I take away from my conversation? From my colleague’s view, the cloud today is about “how many virtual machines you need, how big they are, and linking those VMs to storage. “ Not a very compelling picture but it is his perception of the reality of the cloud today.  His view of the future requirements is quite intriguing.

I took away six key issues that this advanced planner would like to see in the evolution of cloud computing:

One.  Automation of placement of assets is critical.  Where you actually put capability is critical. For example, there are certain workloads that should never leave the physical data center because of regulatory requirements.  If an organization were dealing with huge amounts of data it would not be efficient to place elements of that data on different cloud environments. What about performance issues? What if a task needs to be completed in 10 seconds or what if it needs to be completed in 5 milliseconds? There are many decisions that need to be made based on corporate requirements. Should this decision on placement of workloads be something that is done programmatically? The answer is no. There should be an automated process based on business rules that determines the actual placement of cloud services.

Two. Avoiding concentration of risk. How do you actually place core assets into a hypervisor? If, for example, you have a highly valuable set of services that are critical to decision makers you might want to ensure that they are run within different hypervisors based on automated management processes and rules.

Three. Quality of Service needs a control fabric.  If you are a customer of hybrid cloud computing services you might need access to the code that tells you what tasks the tool is actually doing. What does that tool actually touch in the cloud environment? What do the error messages mean and what is the implication? Today many of the cloud services are black boxes; there is no way for the customer to really understand what is happening behind the scenes. If companies are deploying truly hybrid environments that support a mixed workload, this type of access to the workings of the various tools that is monitoring and managing quality of service will be critical.  From a quality of service perspective, some applications will require dedicated bandwidth to meet requirements. Other applications will not need any special treatment.

Four.  Cloud Service Providers building shared services need an architectural plan to control them as a unit of work. These services will be shared across departments as well as across customers.  How do you connect these services? While it might seem simple at the 50,000-foot level, it is actually quite complex because we are talking about linking a set of services together to build a coherent platform. Therefore, as with building any system there is a requirement to model the “system of services”, then deploy that model, and finally to reconcile and tune the results.

Five. Standard APIs protect customers.  Should APIs for all cloud services be published and accessible? If companies are to have the freedom to move easily and efficiently between and among cloud services then APIs need to be well understood. For example, a company may be using a vendor’s cloud service and discover a tool that addresses a specific problem.  What if that vendor doesn’t support that tool? In essence, the customer is locked out from using this tool. This becomes a problem immediately for innovators.  However, it is also an issue for traditional companies that begin to work with cloud computing services and over time realize that they need more service management and more oversight.

Six. Managing containers may be key to the service management of the cloud. A well-designed cloud service has to be service oriented. It needs to be placed in a container without dependencies since customers will use services in different ways. Therefore, each service needs to have a set of parameter driven configurators so that the rules of usage and management are clear. What version of what cloud service should be used under what circumstance? What if the service is designed to execute backup? Can that backup happen across the globe or should it be done in proximity to those data assets?  These management issues will become the most important issues for cloud providers in the future.

The best thing about talking to people like this architect is that it begins to make you think about issues that aren’t part of today’s cloud discussions.  These are difficult issues to solve. However, many of these issues have been addressed for decades in other iterations of technology architectures. Yes, the cloud is a different delivery and deployment model for computing but it will evolve as many other architectures do. The idea of putting quality of service, service management, configuration and policy rules at the forefront will help to transform cloud computing into a mature and effective platform.



The lock-in risks of Software as a Service

I started thinking a lot about software as a service environments and what this really means to customers.  I was talking to a CIO of a medium sized company the other day. His company is a customer of a major SaaS vendor (he didn’t want me to name the company). In the beginning things were quite good. The application is relatively easy to navigate and sales people were satisfied with the functionality. However, there was a problem. The use of this SaaS application was actually getting more complicated than the CIO had anticipated.  First, the company had discovered that they were locked into a three-year contract to support 450 sales people.  In addition, over the first several years of use, the company had hired a consultant to customize the workflow within the application.

So, what was the problem?  The CIO was increasingly alarmed about three issues:

• The lack of elasticity. If the company suddenly had a bad quarter and wanted to reduce the number of licenses supported, they would be out of luck. One of the key promises of cloud computing and SaaS just went out the window.
• High costs of the services model. It occurred to the CIO that the company was paying a lot more to support the SaaS application than it would have cost to buy an on premise CRM application. While there were many benefits to the reduced hardware and support requirements, the CIO was starting to wonder if the costs were justified.  Did the company really do the analysis to determine the long-term cost/benefit of cloud?  How would he be able to explain the long- term ramifications of budget increases that he expects will come to the CFO? It is not a conversation that he is looking forward to having.
• No exit strategy. Given the amount of customization that the company has invested in, it is becoming increasingly clear that there is no easy answer – and no free lunch. One of the reasons that the company had decided to implement SaaS was the assumption that it would be possible to migrate from one SaaS application to another.  However, while it might be possible to migrate basic data from a SaaS application, it is almost impossible to migrate the process information. Shouldn’t there be a different approach to integration in clouds than for on premise?

The bottom line is that Software as a Service has many benefits in terms of more rapid deployment, initial savings in hardware and support services, and ease of access for a highly distributed workforce.  However, there are complications that are important to take into account.  Many SaaS vendors, like their counterparts in the on-premise world, are looking for long-term agreements and lock-in with customers.  These vendors expect and even encourage customers to customize their implication based on their specific business processes.  There is nothing wrong with this – to make applications like CRM and HR productive they need to reflect a company’s own methods of doing business. However, companies need to understand what they are getting into. It is easy to get caught in the hype of the magic land of SaaS.  As more and more SaaS companies are funded by venture capitalists, it is clear that they will not all survive. What happens to your customized processes and data if the company goes out of business?

It is becoming increasingly clear to me that we need a different approach to integration in the cloud than for on premise. It needs to leverage looser coupling, configurations rather than programmatic integration. We have the opportunity to rethink integration altogether – even for on premise applications.

There is no simple answer to the quandary.  Companies looking to deploy a SaaS application need to do their homework before barreling in.  Understand the risks and rewards. Can you separate out the business process from the basic SaaS application? Do you really want to lock yourself into a vendor you don’t know well? It may not be so easy to free your company, your processes, or your data.

Why did IBM buy Lombardi?

Just as I was about to start figuring out my next six predictions for 2010 I had to stop the presses and focus on IBM’s latest acquisition. IBM just announced this morning that it has purchased Lombardi which focuses on Business Process Management software. Lombardi is one of the independent leaders in the market as well as a strong IBM business partner. The obvious question is why would IBM need yet another business process management platform? After all, IBM has a large portfolio of business process management software — some homegrown and some from various acquisitions such as Filenet, ILOG, and Webify. I think that the answer is actually quite straight forward. Lombardi’s offerings are used extensively in business units, by business management to codify complex processes that are at the heart of streamlining how businesses are able to differentiate themselves. Clearly, IBM has recognized the importance of Lombardi to its customers since it has had a long standing partnership with the company.  I think there are two reasons that this acquisition are significant beyond the need to provide direct support for business management. The ability to use Lombardi’s technology to sell more WebSphere offerings and the connection of business process to IBM’s Smarter Planet initiative are the two issues that stand out in my mind.

Selling more WebSphere products. There is no question that the WebSphere brand within IBM’s Software business unit includes a lot of products such as its registry/repository, applications integration, security, and various middleware offerings. IBM likes to sell its products by focusing on entry points — the immediate problem that the customer is trying to solve. The opportunity to gain direct access to business buyers who start with business process management and then may be see the value of adding new capabilities to that platform.

Supporting the Smarter Planet strategy. Business transformaton often starts by reconstructing process. IBM’s smarter planet strategy is based on the premise that customers want to be able to transform their businesses utilizing sophisticated technology. Therefore, it is important to look at how business innovation can be supported by IBM’s huge hardware, software, and services portfolio. The fact that Lombardi’s technology is the starting point for business units looking at transformational process changes is an important marker in IBM’s evolution as a company.

Bureaucracy gone mad: when process gets in the way of service management

I had two interesting discussions over the past few weeks; one with an IT manager and the other with Rhett Glause and Matt French from Service-Now. Both discussions related to the issue of managing service processes in a complex computing environments.  Let me start with the IT manager. He is charged with taking his organization’s web presence from 1990s architecture into a modern Web 2.0 design that will enable better support for customers and partners.  It is a big effort with lots of interaction with the customer facing departments about what they want and with the IT organization about how this new environment will be supported.  Now, this part isn’t out of the ordinary and this is not what this manager was having problems with.  He was being driven crazy by process. The company he works for is devoted to ITIL (Information Technology Infrastructure Library). ITIL is a set of best practices designed to help companies create environments that have a common way to troubleshoot problems with managing complex services.  They are intended as guidelines – not step-by-step instructions about how to managing service processes. In fact, ITIL best practices mandate that you need to start with your strategy for managing services before you get involved in the details.

The IT manager’s problem is that his company’s IT department was so embroiled in process that it was causing excessive delays in getting to a solution. It has a Configuration Management Database (CMDB) —  a repository for all of the details about an application environment including who can change something; how a service or an application is configured and what the change management process is. This company’s problem is that it has set up a change review board that has to review and approve every change for the new environment.  Therefore, something that should take a few days to develop is taking six month of endless meetings.  In other words, the IT manager’s organization is too caught up in process so that it actually crippling the ability to get the job done.  According to the IT manager, “It’s bureaucracy gone mad! This approach will not help make IT more responsive; it will do the opposite.”

I thought about the discussion in context with a great call I had with Matt French, director of marketing and product strategy and Rhett Glauser, communications manager at Service-Now, an IT service desk software as a service company.  What did they think of my friend’s tale of woe? They agreed that this is a common perspective that they hear from customers.  Many customers are beginning to understand that they have to take a pragmatic view of process.  Their top recommendation was that companies should approach ITIL in a phrased approach.

So, here are some recommendations about how to handle process in context with driving business value:

• Establish a light-weight CMDB by only focusing on configuration items that the organization really needs. If a process isn’t likely to change, it might not be necessary to track that process.  You don’t need a change management process for everything.
• Get IT management to take a step back from relying too heavily on IT processes. Rather management needs to be focused on what is important to business management and then execute in a pragmatic way.
• Every service should have a business owner who can make decisions.
• When a change management process is required make sure that there is a change advisory board. There needs to be one person who has the authority to manage that change in the context of the business drivers. The change management board should expedite process and should not become a bottleneck.

In the end it is about common sense. If IT organizations are going to be effective in managing business requirements they have to look at service management in context with the overall priorities of the business. This was the key message our team was aiming for when we wrote Service Management for Dummies. Service management is increasingly defining not only how we manage IT environments but how we managed businesses. Therefore a streamlined view of process management will be the difference between success and failure.

Can we free process and data?

I am still at IBM’s Information on Demand conference here in Las Vegas (not my favorite place..but what can you do). In listening to a lot of discussions around strategy and products I started thinking about one of the key problems that customers are facing around business process and managing increasingly complex data. What companies really want to do is to have the flexibility and freedom to leverage their critical data across applications and situations. They also want to be able to change processes based on changing business models.

This is the core issue that companies will be facing in the coming decade and will be the difference between success and failure for many  businesses.  Here’s an example of what I mean. Let’s take the example of a retailer in a competitive market. Let’s say our retailer had five or six applications: Accounting, Human Resources, supply chain management, a customer support system, and a customer facing e-commerce system. Each of these systems has an underlying database; each one manages this data based on the business process that is the foundation of the best practices that is the value of these packages. Even if each of the packages are the best in their markets there is a core problem since each solution is a silo. Processes that move between these systems tend to fall through the cracks.  This is why we, as customers of such retailers, are often frustrated when we call about a product that wasn’t delivered, doesn’t work, or requires a change only to discover that one department has no ability to know what is happening in another area. For most companies the dream of single view of the customer is aspirational but not practical right now. In reality, it is hard for companies to mess with their existing applications. These solutions are customized for their business environment; they were expensive and complicated to implement — and change is hard. In fact, companies only change when it is more painful to stay with the status quo than it is to change. In a retail scenario, companies change their approach to process and data management when they must change their business model because the current processes will lead to failure. Retailers are currently faced with emerging approaches to selling and managing customer relationships that are challenging traditional selling models.  Look what a company like Amazon.com or Netflex have done to their slower moving competitors.

A number of customers I have spoken with understand this very well. They are looking at ways to separate their core data assets from the underlying applications. Many of these customers are at the forefront of implementing a service oriented architecture (SOA) approach to managing their software assets. They are increasingly understanding that the secret to their future success is the knowledge they have about their customers, their needs and future requirements within their own set of offerings and those from partners. These companies are setting a priority of making this data independent, secure, and accurate. These business leaders are preparing for inevitable change.  At the same time, I have seen these customers creating SOA business services that are, in essence, codified business processes. For example, a business service could be a process that checks the credit of a potential partner or links a new customer request for service to the set of applications that confirms the request, orders the part, and notifies a partner.

So, here is the problem. These customers are implementing this new model of abstracting data and process based on specific projects or business initiatives.  These projects have gotten the attention of the C-team because of the impact on revenue. But, in reality, the real breakthrough will happen when the separation of data and process are the rule, not the exception.

This is going to be the overriding challenge for the next decade because it is so hard. There is inertia to move away from the predictable packaged applications that companies have implemented for more than 30 years. But I suggest that it will be inevitable that companies will begin to understand that if they are going to remain agile and change processes when they anticipate a competitive threat. These same companies will understand that their data is too important to leave it locked inside an application linked tightly to a process.

I don’t have the answers about what the tipping point will be when this starts to become a wide spread strategy. I think that the cloud will became a forcing action that will accelerate this trend. I would love to start a dialog. Send me your thoughts and I promise to post them.

Sometimes its the little business process mistakes — not the strategy

As an industry analyst I am always looking at new technology innovations and new approaches that help companies transform their business process. There are some technologies that I have been seeing that are really excellent at adding robustness and sophistication to help companies transform the customer experience. But every once in a while you come across a business process example that makes you stop in your tracks and think about the small business process issues that can undue all the innovation.

Let me give you a real life example that got me thinking about this issue. An individual I knows owns rental property. It is a multi-unit house in the middle of a city. Needless to say, it needed insurance against potential disasters. My friend, being a responsible landlord sent his payment into his insurance provider. In fact, he set up a process with his bank so that his payment would be automatically sent out each month. Things were going great until one day my friend got a check from his insurance provider for “overpayment”. This really puzzled my friend since a process was in place for automatic payment. That process seemed to be working fine.  After numerous calls to the insurance company he finally got to the bottom of this complex business process problem. It seems that the company has a funny way of creating customer account numbers. The first seven digits of the number are the account number; the next two digits are the number of years that the policy has been in place.  My friend has put all nine digits in the account number field in his online payment system. Unfortunately, for my befuddled friend, no where on the insurance company statement did it suggest that those last two digits had nothing to do with the customer account number. So, basically, the payment was rejected because the year field was added. The company simply had not anticipated that anyone would not understand their process.

Now, I am sure that my friend wasn’t the only customer on the planet that thought that all nine digits were the account number. The happy ending is that the insurance was reinstated.

But here is the issue that I started thinking about. I suspect that this company spent a lot of money on its business process strategy, buying technology and tools. And they are pretty proud of their efforts. But it is so easy to get caught up in the broad process issues and forget the small issues like the structure of the customer account number. However, the reality is quite important. Take the example of my friend’s insurance company. If there were a few hundred customers who all made the same mistake it could result in an unanticipated loss of revenue. And in the future, those customers may decide that they really can’t trust their insurance provider and will choose to move to another insurance company.

An account number confusion problem will probably never be noticed by the management team. No one is going to call a meeting to discuss the fact that customers are confused by how we print our account number on our bills. But the reality may be that this small business process mistake made by an innocent programmer somewhere in the world can impact a company in a big way. I guess it isn’t a huge momentus issue in the full spectrum of world economies or technology evolution and it certainly isn’t the most exciting topic. But I think it is worth stepping back and thinking about.

Will packaged applications sink under their own weight? Five recomendations for change.

I have been researching and thinking about the problem of the packaged application for many years now.  Over the years I have had conversations with many CIOs who are planning to implement large complex ERP systems as part of their initiative to streamline their operations.  There is an assumption that implementing one of these systems will simplify corporate IT. There is also the assumption that it is possible to implement an ERP system as is – in other words, without complex customization.  The sad reality is that this just doesn’t happen in the real world.

This brings me to a conversation I had about a month ago with a CIO.  He was in charge of the IT organization in a relatively large corporation (I am not at liberty to mention the company name).  The company had decided to replace its assortment of corporate business applications with a comprehensive ERP system. The idea was correct – the company needed a system that would implement business process and best practices to support the business in a uniform and efficient manner.  The problem, in my mind was two fold – first the cost.  To purchase and then implement this software cost the company $500 million dollars. Obviously, a considerable part of this expense was for professional services.  And maybe that is the point. The idea that a company can purchase a packaged ERP system that is really packaged software is a misnomer. In reality, packaged software is not really packaged.  It is a set of tools, a set of templates and processes that are linked together based on marketing and promise.  The CIO I was speaking with provided some insight into the complexity of this implementation. It required a lot more customization than anyone had anticipated. The promise of out of the box implementation was a myth.  Once the customization was applied to this package, the concept of a packaged environment was gone.  Therefore, it should not have come as a shock when the next time the base platform of processes and tools had to be upgraded; it cost the company an additional $50 million.

So, what am I saying here? Should we throw the bums out? Should we declare that the concept of packaged software is dead and flawed? Probably.  Now, let’s get real. Obviously, companies cannot and should not go back to paper based processes. However, I think that we need to get real about what it means to package software.

Here is what I propose. Let’s not pretend that packaged software is packaged.  The reality is that good software that is designed to meet a specific corporate goal should have the following five components:
1. Business best practices should be component based.  Packaged software should be a set of business services that implement well-tested business processes that are either industry or practice based. For example, accounting practices are fairly well understood and well codified.  Accounting best practices may be different between industries but it is straightforward to create modular components that are populated with processes.  It should not be constructed as a set of complex intertwined code. It should be independent modules that can be linked to each other and that can exchange data.
2.  Create standards based links. Well defined interfaces that enable the customer to link these components and other components without complex coding, including easily usable interfaces to all data files and databases.
3. Separate business rules from code. Business rules should be contained in a separate set of components or a rules engine so that they can updated easily. These rules should have a visual interface so that management can easily review them and map them to corporate governance
4. Implementations should be configurable. It should be straightforward for an organization to change the details of a process or a service without recoding.
5. Modularity is the key. Company specific rules, configurations, and services should be modular and separate from the connective tissue that links the components of these environments.  In this way, when a system foundation needs to be upgraded, it can be done without impacting the value that is the lifeblood of a company.

The bottom line: the packaged software market is at a transition point

The state of the packaged software market is complicated.  Companies across the globe have spent trillion of dollars trying to automate business practices.  Some implementations have been successful. But even those companies that have had the good fortune of implementing packaged software to streamline their business have done so at a steep financial and organizational price.  I predict that we are entering a new stage of evolution of software.  Many of the CIOs I have spoken with lately are beginning to rethink the conventional wisdom about packaged applications.  They are beginning to take the concept of business services that is the foundation of a service oriented architecture and applying that to the packaging of codified best practices.
One CIO I spoke with has started methodically to peel away key business services from packaged applications.  This might be an order to cash process that is rewritten hundreds of times across hundreds of applications.  Now, the company has created one business service called order-to-cash.  This order-to-cash service will be used anywhere in the company where this capability is needed.  This very patient CIO plans to replace duplicated services locked in inflexible packaged applications with well-constructed and very independent business services.  And some day, there will be no more complicated, inflexible, and repetitive packaged applications.  I think this might lead to a lot more innovation at a fraction of the cost.

Why I think Web Oriented Architecture is phony

If you are not in the software industry and not conversant in the jargon, you probably think I have lost my mind. What do you mean WOA? It stands for Web Oriented Architecture (WOA).  So, from what I can see the positioning is that SOA is about back end services and protocols like SOAP, etc. and WOA is about cool web protocols like REST, etc.  So, perhaps we are supposed to say, thank goodness that we can move away from SOA and find something new and exciting to focus on.

Well, I hate to burst the bubble but SOA is not just about back end protocols and services. Protocols like REST that provide stateless communication are, in fact, an integral part of a service oriented architecture. Before you get mad at me. Let me explain.  When we talk about SOA we really aren’t talking about protocols. Sure there are lots of protocols and interfaces that are an important part of service orientation. But the power of SOA is in the fact that it enables businesses to focus on two key enables:

1. creating business services that are key business functions

2. enabling these services to be used flexibly to create a variety of business processes that can be changed quickly to enable change and innovation

Companies are getting pretty creative with this approach. Not only are they creating business services involving software components, but they are tying those business services into business elements such as monitoring electric meters.  An excellent example is the SOA implementations of two electric utilities: Delaware Electric and Austin Energy. Neither of these utilities are the biggest in the world. Both are mid-sized utilities with limited IT resources. However, they have both leveraged SOA to tie the ability to monitor and manage power usage and working with constituents to help make the customer experience better and save money at the same time.

These are just two of the 25 case studies that are part of the forthcoming second edition of SOA for Dummies.  What did we learn? Simply put, customers are implementing SOA from a business perspective. They are leveraging back end and web based capabilities and gaining huge business value. These customers don’t care if you call this approach SOA, WOA, or CASH…they simply know that it is allowing them the flexibility they never had before.

The bottom line is that we simply don’t need another new acronym. SOA is not a fad, it is a long term business approach to turning IT and business assets into services that can be used as part of an evolving business process.

I am going to try the neat new capability in my blog and post a survey.