Every enterprise uses middleware as a plumbing tool to connect up multiple applications/ data points. A visionary company that wants to achieve real-time business and process agility focuses on an end-to-end approach – a visionary approach to middleware starting from integration of applications to SOA, business activity monitoring and business process management.

Abstract

The objective of this session is to discuss and understand the evolution of Middleware tools and products. The panelists debated, agreed upon, differed from each other on what makes Middleware useful. The debate help you understand where Middleware is heading and what you can expect in the future. Panelists also suggested on how Middleware can be leveraged to extract maximum business and strategic value out of it. The session also provides an insight on how customers are using to solve the middleware tool sets to solve some unforeseen problems.

Discussion

Tim Mann: Skandia, a Swedish organization, The UK part was bought by Old Mutual. The UK part has been around for nearly 28 years and largely sells financial services contracts, products that would be pension's, protections, investments to UK through an intermediary channel. Skandia's mutual market capital is about 9 billion and has funds and management of 218 billion.

Our vision is to be the premier open architecture investment provider in our chosen markets. For me, Visionary Middleware sounds like an oxymoron. IT strategy at Skandia started five years ago. Since we were good at marketing we called it Darwin . This marketing initiative had two objectives:

• To develop IT systems and processes for people which focused on the value creation activities in our business
• To create an architecture which was to reverse the IT development entropy and avoided the legacy situation in the future

Entropy is the lack of order in a system and is used to indicate chaos. Development times in projects that had IT content were increasing and so was testing and analysis. This saw time-to-market getting longer. One of the first things that we did, after coming into middleware, was to create an architecture team. Finding architects for the team was a tough task - the first in many of the surprises in our journey towards 'User Middleware'. Having got the IT strategy in line with Darwin , we mapped the "to-be" architecture and the "as-is" architectures.

The second surprise was in creating governance around these things, particularly middleware. We found that many people in the business thought that they owned their IT solutions and the IT people are just to run the desktops. Getting hold of governance is crucial to make middleware work. The Darwin program board, which meets every month, takes all the big technology decisions for the UK .

The other part of our strategy, having got the "to-be" architecture, was then to replace bits of it on a piecemeal basis, and the size of our corporation meant that changing technology in a short time was not possible and not affordable.

Skandia started to build services that it could use in other places. So, when did it use middleware? It was in December 2006 that Skandia, along with HCL, signed the deal with TIBCO for business work to night process. The middleware piece is simple, it's used to join the services together on technologies of different age or different platforms.

Our first real industrial use of the middleware piece was in our fund supermarket, launched in August 2007. The complicated stack is all joined up, thanks to middleware. By the way we still got to resolve legacy issues of our large amorphous technology applications that we got over the twenty years. The things we learnt along the way is that it's quite hard to get hold of best practices relating to middleware and a lot of people said they knew it, but not many actually do. Centers of Excellence do work, but you really got to find the experts. We found it very hard to get experts.

My advice: Don't load middleware costs onto the first project that comes along. We did it and it nearly ruined the business case. Our journey toward Darwin is our industrial strength and an important part in our vision. Visionary middleware for us was simply a way of connecting up.

Ram Menon: Chaos is what every IT professional sees today, because the number of end points is increasing. Transactional information is increasing at volumes of 9x to 10x every quarter. TIBCO is in the business of managing that entropy for you and trying to get people to talk to each other, systems to talk to each other. And I think the biggest issue that many of our customers face is the complexity.

Half of the world's information is still on mainframe systems. There is the J2EE world and there is the .NET world and one is not going to destroy the other. Then there is the legacy custom thing, which is still very useful. Then we have packaged applications that at an earlier time, many of us thought would solve world hunger but right now you are spending $100 million for your next upgrade which is probably 22 months ahead. Now to put all these things together, the IT manager has the budget, which is typically 80% to just keep the lights on and 20% to get some innovation and value out of it. This is the scenario today. So what we tried to do is to first get things connected to talk to each other, to try to reuse the assets and to make some sense out of it. When you are able to do that, you are able to provide a superior customer experience or provide new services.

When I talk to customers, I see a massive shift from database-oriented architecture to a service-oriented architecture. This means the dawn of client server computing is about the database. People understood that data is a corporate asset and you need to manage it. So you built the database of all databases. The killer application on top of the database was your ERP black box and the killer analytics piece on top of that, which always sourced from the database, was your BI tool.

