We have spoken, read and heard about SOA. But have we seen it at work? How does SOA change the way we do business? How does SOA impact business-critical functions?

Abstract

The session explores the real implementation of SOA in business processes and how it impacts the business objectives. What are the key factors that help in successfully implementing SOA? Panelists shared their experience on implementing SOA in their organizations. What were the real challenges that they faced initially and what path they adopted to address those issues? How governance can play an important role in implementing SOA in business processes?

Discussion

Ranganathan Krishnan: Welcome to this session on SOA@work, transforming business as usual. My name is Ranga. SOA is talked about pretty lot in multiple forums. We are trying to focus on business driven SOA, in a sense that is SOA really working for the businesses. Many of our customers come back and look at us to help them build business cases for SOA projects, also looking at a lot of business related problems, business transformation and how SOA supports those kinds of activities. We're very fortunate to have a panel with us of which most of them are actually practitioners. People who have actually done, implemented SOA have tried to solve business problems using SOA related components and tools.

Vladimir Mitevski: During the exercise of trying to identify how to solve a specific problem, I came to the crossroads to decide either do I buy or build a specific tools be able to manage my services and in particular the case. We actually had a problem with managing the services and understanding that who is the user, who is the consumer, who is the provider and at the same time control each of that. So we started implementing SOA from a different angle, and understanding what we have, what is our asset. We did that by implementing couple of tools that are on the market these days: Registry, Repository, Power Sync Manager, so that was our approach that we implemented and with that we also did a little bit of different approach than everybody else. There are talking about in the industry, usually SOA and all these tools that are used, even the vendors are promoting them as tools that you can reuse, anything that, any service that you can reuse is pretty much. You need to register with the service tools or the SOA tools. How to reuse services when I don't have a clue of what I have? My thought was, let me register everybody and let me start governance regardless if I can reuse, if I can decommission something. So that was the approach we took. The company is maturing as the tools and services are maturing. We are moving from registering to policing to enforcing and now are at the stage where we actually enforce governance and for the new services that we are building we have in mind, how to reuse it.

Claude Zamboni: I think the paradigm at power wave is very different in the financial area. I realized there was a huge business culture gap and that was not only disparate for which we could build middleware. We could have addressed it as a technology issue, but really what we saw was a lack of maturity of business process. Many companies that I have talked to throughout my tenure, experience the same issues of is business process being different from region to region and place to place. So my first attempt to address their appetite for SOA was let's get the act together on business and it is very difficult to have an IT guy say that, because they are going to say what do you know?

We implemented Oracle as early as possible, it has a process let's see if it fits but you have to adhere to it. Once that foundation was placed in, it was accepted by the business and was utilized in the way it's supposed to be utilized. The difficulty was there was no cohesion there. We did not see a uniform acceptance of business process across the globe. It was necessary for me to deliver, from a low cost solution, to provide something that's system agnostic from the user's perspective. I needed to make sure if they were utilizing the system properly. So there was a lot of pressure, we needed to not only rollout and get systematic and uniform across the globe but also to provide some quick win for the organization.

So the best thing we could was get the system in and try to get adoption of business processes at least from a level such that the executive management board, discipline the rest of the groups and later we could start putting up portals. I attempted to do some of these things quickly and it wasn't very good, it was sort of a disaster because we did not have the utilization that we needed to get the information out to the customer when they need it.

We were able to roll that out in a small segment. But I think what's critical from a business perspective is IT can implement but you got to have to be successful not only in SOA but related things as well. There's got to be a partnership between IT and business. A standardization of how the process works and how to put a system up and around it but you cannot put multiple systems or applications and expect to have cohesion.

Ranganathan Krishnan: The most important thing is to deliver the data that it is required seamlessly. In that context Partha do you think that CEOs of the current time really care about SOA or just looking at the problem to be solved? They don't bother about doing it SOA or not. What would be their priorities?

