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.
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.
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.
It seems like just the other day that our team was busily finishing the first edition of SOA for Dummies. But it was two years ago since that book came out. A lot has change in that time. When we first wrote the book, we heard from lots of people that they really didn’t know what SOA was and were happy to have a book that would explain it to them in easy to understand language.
Because so much has changed, we were asked to write a second edition of SOA for Dummies which is coming out on December 19th. What has changed in those two years? Well, first of all, there have been a lot more implementations of SOA. In fact, in that edition, we were happy to have gotten 7 case studies. Many of the customers that we talked (both that were featured in the book and those who took the time to speak with us without attribution) were just getting started. They were forming centers of excellence. They were beginning to form partnerships between the business and technical sides of their companies. They were implementing a service bus or were building their first sets of services.
In this second edition, we were fortunate to find 24 companies across 9 different verticals willing and able to talk on the record about their experiences implementing SOA. What did we learn? While there is a lot I could say, I’d like to net it out to 5 things we learned:
1. Successful companies have spent the time starting with the both the key business services and business process before even thinking about implementation.
2. Companies have learned a lot since their initial pilots. They are now focused on how they can increase revenue for their companies through innovation using a service oriented approach.
3. Many companies have a strategic roadmap that they are focused on and therefore are implementing a plan in an incremental fashion.
4. A few companies are creating business services extracted from aging applications. Once this is done, they are mandating the use of these services across the company.
5. Companies that have been working on SOA for the last few years have learned to create modular business services that can have multiple uses. This was much harder than it appeared at first.
There are many other best practices and lessons learned in the case studies. It is interesting to note just as many companies that said yes also were not able to participate because management felt that they didn’t want competitors to know what they were doing.
The bottom line is that SOA is beginning to mature. Companies are not just focused on backbone services such as service buses but on making their SOA services reach out to consumers and their business partners.
We have also added a bunch of new chapters to the book. For example, we have new chapters on SOA service management; SOA software development, software quality, component applications, and collaboration within the business process lifecycle. Of course, we have updated all existing chapters based on the changes we have seen over the last few years.
We are very excited that we had the opportunity to update the book and look forward to continuing the dialog.
The other day I had to fly from Boston to Denver when it became clear that there was going to be a sizable snow storm in Boston. Once it became obvious that if I tried to fly out on Monday I would probably not make my Monday night dinner meeting and my Tuesday consulting I decided to take action. I called United Airlines and changed my flight to Sunday. Now, I hate traveling on Sunday but missing the meeting was not an option.
I was connected to a very, very friendly agent in India. She was extremely polite and informed me that, yes, I could change my flight but I would be charged a $100 change fee plus another $250.00 for the new flight. I was also informed that according to her system there were no weather problems that should cause me to have to change my flight arrangements. I suggested that she might want to look at a website called weather.com .
I was actually surprised that she looked at the site and did acknowledge that there was a storm coming into Boston. Despite this revelation, she would not budge. I asked to speak to a supervisor. To make a long and painful story short — I got the supervisor (also in India) to wave the $100 change fee, but not the $250 charge. I had no choice, I paid for the additional ticket charge.
On Sunday afternoon I arrived at the airport and discovered that I was not the only person who thought the weather might cause travel problems. The United Airline agent at the airport told me that I should not have been charged the $250 fee at all. She gave me a phone number to call and I would be able to get my money back. She was professional, informed and actually quite pleasant to deal with. While sitting and waiting for my Sunday flight to take off, I noticed that my Monday morning flight was indeed canceled.
On Monday, I called the number to get the $250 charge reversed and I found myself caught up in the same process that I experienced when I tried to change my flight. I spent more than an hour talking to very polite agents in India who seemed not to want to reverse the fee. I was finally given a promise that the fee would indeed be reversed and that I would receive an email confirmation. It is Saturday and I am still waiting.
So, what’s my point about process? Companies know that they have to provide customer service. However, it is not a profit center. So, companies like United Airlines create the following process for customer service. If you are a gold/platinum customer you can call a special number and talk to a local representative who treats you like you are a real person. My friend Henry was traveling the same day on United and because he travels on United frequently his experience was the opposite of mine. In essence, United established a class system that treats customers who traditionally spend more money differently from customers like me who tend to travel on other airlines.
On one level it makes sense. Set up a system that rewards loyal customers. The business process designed to support these customers is good. However, the process to handle all the other passengers is broken. Training smart people to be polite, follow a script, and never deviate from a defined process is flawed. What is missing is context. To be good at managing business process requires that there be context for what is happening such as problems with weather and unexpected emergencies. We live in a complex world that requires that customer management be treated as an opportunity for future business development — not as an over simplified process.
In the future, I will probably try to avoid United Airlines if I can (unless there is no direct flight to where I am headed). Had the company had a different business process and treated me as a potentially valuable customer I might have looked more favorably at United for future trips. The bottom line is that streamlining business process too much can be a dangerous thing.
It has been quite a week. First, SAP sets its sights on Business Objects and now for about the same amount of money, Oracle is ready to swallow BEA. Indeed, it looks like the world of enterprise software is continuing to consolidate. So, what do I think? I actually think that Oracle’s decision to buy BEA is a smart move. Oracle needs the depth of middleware and business process software that are two strengths of BEA’s platform. I have spoken with Oracle customers who have not been happy with Fusion middleware. Therefore, the BEA acquisition should strengthen Oracle’s infrastructure assets. Remember that one of BEA’s original assets was AT&T’s Tuxedo distributed transaction processing software suite.
AcquaLogic , BEA’s services integration and business process management platform is well regarded among customers. A few years ago BEA bought Fuego, a very well designed business process management engine.
I could go on for a long time talking about the depth of the BEA software environment. Both its transaction management and business process platform are the jewels in the crown that will benefit Oracle — especially in its Service Oriented Architecture (SOA) strategy.
So, let me get to the bottom line. Here are my conclusions about the Oracle move:
1. Oracle is moving to pick up a strong middleware platform. It has the potential to fix some of the problems with the Fusion platform.
2. It will be a more complicated integration task than some of Oracle other acquisitions. Oracle will have to rationalize its work on Fusion middleware with BEA’s offerings. This will take some time.
3. The comparison between Oracle and SAP’s acquisition moves are very interesting. While SAP has bought a BI platform that will have to be kept separate from its ERP business, Oracle’s purchase will be much closer to its core strategy. The money isn’t that different.
4. BEA was in an uncomfortable position in the market. It has been a player with some impressive acquisitions and leadership. However, it was never able to break out as a leader in terms of revenue. It made its mark with WebLogic — the leading application server. However, it was never able to break out to be viewed by customers as a overall leader — despite some very nice acquisitions.
I expect that this acquisition will go through. I do not expect any other company to come up with an offer. HP, for example, that has been mentioned as a suitor, is unlikely to move in this direction.
I thought that Dana Gardner’s blog today was a well constructed analysis. I agree with many of his points. But don’t think that an HP counter offer is likely. I do think that his view of the interactions between other players will be impacted by this move.
My bottom line: I think that there will be major ripples from this move by Oracle. IBM will not sit still for long. Will IBM increase its alliances with other players — I think so. What does this mean for Tibco? I have talked to customers lately who have been buying Tibco for both its business process and scalable SOA middleware platform. Is Tibco in play? Will SAP and IBM strengthen their relationship?