here is a shift, from static data to dynamic data and service-oriented architecture helps in that. Business process management is really the ERP today. I was talking to a company in India , they are trying get all their systems connected. This conglomerate has multiple channels to talk to the customer, what they need is a single view of this customer who might be buying cars, or holidays or even opening a checking account. All these purchases are to the same conglomerate. The flexibility and the ability to create applications, composite applications, on the fly for your internal business users enable delivery of superior customer experience. I think we are in the transitional stage of SOA being real or not real.

Randall Carrier: How to respond in a timely and efficient manner? We know that we can develop a product that can differentiate our company, but many times our competitors are quick to respond. Move from something that is very unique and has a customer value that soon will become something that the customer expects. How do we maintain a consistent stream of revenue in response to the customer shift and their control of what they expect and what they want? The fragmentation of what our customers present to us gives us the challenge of how well we are going to continue to provide value to the sales and services workforce. The concept of knowing your customer gives us the differentiation edge. Therefore we need to provide customer information to a broad workforce that has different needs but helps in the same customer knowledge.

The paradigm in terms of middleware is to look at where we need to be going as we are starting to move away from an application product delivery vehicle to be more of a business process delivery-oriented type solution. Moving forward, the challenge is to transform our technology so as to take advantage of BPM-type schools and service-oriented architecture. This journey is not a single project and will take years.

Allow the front end teams to think about solutions and processes so that they can respond to the changing cultural environment. So given that SOA can provide the reduction in integration costs, increase of asset rate and increase of business agility culpable with business process management, the benefits are distributed in more efficient processes, easier to use systems and leading to rich customer experiences which is the core.

SOA is not something you buy, it is something that you cultivate as a culture within an organization. We can't overlook the political aspect of SOA. Those in the business, who are used to operating in a silo have apprehensions about trusting not only other technology teams that are going to provide information, but also trusting their own peers.

If you look at the core infrastructure of SOA environment, we know that it is not circuits, or bandwidth or BPM tools, they are all enablers of SOA. But the critical issue within an SOA is quality of the services published. If you don't have quality, consumers will lose confidence.

inding the architect, establishing the governance team, creating the dialogue within the technology team, knowing what SOA is and guiding and directing them to come up with what SOA means to your organization. It's a critical corner stone. It is not one project for SOA and middleware; it's a culture that moves you forward.

Juan Mendez: In the process to get to "to-be architecture", the quality of service (QoS) is really the key. In customer services, retaining customers and getting customers from our competitors is all about customer intimacy. It really boils down to the quality of that customer experience with every single touch point as Ram mentioned earlier - we have exploding touch points from multiple channels into our organization.

We at JumpStone Systems have been in the field distributed data management business for over 20 years. Five years ago, we started work on Wall Street with some of those visionary chief architects and chief information officers, chief technology officers. They demanded from us a new class of middleware. At the heart of it was a need, triggered by a fundamental change in the way Wall Street does business that will affect businesses and industries worldwide. The survival, competitiveness and profitability of businesses' depend on two things - "brains and brawn". Brains is how you create products that allow you to be smarter than competitors and allow you to be more successful and brawn is how you create the volume that the sales forces are demanding, how you ensure that you have growing volumes and capacity.

Till a couple of years ago, we believed that brains and brawn was a unique problem of our customers on Wall Street. But emerging from Wall Street after getting five of the top 10 banks to use our software in truly mission critical systems, we went out to the general, commercial market and we realized that brains and brawn really are the heart of competitive successful businesses.

Let me give you our opinion and our customers' opinion on QoS. These are performance, consistency, availability, reliability and the scalability of information and being able to respond to real-time events and complex events. Globally distributed organizations that have non stop business find that most bottlenecks are limitations in the physical infrastructure. The financial service industry in particular demands 100% uptime and zero down time and with customers demanding relentless levels of quality of service. Application development queries would be: what topology, what infrastructure, what quality of service, what fail over policies, and what availability. It shouldn't matter, all of that should be handled by the infrastructure, all of that should be handled by the middleware in a dynamic real time, elastic, highly scalable autonomic fashion. I think that the majority of the issues that the we are facing today is we are getting to the state that we use next generation quote unquote middleware.