Partha Iyengar: What we see the business caring about these issues where the semantics between, what IT talks about in terms of what Claude was saying and what Vladimir was saying about some of the buzzwords that the business wants to hear. That is often the big disconnect. From the CEOs perspective if the message regarding SOA has to be a more responsive, IT organization which says if this whiz bank gadget that you keep talking about lets you do twenty percent more or 2X more than you've done in the past and you can do it 40% cheaper that's the kind of business that the CEOs and business line leaders want to hear. The first one I think his don't underestimate the power or the need to get your semantics right, because especially with something like SOA the same terms could mean very different things as you said, from the CEO level down to the programmer level. The CEOs overview, so if you have SOA as a very technology driven project that's probably the worst place to start. But we see a lot of clients starting there using SOA as a technology initiative. An SOA initiative that is not tied to the business leaders, not tied to the business analysts, is not giving you a long term growth path into truly achieving the end goal of business. The second issue we see from a business driven SOA perspective is many organizations that have recognized that SOA is a business level benefit, usually also have a business process management initiative, a BPM initiative. One of the issues or challenges is these two are really two separate initiatives and that is a very clear danger that they can pass each other like ships passing each other in the night, unless they are integrated in a very specific governance mechanism in a very specific where there is overlap of skills that are driving both projects. There is overlap of sharing of information from both projects so that is the other key message I would suggest the business has to take hold of.

Vikram Duvvoori: From our perspective having seen the evolution of this for the last few years, what we are seeing is for a lot of the folks in business today SOA is a plumbing on infrastructure but its also a way for them to get the business to be more agile in specific ways, one around processes they want to be able to automate inventory and also optimize those processes and they want that to have a solid foundation which is different from the way they were doing before. So that's the place where we're seeing a lot of convergence of process automation and the SOA forming an infrastructure that comes with it. But at another level there is also a big cultural change/shift. So SOA and process automation both have something in common, they break down silos. So you can't just have an SOA initiative or BPM initiative that go in parallel but you need a lot of coordination. But the good news is we are seeing more and more of the businesses are doing it.

Ranganathan Krishnan: You had a particular business problem. What was it that you had to do to convince your CEO for the budgets, for example, for this kind of an initiative toward the business case?

Vladimir Mitevski: It was really a business process that we were struggling with and we needed to put the governance behind it. So when it came to the budgeting point I had I was given two minutes to talk to my president in terms of financial to sign my check or pretty much walk out from the office. I quickly adjusted my conversation before I was talking around the details of the technology and the tools and I lost the guy. So at the end I said, Oh! simple what it takes now, six weeks with twenty people. He said, I didn't even finish the sentence, but he said six months. I said ok that would be acceptable. So we implemented the tools. The task was done through a way of first registering what we have with that actually putting the full workflow, really the business process behind it with a clear ownership and we took the ownership from the technology guys to make a decision for the business. We put it back to their business to drive their product through the lifecycle and have the clear ownership and not to blame the IT people, and at the end we actually put before we went to production any new service. We put the ownership to the business that holds the P&L at the end. They quickly realized that now if they made a mistake or they didn't have proper sign off from all their things, they will not press the button to move it to production that one also created a positive effect on the other side. Whoever was the consumer now he was at the end of the day the provider and the consumer was tied to the P&L. When you have the P&L people approving and moving the service in production that's when they realized they really cannot just blame the technology. They got to look at it and the details so that was our business case in more detail then.

Ranganathan Krishnan: Your way of saying that tying P&L on both sides provided the consumer. That's the best way to take in; another best practice that I can take from this is how to get a budget approved from the CEO. I'd like Claude to comment on the fact of that you need to deliver.

Claude Zamboni: You know the thing about so often from the perspective of how the business perceives it they really don't as Vladimir indicated. They just want to be able to lower the costs they want to be able to have a quicker time to develop in which means faster to the market for them. I still go by and it's a prophecy that I have, I'd rather use that word because you have to you have to still build that foundation I think the business process again. With Oracle we were able to indicate standardization and even though that it's truly not what I call a classical SOA. We were able to say look, the ability to go module to module and go cross functional. You would be able to build some efficiencies in your process, but I back to that place, is the process has to be consistent, and it has to be not only between your organization; be it the finance organization but needs to know how to impact the logistics, the operations, the factory floor everything needs to be known and consistent across for us to be able to deliver stuff that is lowering costs, faster to develop and quicker to market. That was like the number one poof concept and that has been extremely successful and what that allows us to do it allows us then to take what we started in Oracle as a small segment of the services that are available and provide real data in terms of service call returns in terms of customer satisfaction, in terms of knowing when shipping is going to occur, given that visibility out there to our customer base. Oracle has a fusion product that they consider the middleware for SOA now there are as many different solutions but it allows us the opportunity to interject that would putting some boundaries around understanding what they're going to get and what their expectations are.

