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.

Is a Hedge Fund Manager Right About SOA?

I was busily working away when I got a call from a hedge fund manager. Now, I don’t really know that many hedge fund managers so I thought this could be a good education. This fund manager — no I don’t remember his name — had a request. Could I spend an hour or at least 5 minutes (yes, that is exactly what he said) with him explaining the key trends in a SOA. Now, while I appreciated his thirst for knowledge, I have to admit I was perplexed. What exactly was he up to? I won’t keep you in suspense any more. Simply put, he wanted to know if SOA was passé. He was reading various blogs and articles that implied that SOA was fine while it lasted but it was basically over. Companies gave it the old college try but found it didn’t work and moved on.

Here is what I told my new friend. Clearly there are people who are proclaiming SOA dead. It is easier to get headlines that way. After all, who wants to write an article and say, it’s moving ahead slowly but surely — not a good headline. My perception is that from the many customers I have spoken with and continue to speak with, SOA is a continuing process. It is not a quick fix. It isn’t like building a single application. It is, as I have said many times, a business strategy and a different approach to building business services. It is not necessarily so easy because the IT group can’t go off and do it alone. The old style programmer who liked to sit in a quiet place and write code doesn’t do well with SOA. The new style developer is a business collaborator. That individual must partner with colleagues in the business units to determine what services and what business processes can be abstracted so that they can be used and repurposed to support business change. That is very different than other technology trends I have witnessed over my years in the business.

No not to belabor the point — SOA is not a fad. It is a business approach to software that is still in its first stage of development. There is a lot more work to be done in terms of products, services, and techniques. So, Mr. Hedge Fund Manager, SOA ain’t dead yet!

SOA Lessons: The end of the hype cycle? Revisiting 2007

I have just gotten back from the Object Management Group’s SOA Consortium meeting. This is a very good advocacy group consisting of primarily corporate customers with a few collection of assorted vendors and integrators. It is a very thoughtful and pragmatic group. I have been a member of the steering committee for the past year and enjoyed participating in the weekly conference calls. We have discussed important issues ranging from maturity models, to SOA governance, to many different best practices. Learning from each other is a powerful theme and focus.

What made this meeting fun for me was being able to share the podium with Sandy Carter, head of marketing for SOA for IBM. We both presented our observations about the direction of SOA for the group. I thought I would share some of Sandy’s comments and then some of my own.

Sandy’s talk focused on two major areas: the learnings from more than 5700 SOA engagements at IBM and the overwhelming requirements for SOA skills and ROI experience with SOA engagements.

So, here are some of the key takeaways from Sandy’s talk:

1.While everyone talks about how programming skills are being outsourced, IBM’s extensive surveys have shown that the an overwhelming number of the respondents found that the biggest inhibitor to the adoption of SOA is the lack of skills — primarily the ability to understand technology tied to the needs of the business. IBM found that 80% of these companies are going to increase their SOA resources this year and 60% of the companies are planning to retrain their existing staff for SOA.

2. Sandy mentioned a new study IBM had sponsored by the London School of Economics that found that companies that implemented SOA increased revenue by 2% — companies that focused on changes in automating business process increased revenue by 18%. Pretty powerful numbers.

3. In another study focused on interviewing hundreds of CEOs, IBM found that SOA is top of mind with the hundreds of CEOs that IBM interviewed. Sandy pointed out in her talk that these CEO from some of the largest companies in the world see the direct link between SOA and business agility.

One of the most interesting issues that Sandy mentioned in her talk was the emerging a Service Science major at major universities. IBM has established a partnership with 200 Universities to help create this new discipline. Teaching MBA students about the SOA principle of creating a service oriented approach to business/technology is critical I would love to see this type of program grow dramatically. I think that many universities are still stuck in the 1980s when it comes to teaching about the intersection of technology and business.

My talk at the meeting centered on SOA lessons from 2007 and predictions for 2008. I’ll give you a synopsis of what I said about this year. My next entry will be a full set of predictions for next year.