Do we really need to buy different pieces of middleware? We live in a world of distributed architectures we live in a world of more demanding customer. The smart use of technologies would enable you to achieve nonstop operations in under normal conditions right. Technologies are out there that help us get to the next level leap to the next level in terms of our customers interaction, in terms of how the use of brains and in terms of how we apply the brawn of our organizations.

Ramarao Kanneganti: Very interesting set of perspectives for instance almost revolutionary statements from Juan, from Ram we have seen how things that are emerging, for example what are the business drivers that are driving the entire middleware space for instance business intelligence. From Randall we have seen how SOA in totality, the integration or one enterprise in totality, how it works that is the culture change. How it actually enables this technology to make it work from Tim. We have seen how the middleware is actually only a small piece in the whole IT spectrum. On one end we see middleware expanding and expanding and taking on different hues of even developing applications on the other end we actually see it delivering on the promise of actually hooking up the things.

Question and Answers

Question (Rajiv Sodhi): I heard two perspectives - one, to keep the legacy as it is but create a complex connecting system, the other, was that if you can really build nonstop systems, you don't need recovery which will redo everything. But, you point out that unless you redo everything you can't have such a system. So where do you provide the balance and what is it that you have to do? Then, there are certain functionalities that you cannot achieve by connecting systems. How do you balance the requirements? Where do you draw the line? Where do you keep moving the line?

Juan Mendez: There are two types of applications that we are talking about. If you look at a green field environment then the opportunity exists to use middleware, use infrastructure and use technologies that can fundamentally move your business capabilities forward. If you're in a legacy environment, the key for success is to integrate the new technologies to solve business issues and pressures that are hitting our existing legacy business.

We have customers, who have about 70 percent of the data in the mainframe world. They want to extract it and publish it out of the processes that are running in a globally distributed world. People in Tokyo need to see the information at the same time as those in Singapore , London , New York . Wall Street needs weigh in this information, so integration with the legacy world can happen through new technologies that can provide new functionality at better return on investment and total cost of ownership to the legacy world. It requires a lot of smart people, a lot of architects, a lot of people getting together to make those business and technology tradeoffs. It is not easy to say, we are going to take a leap of faith and change into a revolutionary type of middleware and architectures. Yet it is also not easy to say we aren't going to do that.

Randall Carrier: It is a question of what is real-time vs. real world time, depending on the business, the availability level and the level of transaction processing for a particular customer. Suppose he demands real time transaction, it could be, yes, I would need to be real time update but back to the question of recovery it might be OK to recover in fifteen minutes, 30 minutes. I think what we see is a transformation of the customer driving us more and more toward a real time environment even though it is unexpressed. To retain customers and keep them satisfied we need to place information at their fingertips so that they can make a decision at 10:00 at night and not have to worry about legacy going into end of day processing.

Tim Mann: If you go around the banking industry or look at the data centers, you look at banks that have done a lot of M&A activity. This is the new system, this is the SAP, and this is new mainframe. You will also find this in the insurance companies. But coming to M&A activity, lot of it is out of legacy systems, most that we've not joined up.

We also have lot of legacy clients and the average client, well it's Skandia, but the oldest one is 28 years with us now. We got a million policies. So legacy really does mean they're going to be around for life because these are life insurance policies. One of the things that insurance companies and technology leaders fail to do is create a breakpoint and say enough this is it, we'll build on the new. We've just done that with our fund supermarket. We have 35,000 contracts on it vs. a million. Guess where all spend goes? It goes on legacy. One of the things that middleware does is to enable us to connect both of them.

Now we need to work on the functionality of the middleware and how much of legacy to connect, the pass back values, pass back transaction information.

Ram Menon: Everybody has to look at bridging the gap. Middleware helps you unlock many pieces of information from legacy. You need to create new types of applications not the old way but in a new way by using existing pieces of business logic that you can put together in some kind of level format to be able to then drive a particular business requirement in a short time.

Question (Chandru Narain): This question is for Juan Mendez of JumpStone. You spoke of the possibility of getting rid of persistent storage and your experience is akin to my own experience of trying to move to SOA at my company. The other point is the fact that you have legacy applications is what will actually make the SOA opportunity that much more exciting. I don't think green field applications are no-brainers. It's very difficult to sell SOA as a piece of technology. But what we've done is at least to retrofit some of our own internal applications, some legacy applications by publishing services for use internally and then lo and behold, tomorrow here comes the requirement. If you can prove that you can do it in virtually no time, it catches on. Selling it as a technology is tough, but as a solution, where you get internal mechanism built-in that you can move it onto other legacy applications, is easier.