Ranganathan Krishnan: A couple of things Claude mentioned are very much up your value. One is the process standardization bit and the second thing is business monitoring, where we see the KPI's and the dashboards kind of things. So we have always considered the business facing part of SOA is business activity monitoring and the BPM process kind of thing. What has been your experience in this?

Vikram Duvvoori: One of the challenges that anything to do with SOA is that it is just all over the place we have customers who are just starting on small engagements and then this takes rather a long period of time because they're hesitant to jump in and their customers are going full steam, a few hundred people team going through all their processes, taking inventory and saying, how do I go this step by step. There a lot of more autonomous activities that are now becoming interdependent and any change is hard. So part of this effort in terms of process standardization is even when we have dependency, they can be transparency and standards by which we have that dependency rather than some obscure dependency by using industry standards, by using just getting into technical stuff BPM and BPO, etc. You can agree on process standards as well. CEO of a very large fortune head company said that there are reasons why people do not want change instead he just looked up and said well people hate change and what we forget is its not just a technology change even though we say its technology. It is big change for business. As I said the business users signing off the P&L signing off. It means that they cannot now blame my team. So these are fundamental changes that one needs to be prepared for and not just look at it purely from the point of view what technology team has come in.

Ranganathan Krishnan: Vikram, you're getting into the area of what we observe as best practices and things which make it work. I think I want to buff it and take on this trend to talk about what do you think would be the precautions or approaches which somebody should take to make sure that businesses perspective an SOA initiative can actually succeed.

Partha Iyengar: The successful SOA projects will be as much as a change management initiative as a technology change of technology initiative and the two have to go hand in hand. The cultural change that has to happen if you're truly are going to embark on a SOA initiative; is there has to be a fundamental rethink at all levels of the organization but primarily first within IT of thinking of stopping this whole thought process of software components to business components and there's a whole evolution there and there is a paradigm gap unfortunately in terms of how do you make this happen? How do you get your IT to start talking the credit rating services? How do you do that transition? Beyond services we are all struggling with SOA but heads up truly to deliver the next level of SOA. There is new architecture that is riding on the back of SOA which is event driven architecture. So even as you are coming to grips with this new animal called SOA, you have to have the business understand the concepts of EDA. The good news is that EDA is actually more intuitive from a business person's perspective, because event driven architecture gets us closer to how enterprises typically work. So there is a significant evolutionary chain that has to start in IT, but has to take the business along with it. So you have to back to the semantics; you have to simplify it; put it business terms. Otherwise you are going to lose the race.

Ranganathan Krishnan: We spoke of actual reuse in measure and also Vikram spoke about how reuse is not only there we can look at a business case … into his business. Vladimir, what has been your experience in ensuring reuse and the governance mechanism that you mentioned about? How you cut across multiple groups to make sure there are reusing it? Could you share your experience on that side?

Vladimir Mitevski: As I said I would go still in the process of first understanding what we have is an asset and then we went from really between the business and IT blaming, each other to put a clear process and workflow behind it and put the ownership on the business now for their own systems. We also did a different approach which was the step-2 that we took is the governance. You are shifting the main ownership to the business side and they are the ones because they own the P&L and now they see what they have, what is their asset which means now they're coming in. They know the asset so if the IT guy comes in, development and whatever and they say we need to build this and we need so much money on this, they come in now and also wisely coming in and saying but hold on one second why can you not reuse these things. So we're starting to do that we have registered over 2000 services and we're growing. Daily we're discovering things that we did not even know that we had and then at least I did not know that we had it and now we're trying to reuse all of those and some of them decommission them because we have files each in some cases.

