"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]>
To: [email protected]
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
> >
>