Juan Mendez: The point was questioning whether or not you need a persistent storage mechanism, a classic persistent storage mechanism your architecture is really just that. Questioning! Make sure that you need it, you absolutely need it. Or are we just repeating the history. Let's question where each tool is used, I rely tremendously on my persistent storage.

Question (Namish): Do you actually believe SOA will be a technology spending driver? Will it be implemented on immediate demand or do you see that demand rising only within the next five years. Will it change the way companies spend money on their IT systems?

Ram Menon: We've had the same kind of concerns some 24 months ago. After some proprietary research and we see SOA is real. Take the fact that we've been doing SOA for 20 years. So the concepts are not new, the approach is. Our research across 800 North American companies says that about 48% of them have some level of SOA architecture in production. In Europe , it's just over 20%. In Asia, it's kind of more advanced in Korea and India , primarily because of the lack of legacy approach. So, we think SOA is real, people are taking a more studied approach because it is very difficult to sell SOA as a technology. It is actually not a technology problem but an organizational problem. I was talking to a CIO the other day in Europe and he says, "I don't want to hire more architects, for my SOA initiative, I want to hire communicators." That's an interesting thing coming from an old line CIO who is managing 3000 people. Because that's the issue, the whole method of computing has created silo-based architectures which are serviced by silo-based organizations, which find it very difficult to talk to each other.

Randall Carrier: One of the questions you have to ask yourself in the legacy world is, how do you publish something and who owns the publishing rules? Because your business is built in the front end and they are dealing with the customer, they're dealing with the best issue that says I need to have this type of process built with this type of data and with these types of business functions. Legacy is not going to go away, particularly in our environment. How do you take the legacy team and get them to think about open world architectures and get them to move away from the actual silo based architecture? One is the presentation to orchestration, the business process on the data that everyone sees and middleware provides. So, we have a pretty hard stake in the ground that says the producer of the service has to come from the legacy applications whether that is a mainframe application or one that runs on a client server or server based farm. They're the subject matter experts, what business functions are to be accomplished? We find a lot of value in moving towards that type of stake in the ground where it's the producer who has to approve of whose going to consume their services. We don't want these services to be consumed independent of the production because they could end up being utilized incorrectly as to what they were originally intended.

Question(Rosely Herberts): What do you actually talk about in governance? And I say this because we all understand the notion of an architect and a logical design is and why you would want to put one and how to get there. I'm more interested in having you setup your governance discussion with the business people. Who do you actually have in the room and what it is that you actually talk about?

Tim Mann: There's one thing we're doing, replacing the financial and actuarial systems at the moment. So, it is an organization that is largely staffed by the IT people but it's the body that takes technology decisions. I suspect in the past, we have been quite successful winning the argument that IT takes the decisions. We've been right there.

Now, who owns and what are decision rights?. Now thinking about the question, we probably won the argument about five or six years ago, when we proved we could probably clearly take sensible business decision within the IT community. So it's mostly IT, on the job and board.

Randall Carrier: What we did across the board, we had an organization that helps us see the concept of a governance process. We are technology oriented, because it is a technology program. But we have in our organization separate groups, one's business services and they're primarily the ones that we interact with while they interact with the actual business units. From requirements in business function standpoint, that's what the processes are. So in that business group they do a lot of modeling, they are very technology driven and they have a good system sense. Now they set down the governance goals in the SOA environment because they can see the demands coming from the business side, they can start to see the value the delivery of SOA environment. So, they are actively involved in setting direction on what value SOA brings to business and also gives feedback.

Ramaroao Kennaganti: I would like to ask one question for Tim and Ram actually. I have been in the middleware business long enough to see it evolving, taking on different roles in Indian. I'm not talking to TIBCO for they view and they brand application development and business predictive enterprise under middleware. But Tim's perspective it appears that when we look at middleware, it is essentially getting information from one application to another. I would like to sketch it out a little bit if you can.