Vikram Duvvoori: I think the question in terms of the impact and metrics related to support and maintenance as opposed to reuse. So if you're looking at change request as an ingrained part of your maintenance cost or your ADM budget, then I think its just that more changes are being enabled, because you have suddenly given business hour flexibility but definitely if you are sub classifying it and saying how much would I be paying just for maintaining functionality and if I measure that definitely most of the cases we've seen and we report this back in some of our large governance systems. That's our engagements where we have very large engagements; we actually report that back in our quarterly governance steering committee meetings. We are finding that there is significant drop in that but the net spend may not necessarily come down because you are automatically seeing the business get excited about it and reduce the number of change request are significantly higher we seen in the log. But they are very happy about it, what they think, At least that's our ... anybody else wants to come.

Partha Iyengar: What is maintenance and support in a pre SOA world may not be the same as maintenance and support in a SOA world. Many organizations have to get over that debate in the old world have said anything that required say less than X hours, person hours of effort we will classify as maintenance and support etc. Those kinds of rules break apart when you step into the SOA world. So you may need to take a step back and say, this is how we'll define maintenance in the SOA world, maintenance and support. So without kind of saying, has that happened or not and I tend to agree with Vikram that I think there probably isn't sufficient data yet to come out with the pronouncement that SOA will help in reducing the maintenance load at least none that I have seen. But I think the key corollary to that is you do need to change your definitions of what you call maintenance and support and start socializing that within the organization.

Panelist Answer: We're doing this to reduce the maintenance costs as a matter of fact. I think if you take that approach, I have seen actually even in our organization in 2002, 2003, 2004 we we're talking about cost reduction with that we increased the risk tremendously. So then the business flipped it and said no, we got to reduce the risk which means lower the risk that but reduce the cost. Here you are not reducing the costs. You're saying you are shifting the costs from one side to another side and in our case as I said it took twenty people to release a product with the perfect orchestration synchronization in a perfect time and everything was batched in 100-150 services at one time on a specific day and if one had some problem you need to roll everything back. It was a painful time so that's how we calculate the ROI that it is much smaller so

Ranganathan Krishnan: It is one interesting angle here that I got one customer who said hogged and I understand you are also a hogged customer. If you look at the legacy part of the landscape and we have a hogged kind of an application. Is that an important factor for you that the maintenance costs on those legacy applications are actually expected to come down because you adopt SOA?

Panelist Answer: No, it is not an expectation if we were to anticipate. What we anticipated is not necessarily the expectation of the maintenance going down or shifting that we were now going to be focusing on the processes. That's where's your time is gonna be spent. But if you're in the process with the basic BPM tools, the various capabilities of the delivery channels themselves they could be still delivered quicker and faster and what we're starting to see through the abstraction, what SOA brings to software (.net) community, what used to be maintenance in hogged is now really maintenance of the process, because what it was designed to do 20 years ago was to do everything process, system and the whole thing. We're seeing the shift away from the legacy, once our services are published. We see the shift away from the legacy of over into as to how we improve the processes to consume those services.

Panelist Answer: That is an interesting summarization. I think what you're saying is the maintenance dollars have moved from technology dollars spending to maintaining the technology infrastructure to business impact and trying to see what your process being one of them but changes enhancement to them is also business. That a very interesting observation.

Panelist Answer: If you have a dysfunctional process set SOA actually exposes you to the risk of making mistakes faster and with greater impact across the organization. So I just wanted to throw that out as a caution. You do need to either restrict your SOA initiative to a such a small corner and that may not be all that bad and it is good to start with a pilot restricted to such a small point of the organization that it doesn't get exposed to the broader processes but as you start expanding this, the SOA initiative, you better make sure that your process is a reasonably well rationalized, standardized and you don't have a dysfunctional process set.

