I think that Steve has changed the topic a bit. There is no point to compare "Time to market for a new web page" to the "time to market for a nuclear powerstation"; each of them have their own baselines.
If one compares a solution flexibility for "T2M" attribute, the comparison goes against the same entity but for different solution. However, I agree that fixing problem in isolation is not the right way of doing this work. - Michael ________________________________ From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, October 27, 2008 11:11:19 AM Subject: Re: [service-orientated-architecture] Re: Rhody tells you how to sell SOA Now how many companies actually have an ability to measure the Time to Market in a consistent and quantifiable way? Time to market for a new web page is one thing, time to market for a nuclear powerstation is another. How to compare "flexibility" in these two cases? This is why I advise clients to start measuring things first before getting into a transformation programme, its amazing how often it turns out that the problem wasn't where they thought it was. In the same way as people spend months optimising a query to go from 100 ms to 20ms and ignore the 5 seconds of latency its pointless optimising bits that don't have significant impacts. So I agree that in theory its simple, but in practice the data isn't normally there. Steve 2008/10/27 Michael Poulin <[EMAIL PROTECTED] com>: > "flexibility" has following metrics: > 1) how quickly a change may be adopted in the business solution > (time-to-market) -T2M > 2) how costly to adopt a change in the business solution (investments) - INV > 3) cost of integrating the change into existing business solution landscape > (impact) -IMP > > max ('flexiblity' ) = min {\xAD\xF4(T2M+INV+IMP) } > > > ROI is out of this picture because it belongs to another category than > 'flexibility' > > What the ambiguity left? > > - Michael > > ____________ _________ _________ __ > From: htshozawa <[EMAIL PROTECTED] com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Sunday, October 26, 2008 10:53:24 PM > Subject: [service-orientated -architecture] Re: Rhody tells you how to sell > SOA > > 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 service-orientated- architecture@ yahoogroups. com, "Steve Jones" > <jones.steveg@ ...> 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 <gervas.douglas@ ...>: >> > <<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 >> > >> > > >