Ram Menon: What you're seeing is a bunch of things going on, but the fundamental thing is you are seeing "democratization of information" - Information for all with unrestricted access. There are different stages in this evolution. In some cases it's purely a need to connect A to B, C, and E and that's one approach, that's about it. But when you start connecting A to B, C and E and you are comfortable with that mediation aspect , now I've got all my information connected, how do I improve my business process and that's why I call business process management - the ERP of this generation. We have for example, an insurance provider who has been able to quadruple the amount of processing, using a business process automation tool enterprise-wide in Switzerland . That's like going through a maturity phase as you find that the information is unhindered across your enterprise. Create an event cloud so to say.

We have a lot of companies who're kind of, the cutting edge. That's this whole concept in a more esoteric area of computer science called complex event processing, and the concept here is you have all your information which is basically defined as events running coursing through a central bus. You're able to automate different things. Now when you have this event cloud, you're able to see patterns in real time, which is the key issue; you are able to deliver newer services. Let's take the example to cite some of these things that many folks are doing. There is a retail banking enterprise who also does brokerage or who does simple checking account and also wealth management. If you got all these things connected to each other and the find that, for example, Joe has a checking account, but doesn't have a mortgage with us, but is actually paying someone else, because I have visibility into his checking account X number of dollars every month. Complex event processing enables you to really process all that information in real time and provide to the call center person a new offer which is a reasonably customized to this particular persons profile saying hey you know you are with XYZ company on the mortgage, we'll give you a percent off and do it in real time. This is an example where as back to your point, a new class of application services that is being built on the infrastructure that is delivering superior superfine customer segmentation in real time. So you have all these different categories and it really is you know depending on the majority of how people are looking at this and that's our view of infrastructure and middleware in its totality.

Tim Mann: The middleware for application development and that sounds horrible to me. I disagree with your definition of business services and how well the IT services stack up against that. Middleware as far as I can see, it is for joining things up, it's not for producing another set of business rules into an application. The only exception to that would be process automation which is probably is somewhere where you start getting business rules manifested. We did have an instance of this in the fund supermarket, where someone tried to build and use some form of business works and application development. We had to stop it straight away; it is very dangerous because it starts moving outside what we consider middleware for. We might be wrong but one of the things we've got some power in are in what's the model, like what tools are meant to be useful.

Randall Carrier: I absolutely agree with you. You got to have a police force out there in your organization, it's going to ensure that you are not going to turn your middleware which is a managed service environment into an application development team because what happens there is all of a sudden you have two subject matter experts who wins over the team that actually knows the most about the deposit application, that deposit team or the middleware team. If you evolve into that type, we end up having that chaos. If they can publish and create all the services that we require in the organization without engaging any of the application team and that scares me to no end in terms of how I deliver effective solutions.

Juan Mendez: I just want to add a small perspective. I'm in agreement with both Tim and Randall and necessarily in disagreement with Ram. It's not a black and white issue. The way that we see the world and the way our customers interact with the world, we observe that the customers has a clear separation of concern. We try to help our customers have a clear separation of concern between application development and infrastructure, really the way that you want to develop applications. The way that a lot of our customers want to develop applications, they want to work with information and data in the native state that they're going to be operating on it as the business logic. Whether that be a C++ Object or C# object, a Java Object, a legacy type of data, widget of some sort and then the infrastructure that provides the quality of service or reliability, the availability, the distribution,. That infrastructure should be separate and in order to achieve all of this in the real times we're talking about, in a complex and processing environment. You need that middleware layer to combine messaging semantics, database semantics, distribution semantics, cache in semantics, as well as complexive and process semantics, all in a world in which your pressure to response and your window to respond become smaller and smaller and smaller.

Ramaroao Kennaganti: Well those are really very-very interesting answers and I am sure we can ponder on it for a very-very long time. To summarize, extremely diverse points of views not so extreme actually, everything I see is a continuum of thoughts. On one end you have got interesting ideas of where exactly you would within the confines of the legacy how exactly will some new applications that are demanding different kind of solutions and where this kind of evolution of the middleware is enabling newer and newer kind of application that from Ram. From Tim's perspective, the kind of applications that you are used to doing, what is the best way to work and getting the best out of the middleware to enable those kinds of applications to build more and more effectively. And from the perspective of Randall, how to make the culture work? How to bring in the governance so that actually all these can benefit the business. These are all interesting diverged point of views.