Ranganathan Krishnan: Typically in this industry packages like ERP packages like SAP and Oracle Financial packages wrap a lot of business value that is the reason why customers buy it. But they are also in contradiction with an architecture like SOA where the package is expected to expose a lot of functionalities. So you can link it from a process angle so in that context I quickly like to check with Claude as well as going back into Vikram side on what do you think is the perspective of packages vendors in this whole discussion. Are they going to be the custodians of SOA as they go forward?

Claude Zamboni: Oracle in itself, we built adapters internally and they're truly adapters that are very flexible, repeatable code that goes from application to application and database to database with our particular organizational applications that we have but do I see them capitalizing on a lot of the smaller groups that don't have a good understanding of what SOA brings to the table. Yes, I think you'll see SAP, Oracle jump on that because that is a huge market that is such a demand for it that they say better jump on this and guess what they have a packaged applications and you'll be paying maintenance for that application for ever right so that is a great revenue stream for that company. So I think if you limit which is very important, what you're saying if you limit exposure and do it very slowly and do it has a case by case basis you're going to build the momentum that is going to be necessary and also build the confidence with the organization. Architectures to me is as the structure above the foundation and the foundation always comes back to business process, business process and sharing of information get that down; the rest of the implementation could be done; there is a lot of smart people out there that can do it, if they understand that SOA is really not a technology but is a communication conduit.

Vikram Duvvoori: The challenge if you let all of your custom applications be built on a standardized platform is you are defeating the purpose of standardized platform. SAP's core strength and a lot of customers that we see use it for you is that you get standardized and unified processes. So you don't want to know the core SAP system with a lot of flexible innovating process that you work on and there's usually a way that you can draw a boundary between your core systems that your packages support and the addition of flexibility that you want and the interaction with the process that you want. That is a differentiator for you and not necessarily part of the core packaged offering. So there is a reason for both there is a platform and the foundation that you need to use but I don't think conceding the whole SOA strategy to the platform vendor is optimal for most of our customers. You see in these divisions of who does what is dependency right, what is the biggest complaint you hear about many packaged applications? People feel that they take a long time or because they're so central to the organization that a small problem can shut down the entire enterprise. So the is a way for you to draw those boundaries. To prevent the fire from spreading this is a way to localize your risk. So essentially what you may want to do is use the SOA platform from the strategy of the vendors to dovetail into enterprise strategy and their SOA strategy into your strategy that don't necessarily concede it, because you don't want all those initiatives to now become dependent on Oracle initiative or SAP. Every project cannot have a dependence on your Oracle team or SAP team and that's one of the reasons why you want to draw this separation.

Partha Iyengar: The whole issue of SOA in the context of the package vendors is really interesting and we coined this term SOBER/SOA to describe another acronym for you by the way. But SOA really was defined in the context of what we saw the package vendors recognizing they needed to do which is marry the package world with the SOA world in some shape or form now we don't believe they did it or will do it for altruistic reasons just to give you the flexibility to not be locked into them. But they did it because of a few different reasons. One is I think this is an increasing recognition that with the pace of change of business across multiple industries and the increased demand from customers for very different kind of functionality. The recognition that no packaged vendor, even with the resources of an SAP or Oracle can continue to keep pace with that and be all things to all people. So they future in terms of being relevant within your organization's was dependent on allowing some level of openness and they would go to different lengths to kind of protect where you can draw that firewall so that their relevance is not reduced. But they recognize they have to give you some level of openness to tie in other things that they either cannot do or will not do for whatever reason. The second aspect is a recognition that packages do not give you competitive differentiation or you had to customize the package to such an extent that you almost don't recognize them as the original package was started with. You can implement the package for 70% of your base functionality within the architecture of the package. You can add on the other pieces of the functionality that will give you the differentiation as opposed to now. So the pendulum swinging back to where the core applications within the company are all custom developed applications, because that's where the focus is. They do want to keep that kernel around the packaged applications space and that's going to be another key driver for you to consider in terms of how you marry the packaged world with the SOA world.

Question: From an enterprise standpoint what are some of things that you would suggest we keep in mind for interoperability between how SOA is implemented by versus another?

