The problem, in both business and IT, that they think that SOA is a product. I do work on a project that the business thinks about SOA. They delegate that to the IT. The IT has almost every thing in place, middle ware, ESB, PBM, the only missing is the monitoring tools. There is no way to convince them about defining services, governance..etc. They trust some people and those people are not accept that. The IT people wants to replace every thing with Open source, which they always complain that they do not have enough in house skills. The replacing tools will cost millions of dollars to rewrite the existing EAI applications for the newly open source tools. But the IT thinks this is the best solution. The possible solution for such a dilemma is to go with some tools that can builds services from bottom-up. Then they can recognize the Governance, then when both IT and Business, at least, recognize what is meant by services then we can introduce any needed tools such as XML appliances, monitoring tools, ..etc. The problem with approach will not support the change in business processes properly. But there is no other way.
I think the problem in education, No one can understand what is SOA and its processes. But How!!! Any suggestion for approaching such problem? All the best Ashraf Galal On Sun, Oct 26, 2008 at 12:26 PM, Steve Jones <[EMAIL PROTECTED]>wrote: > I agree with some of the data here but I'm still confused as to why > SOA always has to be net-additional spend over a 2-3 year period. > > My personal experience has been that if you focus on the right > business areas and don't focus on the technology (except as a > necessary evil) then you can consistently deliver net benefits inside > a 24 month period. > > Whenever IT says "we need $20m to fix the problems" I always wonder > why the other $200m they have is being spent on creating the problems. > > Steve > > 2008/10/26 Gervas Douglas <[EMAIL PROTECTED]<gervas.douglas%40gmail.com>>: > > > > <<As you can imagine, I spend a lot of time speaking to people about > > service-oriented architecture (and its variants for infrastructure and > > enterprise) and about how best to create a true implementation (or at > least, > > an effective one). There is a great deal of detail in creating such an > > artifact - design yes, but also implementation, operational details, > > governance, and a myriad of other tasks that can easily take up a chief > > architect's entire day. These tasks are all vital to the actual creation > of > > the architecture, but for all that they may seem the fundamental first > steps > > in evolving the IT shop, and yet there are even more necessary first > steps - > > selling the concept in the first place. > > > > SOA in many ways reminds me of relational database technology. At its > first > > inception, the concept of an RDBMS must have had a hard sell. Sure it > made > > perfect sense to arrange the data and ensure that the relationships > between > > the data were enforced, but what was the business case that enabled the > > purchase of this new and expensive technology? You certainly couldn't say > > that by introducing a relation database, you were going to make the > company > > $20 million a year annually. So the RDBMS slowly made its way into the IT > > arsenal a little at a time, with justifications added in a variety of > ways. > > > > SOA is even more complex - it affects almost every aspect of the > enterprise > > if done to the fullest, and yet the basic premise is very similar to the > > RDBMS - it's a better way to work. I imagine the discovery of the wheel > > engendered similar thought - "Duh, why didn't I think of that, it's so > > simple." And yet there's a mountain of legacy code, 50 years worth in > some > > cases, that prevents a simple rip and replace. Not to mention the cost > > problem. > > > > But the real challenge in SOA is finding the ROI in IT. The logical > > statement that spending $20 million (I'm just picking a big number here, > not > > stating that an SOA conversion should cost that) on conversion will in > the > > future make all IT projects easier to implement and thus less costly by > some > > factor is in most cases not a sufficient justification. The idea of > tacking > > it on to some in-flight project usually creates howls from the business > > owner who somehow is being asked to pay much more than the base project > > should cost. > > > > Really, there has to be another way. And there is - making the business a > > partner. SOA is something that enables changes to how the IT organization > > reacts to business requirements and new functionality requests, making > them > > easier to accomplish, and therefore both faster and cheaper. Building a > case > > with the business that these changes are important and justify slightly > hire > > costs for the first few projects is helpful. Finding a large scale > > transformation project is even better. > > > > In a large scale transformation, many IT systems are going to be touched, > > re-aligned, or replaced. New data models will come into being, and new > > services will be needed. This is not to say that it's justification for > > throwing the kitchen sink into the IT budget during a transformation, but > a > > case can easily be made based on the integration needs that are without a > > doubt going to be part of the program. Instead of some cost savings in > the > > future, by going with SOA in a transformation, the cost savings can be > > realized within the program. > > > > This isn't what the IT world wants to hear - there's a strong push from > > vendors and platform providers to go SOA - but it is the reality of > software > > systems. The concept of a system that constantly requires renewal is > foreign > > for some reason to financial folks, even though there are countless > examples > > of the concept in the world. Software has a life cycle, and if you don't > > feed your investment, it dies. Nevertheless, in order to move to an SOA > > environment, we need to recognize the need to involve the business side > of > > the organization in our activities and make a case in a language they > > understand in order to be successful.>> > > > > You can read this at: http://soa.sys-con.com/node/721654 > > > > Gervas > > > > >
