Steve,
Here is a question which Anne put (but I stupidly deleted when I was
erasing some junk messages): what do you mean by a "heatmap"? It
raises images of infra-red sensory apparatus...
Gervas
--- In
[email protected]<service-orientated-architecture%40yahoogroups.com>,
"Steve Jones"
<[EMAIL PROTECTED]> wrote:
>
> On 21/01/07, Michael Poulin <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> >
> >
> > A couple questions to Steve:
> > 1) is the recommendation "Align the organisation to the BSA and
the heatmap" realistic/doable in majority of cases? Since BSA and
related "heatmap" are derived from the current state of the
organisation, do we need to ask them to align and what to?
>
> Firstly the BSA should map the business and most IT organisations are
> aligned around their capabilities. Secondly the goal of the BSA
> should be to represent what the business wants to do rather than a
> static representation of the org structure and thirdly these things
> need to continue to change.
>
> The BSA and heatmap will continually change and one of the points
> therefore is that the IT organisation and its governance also needs to
> change. The current capabilities based organisations are pretty
> static which is one of the major problems.
>
> > 2) For "Move away from project based delivery...", would it work
if we say "...move to service delivery based on iterative end-to-end
projects"? Management and PM still have to provide delivery but now
the delivery has to be a version of end-to-end project or set of
projects targeting end-to-end service.
>
> As I've said before, the difference between iterative delivery and a
> series of short waterfall projects is hard to spot. Its one of the
> easy ways to get organisations to switch. I agree about the programme
> delivery piece, that doesn't change, but the key is absolutely to
> enable the goal to change during the programme rather than the current
> big bang approach that seems to exist.
>
> >
> > Now, my 1+ penny:
> > 1. Consider SOA service reuse based on business reuse (except,
probably, technical infrastructure services that might be not
represented in the business model). Reuse is not the only one goal of
SOA.
>
> I've argued before that re-use isn't the goal of SOA,
>
(
http://service-architecture.blogspot.com/2006/06/services-arent-about-reuse.html
)
> its about use. Which is subtly different but much more common within
> business.
>
> > 2. Do not buy on business operations claiming them business
services, they are only particular business implementations of real
service(s)
> > 3. Discover, analyze and model business ownership structure in
the organisation. Map it on the BSA to find how will 'pay the cost'
of shifting onto 'thinking in services' and who will benefit from it
(the letter are your heavy artillery in the future).
> > 4. Evaluate ROI on reorganizing organisation based on BSA (w/o
altering IT)
> > 5. If ROI is substantial, perform gap analysis between BSA and
IT structure and try to build transition strategy for IT. If ROI
(with altering IT) is still substantial, start thinking about SOA.
>
> I'm writing a paper at the moment around SOA and Legacy and one of the
> goals there is to identify the ROI pieces & market change v the pieces
> to cost cut on. This gives you two potential sources of revenue to
> drive investment. The key though is that this is predominantly on the
> existing IT estate and not on new projects.
>
> >
> > - Michael
> >
> >
> >
> > Steve Jones <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 20/01/07, Michael Poulin <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Steve wrote:
> > > > Or of course there is the other option. That they are
using large
> > > > amounts of new technologies which have large associated
license fees
> > > > and are therefore having to train lots of staff which
again has bigger
> > > > costs and adds to the cost of projects as there is more
uncertainty.
> > >
> > > Agree, this is also possible. However, in two cases I
mentioned, it was not about new technologies and about " swallowed
the vendor kool-aid".
> >
> > Fair enough, I've just found the two go together, "SOA is expensive
> > because we had to buy 10 new products and now they don't work"
> >
> > >
> > > > This is why I always recommend that people switch their
> > > > governance and organisation first (which is cheap) before
really
> > > > moving on to doing enterprise wide SOA.
> > >
> > > 100% agree. We, probably, have to issue a recommendation
(including wining-and-dining) for IT on how to switch their
organisations and governance onto thinking in services. It is not a
joke or sarcasm. Can we come up with a list of first-hand
recommendations?
> >
> > The SOA Anti-patterns piece @ Infoq might be a good start.
There are
> > a couple of advisory pieces I've done in the last few years around
> > aligning organisational structures and governance to a business
> > service architecture before you embark on transformation using SOA.
> > My day-job concentration at the moment is mainly on that side with
> > technology projects being the secondary part.
> >
> > 1) Define your business Service architecture
> > 2) Define your governance structure aligned to the BSA
> > 3) Build th heatmap
> > 4) Align the organisation to the BSA and the heatmap
> > 5) Move away from project based delivery to service based programmes
> > 6) Consider new build in the same structure as existing support
and development
> >
> > Those are my top six.
> >
> > >
> > > - Michael
> > >
> > >
> > >
> > >
> > >
> > > Steve Jones <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Or of course there is the other option. That they are using large
> > > amounts of new technologies which have large associated
license fees
> > > and are therefore having to train lots of staff which again
has bigger
> > > costs and adds to the cost of projects as there is more
uncertainty.
> > >
> > > So this doesn't mean that they were doing well, just that
they've
> > > swallowed the vendor kool-aid and suprise, suprise it isn't
delivering
> > > the benefits. This is why I always recommend that people
switch their
> > > governance and organisation first (which is cheap) before really
> > > moving on to doing enterprise wide SOA. Lobbing a WS on a
project is
> > > cheap, its when people try and do things at an enterprise
level on a
> > > purely technology basis that things don't work.
> > >
> > > On 20/01/07, Michael Poulin <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > So, at least, two big companies in financial industry, IBT
and Fidelity, claim that "SOA'ziation" IS more expensive and takes
longer time to build than regular applications used in this industry.
Why? My guess, it is because they are doing well already, without
SOA. Or, their systems are already service-oriented enough for the
corporate tasks(!?).
> > > >
> > > > I understand that "it is much much harder to make sure they
are conceptualized , design and coded to stay qualified as
re-useable"; this is because SOA mentality has not been accepted
"down the line", to the development. We know, this will take time and
efforts. However, when we are talking that SOA requires "more $$'s",
I am curious, in comparison to what?
> > > >
> > > > From enterprise perspectives (not from individual project,
however), counting just development expenses is close to cheating
because the cost rocketing up in the maintenance and modification. SOA
addresses the very latter part and overall cost gets lower with SOA,
for the enterprise.
> > > >
> > > > The concept of a "system in which various GUI's consume
services that we build as part of SOA", if quite rich and lucrative. I
am working on this right now as well. However, I found that it can
be implemented iteratively, i.e. not everything behind GUI should be
a service right away. I am talking about 'transition' layer of
proxies that to be replaced when the services are ready. As a result,
investment into analysis and estimates gets spread over multiple
projects for certain period of time and appears as a strategic
roadmap. This also wins some time to make up the development minds to
think in services.
> > > >
> > > > - Michael Poulin
> > > >
> > > >
> > > >
> > > >
> > > > "Sarode, Prashant" <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > Interesting comment-'SOA is a lifestyle'
> > > >
> > > > I just came out of an big program estimation mtg in which I
was pointed that the SOA'ziation of program was an expensive
life-style and how using 2007 technology we still need all those big
hrs to build an system in which various GUI's consume services that
we build as part of SOA.
> > > >
> > > > It is easy to identify re-useable business services w/n an
enterprise but it is much much harder to make sure they are
conceptualized , design and coded to stay qualified as re-useable
after the initial reuse discovery.
> > > >
> > > > Hence, long and expensive estimates and surprise to non-tech
savy as to why it will take longer and more $$'s to do SOA'ization of
business solutions.
> > > >
> > > > Prashant Sarode
> > > >
> > > > ----- Original Message -----
> > > > From:
[email protected]<service-orientated-architecture%40yahoogroups.com>
<[email protected]<service-orientated-architecture%40yahoogroups.com>
>
> > > > To:
[email protected]<service-orientated-architecture%40yahoogroups.com>
<[email protected]<service-orientated-architecture%40yahoogroups.com>
>
> > > > Sent: Fri Jan 19 07:29:37 2007
> > > > Subject: Re: [service-orientated-architecture] Schurter
on BPM, SOA & Software
> > > >
> > > > Hmmm. BPM is something you do, not something you buy. Sounds
an awful lot like SOA to me. I have plenty of examples of companies
that have saved lots of money, improved time-to-market, and reduce
application maintenance through proper application of SOA
principles.In the process, they also consolidated their application
portfolio and gotten a much better handle on their data. But in
order to do so, you have to do a fair amount of enterprise planning,
pick the right projects, deploy a shared infrastructure, institute a
governance program, and change the way people design and build systems.
> > > >
> > > > SOA is NOT about technology, but technology can facilitate
its adoption. SOA is a set of design principles, and to be successful
with SOA, you must adopt those principles. SOA is a lifestyle.
> > > >
> > > > Anne
> > > >
> > > >
> > > > On 1/19/07, Gervas Douglas <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
> > > >
> > > > There are some comments on SOA and its business
value which may
> > > > interest you here:
> > > >
> > > >
http://tech.groups.yahoo.com/group/business-process-management/message/270
<
http://tech.groups.yahoo.com/group/business-process-management/message/270
>
> > > >
> > > > Gervas
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > Check out the all-new Yahoo! Mail beta - Fire up a more
powerful email
> > > and get things done faster.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ________________________________
> > Have a burning question? Go to Yahoo! Answers and get answers from
> > real people who know.
> > >
> > >
> > >
> > >
> >
> >
> >
> > ________________________________
> Sucker-punch spam with award-winning protection.
> > Try the free Yahoo! Mail Beta.
> >
> >
> >
> >
>