Panelist Answer: We have to talk about standards working with each other when they are defined as standards. There is always innovation with standards. So why do standards need to work with each other? Because they should be standards; they don't even need to make it work with each other. But the challenge is that there is not enough in the standards for you to be meet your business needs today. Significant improvement from before, but not enough to meet all your needs. We had to within HCL develop some IT frameworks and solutions and thing from the vendors to kind of the bridge that gap. So the reason why you have standardized solutions still not working with each other is these products whether they are platform SOA or different SOA solutions. They have certain variations in that additional layer that is not consistent that is the reason why you have that. The strategy to make it work is still to focus on how much of that additional stuff beyond the standard you really need. Do you really need auto discovery, do you really need some… dynamic binding or is it something else which is already well standardized and which works well that you can work with. And maybe you should push when you're working with the vendors to say let's have the interop for the app. So there are ways you can do it by saying that we use the core standards, where standards are not fully meeting my business needs. Let me understand and consciously fix that rather than just jumping to what the vendors is providing. I think those basic strategies probably do solve 90% of this challenge of interoperability.

Panelist Answer: What is really SOA, what is SOA doing for us? What is it trying to sow for us? And at the end of the day I look at it as flexibility. It tries to help us to be more flexible to be more agile, but all these packages that we're talking about, I am being locked by vendors. So I personally don't believe in the packages. I think that probably I am trashing out SAP in this particular case. But that is my opinion because that is actually gonna lock you and if they gonna lock you into a same thing with a different package, with a different,… on top if it. So from that point on again I don't believe in packages but to your interoperability point. What is SOA really I mean I 'm looking it as agility flexibility and vendor independent but what are you telling me that, the vendor is telling me, Oh its a problem because of this vendor. No, its your problem, because it works only with your thing but doesn't work with other vendors. So make it fix it pretty much so that's my…

Question: With SOA I just wanted to understand how complex would the IT management become distributed components loosely coupled? How do you manage this infrastructure, root cause analysis, application troubleshooting? How has the infrastructure technology evolving?

Panelist Answer: I have every service needs to be registered and every consumer, consumer directly from the registry, otherwise there is no pretty much you can come and complain if a service has changed with that it actually puts a clear ownership, which means if you are publisher, if you are provider or face service before you actually change it you got to know who is your consumers and that's what we're actually struggling today with any application; doesn't matter if it is SOA, no SOA. You have no clue who is using your service. Therefore, you register it, which means in this particular case I will tell you in our organization I control the systems. So I define the process base from what the business wants which means I have implemented the gate, I don't know the data, I don't know the services, I don't care about the data, but what I care is to make sure that everybody synchronized, which means if a publisher changes his service, he needs to go through a very good life cycle and approve a process, which means he needs to inform all his consumers and he knows based on this information and consumer needs to sign off or else he can move to his new service to the next state. So that's where the ownership is actually much better but who troubleshoots it, again who is the provider and at the end of the day again the consumer and the provider needs to get together like any other application regardless of SOA or not.

Panelist Answer: When you have centralized governance, where everybody goes to the central thing. It is much easier simply, because let's talk about a specific example right down times for backups and updates. Your basic remote infrastructure management has to change. This is a very simple practical example. Think about of this state in Oracle magnitude side. Advantage of his infrastructure is all of this common infrastructure is going through common governance. So if you have the separation of critical elements that support your service or architecture, the critical common services be organized in some clean way with some rolling ways of supporting and managing them. I think you can have a very good way, you still need to change. But it doesn't become a nightmare. You can actually organize it well, because now you can do it in phases. You don't have to bring down the whole application. You can virtualize your services is what happens to some of the largest client that a customer has. They have different data centers, different providers. They virtually switch the service provider on the location, do some changes to the service. They have different versions of service in a way so it actually enhances your ability in addition to making it complicated. We focus too much on application. We also have to think a lot about the underlying infrastructure that is not the knowledge and lessons learned, and it's very important to kind of think about it and go through it.

Concluding remarks