My main observation about 2007 was that it was a year of learning about SOA. Our book, SOA for Dummies had just been published at the very end of 2006. It was becoming clear that there was a hunger for information about what this new technology approach was all about. So, 2007 was a year for learning. No market or technology can mature without starting with a lot of missteps. It was also a year when people made lots of mistakes including:

1. Let’s code thousands of cool web services and see what happens — guess what…no one knew what to do with them!

2. Let’s create a corporate wide SOA implementation this year — what’s wrong with boiling the ocean? (too obvious to make a comment on this one)

3. If we implement an Enterprise Service Bus we are all done with SOA…right? — wrong!

4. Hey, we are reusing a service in the same application but we’re not getting very much value….(try reusing in a different application)

Clearly, these aren’t all the mistakes we made in 2007 but it gives you an idea of what I have been seeing. One of the biggest issues that I saw in 2007 was the lack of collaboration between the business and technical sides of the business. In addition, there was simply too much political jocking for control.

But before you think that I am just in a negative mood…I saw many big successes with SOA in 2007. Many companies are understanding that SOA is, in fact, a business strategy based on codifying business services that represent best practices for business policy and process. These companies are taking a long view — not expecting instant results. Many of these organizations are finding strong returns on investments but they would rather not tip off the competition. Before starting one SOA project, our team had to sign three different non-disclosure documents!

I think that we are at the end of the over hyped stage of the SOA market. It is inevitable in any new market that it begins with unreasonable expectations. When customers start using the approach to solve real problems, it is always harder than the hype would suggest. The reality is that transforming software from purpose driven, single use applications to flexible, agile, and reusable services that are loosely coupled is hard work. In fact, the fact that we are getting over the hype phase actually means that SOA is real!

 

What’s SAP’s Plan: Innovation, SOA, and Winning?

I am back from SAP’s annual industry influencer conference. When I attend one of these meetings I typically take lots of notes on my laptop so that after the fact I can go back and make sense of what the executives actually said. It is a fascinating process. When I take these notes and analyze them I begin to see through the “show business” factor of an event intended to influence.

I enjoyed spending time with fellow blogger Michael Krigsman (IT Project Failures blog) who makes some interesting observations in his blog and the blog of his colleague, Joe McKendrick, who writes a SOA blog for ZDNet. Their perceptions on SOA and SAP are worth paying attention to.

Now, back to my point. So, what do my notes tell me? First, SAP leadership is obsessed with three things: innovation, service oriented architectures, and winning.

So, here is my quick take on each of these issues:

Innovation. In the seven pages of pages I took during the opening keynote sessions of the meeting, I typed the word innovation 25 times. While I am sure that is not a record – every vendor meeting I have attended in the past six months has focused on innovation. SAP’s definition of innovation is not surprising — it is tied to innovation in process. In many ways, SAP is correct. You can have enormous potential for efficiency breakthroughs through a process approach. Here’s a quote that I liked from one of the keynotes, “

It is about continuous innovation. You take the process innovation and industry innovation in SAP, multiply that with the blueprint of SOA. This creates a possible incremental breakthrough. This approach can be adopted in a step-by-step way to create break through. You can bring in new processes and add more flexibility to create a business breakthrough..”

Since I don’t take dictation, this is as close as I got to a direct quote. But what is interesting here is that SAP is talking about innovation in terms of an incremental approach, an approach that assumes a structured service architecture, and the fact that the end result will create a business breakthrough. No one could argue with these points. However, what I kept waiting for and never got was examples that put these words in context with customers’ experiences.

Service Oriented Architecture. SAP loves SOA. In several conversations I had with SAP executives I was told that they were the leader in SOA. And I agree that SAP has done a good job in taking on the task of breaking down monolithic code into modular components. This is a good approach for SAP internally since it means less work for their own development organization when they need to move from one version to the next. Using standards based web services interfaces instead of proprietary APIs helps tremendously. SAP is strong on adhering to industry standards within their platform. What I question is the company’s ability to claim leadership in SOA if it is intended to be an SAP dominated architecture where they own and control all the moving parts.

