Middleware and Applications - Celebrity Software Deathmatch!
Cavaet: I am an independent consultant who works with SAP, this is not official SAP policy or anything like it.
Well, I have commented before about the interesting situation over at Oracle. Recap for those who have not been paying attention to this exciting series of developments. Peoplesoft bought JD Edwards. This combined outfit was then bought by Oracle after a rather lengthy, and from SAP’s perspective highly exciting and rewarding public battle. Shortly thereafter, SAP tried to buy a retail specialist called Retek. Oracle nipped in and bought it out from under SAP’s very nose. Larry had fired up the MiG and gone snatched it from Henning’s grasp.
Very dramatic stuff, but this now gives them four sets of applications to deal with. Now, this is a nightmare from a development point of view, because Oracle now has to convince customers of two very important things. Firstly, that they will not let the customers that they have come to harm in their day-today processing, and secondly that they are going to offer a roadmap to the future that will either allow the customer to continue to use their existing investment, or if they do have to migrate, to do so at a cost that is less than that of simply walking away from the new Oracle family to someone else. (Like SAP.)
In short, you need to come up with a convincing explanation of how you are either going to have four code bases co-existing, or how you are going to move customers onto a new version of one of them, without missing any significant functionality from any of the code bases, and without undue disruption.
Co-existence. Oracle is stuck with the four code bases, whether it decides to keep them as the target architecture or not. Public commitments have been made about the support of the acquired applications, and indeed apparently 95% of the Peoplesoft application developers have remained with the new organization. Oracle needs to find a way to keep these running, but at the same time reduce costs in support to try and make money on a very expensive purchase of a software house at a highish multiple. In other words it has to provide good enough support to stop everyone running away, but not so good that they will not move to the new software when it becomes available, and not so good that the joint organization does not make any money.
Merger: from a technical standpoint, the ideal solution is to create a superset of the existing functions in each of the applications, in a single streamlined environment. This is a rather utopian vision, and a very expensive option. It cannot be done in a single sweep.
Migration: I personally think that the only option is to target main functional chunks in the applications, and replace them one by one, while gradually eating out the four code bases from the middle. What does that mean in the real-world. Well, all of JDE, Peoplesoft, Oracle, and I assume Retek, have some kind of financial and accounting controlling functionality. The requirements are well understood and generic. I would make a module that covered the accounting functions, and then I would provide a set of interfaces, and migration tools that allowed the old accounting functions from the former four providers to be switched off. Then I would do it for procurement, HR, and so on. There are two further options in this. Are the modules all on the same technical platform or not? If you assume that Peoplesoft HR is better than Oracle HR, for example, then would you take the Oracle GL and Financials, as the accounting module, and then have the Peoplesoft HR functions in another Peoplesoft based module? This leaves a problem of the combined code bases still being around, but does leave the option of taking the richest functionality earlier. The other option is to move the additional functions to the new coding platform regardless of which one is richest and best at a technical level. Either of them has disadvantages, mainly of technical complexity over time, versus development complexity in the early stages for the single platform. Either way, to bundle all of this lot together, and to enable the migration, you need what is called middleware.
What is middleware?
Middleware is a broad topic, but essentially it is a series of tools that are designed to link existing information and applications. Now this requires overcoming a lot of problems like making systems and applications with different data models, processing techniques, and so on, all talk to each other. It is not just a technical connection problem either, but often involves the management of the overall business process, and it is this level that is critical to the discussion of why Oracle in particular has a problem.
Why is it important?
Think of the middleware as a big ring that connects all the applications and processes in the organisation. If you want to use it you hook onto the ring, and others can access your information and processes. The issue is a commercial one mainly, because if you are the ring, then there are a lot of users that need access, which generates licence revenue, and the whole thing needs to be installed and implemented with all of the different existing systems, and that is a bespoke implementation, so there are potentially large consultancy fees. Also, from a vendor point of view, if you are the ring provider, then the other applications have to hook onto you, and your future in the user organisation is assured for many years. If not, you are just a service on the ring, and you spend your whole life hoping that your TCO (Total Cost of Ownership) is good, if not then you are going to be outsourced, replaced, or otherwise made unhappy. What it means is that you loose account control, and in sales, that matters.
Who are the players?
IBM with Websphere, Microsoft with .net and in the ERP space, SAP with Netweaver, and now Oracle with Fusion, when it is developed.
IBM want services
MS want software sales
SAP want both
Oracle needs a future that isn’t being a service on the ring, and they know it.
What it has to do in detail
Middleware has to do lots of stuff, like convert mainframe character sets into PC character sets, and push messages over networks, and all sorts of clever technical stuff. But what are going to look at is what is needed to manage a business process. If some of this looks familiar, it probably is, most of what I am saying here has already been well covered by IDS Professor Scheer and other organisations. (To those not familiar with German business culture, being a professor in German business is a Good Thing, and so why not say it upfront? One of Switzerland’s main electrical retailer’s is called Dipl.Ing. Fust (Engineering Degree Fust.) after all, would you go and buy a machine from an unqualified 16 year old? Ah, Dixons in the UK… Right.) Anyway, they are very good at this kind of thing, and so it is worth taking note of what they would consider is the right approach to making a process work.
Managing a Process
Let’s take a reductionist view of the whole thing. What is it that we will need to accurately and completely describe a step in any process? Let’s take a simple one, like paying a bill.
Predecessor Event: what was the state of the world before we did this step? An invoice has come in, and it needs paid. It is from the local electricity company, and it is valid. We will pay on-line.
Process Step: what do we do to actually carry out the payment? Let’s assume we log-in to the e-bank, type in the invoice details, and then approve the payment. We might get an e-mail confirmation.
Successor Event: Now what is the state of the world? The invoice is paid, at the bank, the confirmation has been received, and the invoice is now in the bin, or filed marked paid, depending how fastidious you are.
Data In to Process: what information did I need to put in do this? I needed all of the log-in information for the bank, maybe a token from a secure log-in card, I needed the invoice itself, with the payment codes, amounts, and dates. The banks needs my account information like balance to see if I have the money available to instruct this payment, and so on.
Data Out of Process: What information is created in the step? The invoice information is now in the Bank’s payment queue, correctly authorised, I have a confirmation, and my bank balance has been updated. I may also have ticked up the login information for my account so that I will need to use a unique number for the next payment.
Organisational Unit: what people were involved in this? I was, as a customer, the bank was, and the electric company will also be involved, and all of these have to be shown as organisational units in the transaction to make sure that all documentation and controls are in place.
System Unit: underneath all of this there are IT systems, like my PC, the bank’s current accounting system, and the payments systems, which are often different, and the receiving bank that services the electrical company’s customer payments accounts. We need to be able to direct information between all of these correctly. To take one example, a customer service representative in the bank may help me make a payment, by using both the bank current accounting systems, and the payment system. They are one element from an organisation point of view, but two from a systems perspective.
Where did the respective middleware's come from
So, things we need to manage:
- Predecessor Event
- Data In
- Data Out
- Process Step
- Organisational Unit
- Systems Unit
Now, if we look at the Middleware that we are talking about they come from two very different angles. Both IBM and MS are looking at technical middleware which is about how the machines and files get from A to B, and different technical formats are controlled and so on. Now this is important, and necessary, but as neither firm really has any business processing and ERP experience they are not managing the business process directly. SAP, and putatively Oracle, are less worried about the provision of the technical layer, and in fact are happy generally to co-operate with IBM and MS on this bit. What the concern is for a business software vendor is manage the business process, surprisingly enough. And in order to do this we need to have access to all of the elements above, but this where the problems arise for Oracle.
Why is SAP different to Oracle?
SAP is working on a foundation called NetWeaver. It is being touted for the first time as a middleware solution, but most aspects of it have been in place for years, if not decades. The development environment controls the data model, the code, and the user interactions. It is possible to hook onto web services, and use Java to interact with other non-SAP systems. This is a very high level summary of a big piece of kit.
What does this mean for the middleware and process control model?
Events: these are basically held as data. An invoice in the database that is not marked as paid will be found on the next reading of the database looking for unpaid invoices. This could be triggered by internal or external events, i.e. read this once a week, or update when an invoice over 10,000 EUR is received.
Data is controlled by the NetWeaver environment, which uses Oracle, DB2 or other database as a simple data dump. The model is controlled by SAP. Access to the data is not via the SQL reading of tables for users and programs but through the use of what SAP calls BAPIs (Business Application Programming Interfaces, which are object orientated interfaces, that control access to the data, both allowing SAP to have complex data structures in the underlying tables, and to change them as needed without changing the access methods. It also imposes consistency checks on the data processing, by preventing direct database update.
Processing is done within one environment, with all of the data, and other logic being available to all parts of the processing, i.e. because it is one environment, all parts of the process are visible to the other parts, as required.
The organisational units are held in a single set of shared referential data. Thus, information from accounting, human resources, and so on can be called by all applications, and the data will be consistent and up to date.
Systems units are built into SAP using a combination of BAPIs to call across different applications, sending and receiving messages, and this technique is extendable to work with third party systems.
So, the events, process, data, and organisation and systems information is controlled directly by SAP in one place.
What then of Oracle/Peoplesoft/JDE/Retek?
Here we have the problem. There are two approaches that I can see for Fusion. Either re-write all the applications to a single model, and take the hit with the fact that you will loose many customers with the migration phase. This would work, and eventually might deliver a single platform for the system, but all four of the current users bases would have to migrate, and it will take a long time to get there. The other main option is do what is called componentisation, where the existing applications are put into blocks, and “wrapped”, so that they can co-exist. This has the advantage from a commercial point of view that it is phased approach, looses far fewer customers on the way, and the eventual migration is slow and relatively painless.
The main limits with this are as follows:
Events: are now distributed into four different components, and they need to be able to publish their state to a central database so that processing can occur appropriately. How else for example does the accounting system know that there is an invoice to be paid, if it has not been given the event? Both predecessors and successors have the same problem about broadcasting their current state. This is fundamentally because the run-time environments of the components are different. One is in Peopletools, another is OneWorld, and so on, so they have to find artificial means to describe their state to one another, where a single run-time environment can do it internally.
Data In and Out. This sounds like Oracle’s main integration point. They will post the data from one area to another via the database, or the application server where a database write is not possible or advisable for performance reasons. This implies that they will have to find a new common data model for the four application bases. I hate to be a sceptic, but this sounds like a tall order. There is a joke in IT. “What’s the difference between a data modeller and a terrorist?” “You can negotiate with a terrorist.” Imagine the scene as three sets of application architects argue, not just about how long a cost centre field should be, but where it is used, and what the implications of changing are for their respective “components”. IT professionals everywhere shiver in your socks as you imagine the carnage…
Organisational. Eeeks. All of the referential data is held in the different components in different ways, and needs to be synchonised. Yes sir, it’s going to be a “master data server” project. Everytime someone updates a piece of master data we will have the information updated in all relevant components. Someone who has never tried this in a multiple systems environment thinks that they can do it, and the disaster begins. Take an example: customer master record. I update it, and I have to send it to four applications, all of which handle a customer differently. Name and address might be OK, but how does one system signal whether the customer is blocked or not? How does the accounting take place? All of these controls have to be done differently for each component. Effectively you need the control data for four systems. User friendly it ain’t, and that’s before you start handling four sets of conflicting error messages.
Build the foundation before the house, and not afterwards
The problem is that Oracle is trying to rebuild the foundation whilst not alarming the people who are living in the house. Basically, it doesn’t work very well, and in this market, as my friend Hugh of GapingVoid says. “In this market you are either the cheapest or the best,” and this is neither.
Being eaten alive on both sides.
So, from Oracle’s perspective they are getting it in the shorts from the technical middleware providers – IBM with Websphere and DB2, and MS with .net and SQL Server. They have decided that the only attack route left is SAP, which given that SAP is bigger than the next three or four rivals combined, makes it look like a pretty desperate strategy.
Comments