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 >