In my view, SOA has to be based on a heterogeneous approach to architecture. Business services have to be loosely coupled — no matter what platform they were build for. SAP is not the only company I have a beef with on this point — Oracle, IBM, Microsoft, BEA, etc. all would like to have their platform become the SOA standard. This would be a dangerous move for customers.

Winning. I actually think that if any one vendor “wins” the architectural game, customers lose. If I write next year that SAP has accomplished its goal and become the standard for SOA, I will be there first to proclaim SOA is dead. While SAP is a smart, competitive, and technically sophisticated company, it needs to focus on winning based on their customers success in a highly fragmented, complicated, and heterogeneous world.

 

The Oracle Syndrome: why there are no big bangs

I was thinking this week about Oracle. You remember them. The big database company that decided that it would be a big packaged applications company and a big middleware company. I have to give them credit for swooping in and buying their way into a leadership position. While it is hard to buy companies and keep them going, in the packaged software arena it isn’t as hard as it looks. For example, customers who buy a PeopleSoft HR application are not going to dump it just because the company was purchased by Oracle. Software is a funny thing — it lingers for decades after everyone assumed that it would be dead. As I always say, old software never dies.

So, what is my point about the Oracle Syndrome? The reality is that Oracle is not about innovation. It is about leveraging a captive installed base. It is about stitching together packaged applications with business process connectors so that one package can send an piece of data to another application.

Therefore, forget about Fusion middleware. Rather than a big bang common platform under all of Oracle’s packaged applications, it is a slow methodical revamping of small components of Oracle’s applications. It will take decades before Oracle could claim to have a common infrastucture under its applications.

I think that this is the future of software. No big bangs. Incremental business focused innovation will be the rule — not the exception. Does this mean that there will be no unexpected innovations? Of course not. There will be innovations that come out of nowhere and transform the world of software. However, they will not be overnight wonders — the most important innovations take years even decades before they mature and change the world overnight.

How does SAP turn 250 million lines of code into modular services?

I didn’t attend the SAP Sapphire conference this year. I simply had too much going on so I gave myself a pass. But that doesn’t mean I wasn’t paying attention. I am thinking about the fact that SAP’s application environment has more than 250 million lines of code. I would guess that this is probably the biggest application suite on the face of the planet. If I am wrong, let me know. In that context, I was thinking about what does it mean to position the company for a Service Oriented Architecture. In fact, can you credibly claim to be service oriented with that much code in one environment? Now, I suspect that if I were having this discussion with the software gurus at SAP they would claim that they have restructured that code to create a modular architecture. Now I wouldn’t dispute the possibility that a lot has happened since the company first brought R/3 to market as a client/server application environment. But I am wondering how far they have been able to take this. I would suggest that even under the best of circumstances that it would super human effort to turn 250 million lines of code into a set of business service modules. I have one other question for SAP software architectural gurus…how do you turn NetWeaver into an open middleware platform independent of 250 million lines of application code?

And then I thought about Oracle’s approac to business process management.
So, what about Oracle? Are they really very different from its arch rival SAP? I would say yes and no. No, in that if you add up all of the code from all of the packaged applications it has purchased over the past five or six years, it would probably have as many lines of code. The difference might well be that Oracle ends up with a series of applications that are integrated in name only. They are stuck with customers who simply have no interest in oracle’s grand vision for a single applications environment. They just want to continue using the JD Edwards or Siebel application that they have come to depend on and that has been customized for their requirements. The typical customer has no interest in retraining hundreds of employees on something new. So, I thought that Oracle was very pragmatic in coming out with a set of process templates that can create business process orchestrations leveraging existing applications as they are. It will be interesting to watch how this works and the impact on Oracle’s elaborate Fusion middleware strategy.