Re: [service-orientated-architecture] Re: [ZapFlash] Who's Killing SOA?
- How many companies consistently deliver projects on time, within budget, with capabilities that accurately implement the requested requirements? Oh yeah -- and have no application backlog? And don't forget that >80% of the IT budget goes to maintenance and operations -- leaving less than 20% for new innovation.
That's what I'm talking about when I say that IT is broken.
And I agree 100% that the problem is not caused by only by IT. And I really don't think it necessarily matters whether IT is technically driven or business driven. (although my guess is that any company that does deliver on time and in budget is likely to be business driven)
The problem is caused by the root culture of IT -- project-driven funding models, a cobbler's kids perspective on investing in infrastructure that helps IT (rather than a particular project), and a propensity to never decommission applications. IT systems have grown organically for the last 40 years. They're a mess. It requires a fundamental change in the way IT operates as a service provider within the organization.
That's why when I talk about SOA I always talk about it as an IT business initiative.
Over the last 20 years we've seen technologies come and go. Each new technology was supposed to solve these problems. First it was RPC, then RMI/EJB or DCOM/MTS, then CORBA, then MOM/EAI, then BPMS, now WS-*. But no technology will solve these problems. Not even REST (which is an architecture rather than a technology -- but it's low enough in the stack of things that from this enterprise perspective, it's a technology.)
If you really want to fix IT, you have to address the cultural issues: organization, funding models, processes, mindset, etc. Technology is a secondary concern. The folks that have co-opted the term SOA as a business-driven initiative are simply using this term to describe the need to fundamentally change IT's culture. Perhaps it's inappropriate to use "SOA" for this purpose. But if you want to deliver the benefits promised by SOA (flexibility and agility), you have to tackle these cultural issues.
This is about enterprise architecture -- not application architecture. I reiterate: SOA is an enterprise architectural style.
AnneOn 10/10/07, Steve Jones <jones.steveg@...> wrote:
On 10/10/2007, Rob Eamon <reamon@...> wrote:
> --- In firstname.lastname@example.org, "Steve Jones"
> <jones.steveg@...> wrote:
> > On 02/10/2007, Nick Gall <nick.gall@...> wrote:
> > Ummm so you are saying that IT isn't broken and is working just
> > fine?
> I wouldn't take the extreme view that all of IT everywhere is working
> just fine. But in many, many cases and ways it is working just fine.
I'd say "few" rather than many, many (which implies the vast majority).
> > IT _is_ broken, dreadfully broken, mainly because we appear to think
> > the goal is the technology rather than the operational solution.
> This is the other extreme. Some are broken--even those where the
> business drove the effort, not the technology. What is the state of
> the business and IT where you've done projects following the SOA
> principles and process described in your book? Hopefully you don't
> think those are broken!
Unfortunately they are still the minority :) But the point is that
its an evolution from a point of failure, this doesn't mean it becomes
100% successful within 12 months it means it improves over that period
of time and continues to improve as you move incrementally towards a
My book isn't a Silver Bullet either!
> > >
> > > If SOA is easier to get wrong in twenty different ways than it is
> > > to get right, then maybe the problem is with SOA -- not the
> > > people who are trying to embrace it.
> > There is of course option B which is that TECHNICALLY driven SOA, or
> > indeed ANY TECHNICALLY driven approach is easier to get wrong than
> > right, so maybe the problem is that the people in IT keep driving
> > things from a technical perspective.
> In some cases, undoubtedly.
I'd say most.
> What about the cases where the business drove things in the wrong
A good example of this is ERP customisation. Businesses like to think
they are special at all stages so like customising the package. This
is expensive suicide in lots of cases and to be avoided. The job of
IT in those cases is to play the FUD card and say that customisation =
failure and explaining how vanilla ERP and changing the business will
result in a greater degree of success.
That is where IT can help steer the business back. If the business
makes a business decision that is dumb (GEC selling off their defence
pieces and going into Telecoms at the height of the Telecoms boom for
instance) then there isn't much you can do about it.
> My issue isn't with your POV that business needs and design need to
> drive the technical solution. I agree 1000%. My issue is with your
> seemingly unrelenting notion that IT is universally to blame for all
> the woes that IT shops face. Of course that's my perception and I may
> be off-base.
Yup pretty much it. Well maybe not 100% but certainly a majority.
What I am saying is that TECHNICALLY focused IT is mainly responsible
for the mess we find ourselves in. IT organisations that are business
focused and trying to adapt to the business and who concentrate on the
business are different beasts. My point is against the "People's
Republic of IT" departments who feel they should create strategies and
dictate to the business timescales and approach, those people really
There is good IT, but when making a change and communicating a message
it is good to start with a challenge, it helps focus people on the bit
you are trying to fix.
> Would you agree that technology can be a business enabler?
100%, it should be an enabler.
> That there
> are times when the availability of technology changes the face of a
> business? It doesn't happen a lot, but it is there.
100%, the Mainframe, the PC, the internet and (IMO) a bigger one will
be proper mobility.
> One shouldn't
> start with technology and assume that it will be a business-changing
> notion (e.g. especially when said technology is ubiquitous, such as
> an ESB). One still has to start with the business notion, then
> discover/invent a technology can enable an entirely different
> business model.
Agreed. What you can also do is give the new tool to the business
(e.g. the PC) and then let them do things with it (Shadow IT) this
also creates new opportunities (and problems).
> > SOA is easy to get right, honestly, you just have to start from the
> > right place and go in the right direction, to steal something from
> > Anne and combine it with Chairman Mao.
> > A journey of a thousand miles begins with a single step..... just
> > make sure its in the right direction.
> Yes, make sure you head in the right direction for business purposes.
> Just make sure you also have the technology to build the bridge when
> you come to the chasm.
Yup. The reason I say what I say is that I understand the technology,
at a really quite detailed level. Some people who talk about business
focus do so because they don't understand the technology (or the
business sometimes). To really despise something you have to
understand it :)
- Ann wrote: "a cobbler's kids perspective on investing in infrastructure that helps IT (rather than a particular project), and a propensity to never decommission applications". Let see why business "never decommission[s] applications".
Based on my experience, business way of thinking about applications is this: 'the application (or whatever IT calls it) performs an instrumental work for my business task. Why I have to change this instrument if it provides for the task? Do not change it until it breaks, right?'
So, we have to define when application breaks. If the application was done well, it performs its tasks well for long time, until tasks get changed. This was the case of past years, now, the business tasks change much more frequently than before.
Then, application breaks not when it produces wrong results but also when right results become too costly for the owner. This attribute is usually omitted because individual application maintenance is funded in isolation from the revenue provided buy its use; once again, that was the case in the time of stable business requirements which is extrapolated on our days.
If an enterprise watches the cost of business solution ownership which includes cost of application maintenance/ownership and risks of malfunctioning and compliance, the apps get decommissioned much faster.
Stuart Charlton <stuartcharlton@...> wrote:
--- Anne Thomas Manes <atmanes@gmail. com> wrote:
> The problem is caused by the root culture of IT -- project-driven
> funding models, a cobbler's kids perspective on investing in
> that helps IT (rather than a particular project), and a propensity to
> never decommission applications. IT systems have grown organically
> last 40 years. They're a mess. It requires a fundamental change in
the way IT
> operates as a service provider within the organization.
Devil's advocate time (sorry, I actually like what you're saying above,
but there's this little voice....):
- The inability to abandon anything is an inherent feature of
bureaucracies (look at the government). They often requires urgent
ideological mandates to change. I think this is likely fundamental
to hierarchical organizations, not just IT.
- One of the reasons that project-driven funding is popular is that
shared services organizations are increasingly common for at least the
hardware & OS level, but even this is abused with chargebacks ("server
taxes") far above market rates.
- If you fashion yourself an entrepreneur within your organization, you
can't be held up by the bureaucratic nightmare at shared services, so
a) *against* the PMO,
b) *against* the Enterprise Architecture (which may force you to use
already antiquated technology)
c) *against* their processes (which require a 60 page Business
Requirements Document to initiate, a 300 page Functional Requirements
Document for rubber stamping, and another 150 page Operating Procedures
document for ongoing maintenance) .
The reason we continue to have silos is because decentralized execution
is essential to getting anything done. Every time we've tried to
centralize things, it's slowed things down dramatically -- waterfall
processes, ceremonial documents, the ability for petty tyrants to veto
things that don't serve their interests, etc.
*end devil's advocate*
Perhaps a solution to IT's woes is more along the lines of ERP for IT
like Betz's book... (which places ITIL as a major focus)
http://www.amazon. com/dp/012370593 2/
Wherein SOA is merely one of several ways to (maybe) reduce complexity.
And the processes are streamlined to focus on requirements &
configuration management without forcing people down an old fashioned,
Or, we could all take Nick Carr's view that it's all going to be SaaSd
away, so light 'em if you got 'em :-)
____________ _________ _________ _________ _________ _________ _
Pinpoint customers who are looking for what you sell.
http://searchmarket ing.yahoo. com/
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.