Agreed. Relational database is much easier to learn and use then the "other" databases. It's possible compare the cost advantage of using a relational database. In a similar manner, it's possible to calculate the cost advantage of using SOA concepts and tools. I think we're having problems because of a strong focus on technology and on trying to compare using ambiguous term like "flexibility", which is very hard to quantify.
H.Ozawa --- In [email protected], "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]>: > > <<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 > > >