Claude Zamboni: The cornerstone for success for SOA is to define the communication and maintain consistent business practices at every functional level. The other thing is there has to be a paradigm change for the users. We go back to the sharing of data, specially in our case as we are small very regional, there was a hold the cards close to your chest type of environment. You have to indicate again what a bit of a tit for tat for shared data and that has to be established and has to be done from an executive level down. I first have to get the awareness that SOA is a culture. Once it is a culture then the rest again will flow. Once people understand what it can to and what processes can be improved with that and how it makes it did today living better. Now talking in organizational terms, will it is basically interpersonal relationships out there and once they get that, you move forward very quickly. So basically SOA is communicated, is implemented first by communication. In Vladimir's case the amount of acquisition that is going on just emphasizes the need to have a uniformity on how we're going to divide the services and it is much more difficult when those services are constantly, suitable acquisitions are constantly getting bombarded on both the business and the IT group.

Vladimir Mitevski: You got give executive buying and make sure you have that. The second one is you need to socialize the ideas and make sure that culture, because you are really changing the culture and the way people think you need to show a very clear ROI, and ROI doesn't need to be in the dollar number or percentage. I make a expense to the company but at the same time it is very simple that I can add my ROT to my finance guys who are and tell while I use to take X amount of people now, I can do it with at smaller force and what used to take x amount of time I can do it much lesser. So really its, that is what is very important for the finance, because at the end of today at least in my case the finance is the one that actually makes the decision. The business may say yes, but finance don't pays. You need to have a support from the executive aspect, otherwise you are done; you're not getting anywhere.

Vikram Duvvoori: When you look at a lot of different things if architectures are built for the right purpose, whether is business architecture or a political architecture or we can say IT architecture. I think it has a tremendous impact on business. Some of the key things being not just technology, there is a lot of things about culture and the culture stuff is not really just about one or two things. It is about governance; it is about who is responsible? Who owns and who controls it or who is accountable? It is also about how do we decide who gets to build which service? It is about budget and maintaining which didn't talk about. So as long as they are specific ways that one thinks through this and incrementally works, I think we have addressed a way to kind of move forward and to sometimes take a leap of faith as long as you are very clear that you had a clear strategy.

Partha Iyengar: What we believe is guiding vendor behavior. One of the key concepts that we have put out there are some time back is this notion of stack owner which if you recognize what actually delivers services within your enterprise. It is actually a pretty deep stack and today the stack owners are the package vendors. But as we increasingly move into the SOA world, the danger that the package vendors see that stack owner throne that they sit on today could get challenged and a lot of the behaviors and the challengers could be, some of the middleware vendors could be, some of the services vendors could be. So the challenge really that you have to sort out internally. One is try and maintain control over who you want to be the stack vendor. Don't let that happen by the path of least resistance or by a default, because if you do, you lose some control of your destiny. If you believe from an architecture perspective that it makes sense in the future to have the middleware vendors be the stack owner, then make that decision consciously. If you believe it is OK to let the package vendors continue to be the stack owners, then make that decision consciously.

Final Conclusion

Ranganathan Krishnan: One point that Vladimir made the 30 second pitch to management. I think is a key take away in that don't plan on a 20 slide pitch you will have the eyes glazing over you know slide 10 or 3 operating. So you know it really has to be a very succinct business driven message that you use to try and deliver SOA or to try and sell SOA. But the second point is don't try and sell SOA by stealth approach where if you just sell this on these are the business benefits, the business really doesn't care about how you're going to really do that. If you do that with pencil and paper or excel or SAP they couldn't care a less. So I think often IT goes to much greater length to explain how we are going to do this wonderful thing and that's where you lose the business. Where as telling them this is what we do, but obviously either have enough time to actually do it or have your resume ready is the corollary that comes with that. That is very important. Process standardization is extremely important to use as a first step process rationalization plus standardization to whatever extent is required within the organization and the whole notion of the package world and the SOA world coming together has to be dealt with very carefully. There was a question that triggered the whole issue of, is operations the whole infrastructure operations face SOA world very different? Yes. It is a completely different world, a completely different ballgame and in some cases you may need to relearn some things and reinstitute things that have been going on for 10, 15, 20 years in the organization and make sure you don't forget that piece because that is fundamental to the stability of your SOA world with I will stop and hand it back to you.