This attractive force of desiring to focus on technology rather than the business is really damaging to getting SOA delivering on the promises, its really creating a black hole into which IT people continue to fall while still protesting that everything is fine.
If SOA is technology then its another TLA and another black hole down which money and broken promises are thrown. And while its kind of interesting to watch these projects and ideas fall to their deaths and be compacted down on top of the previous generations of IT to form a super dense impenetrable IT estate, this time with XML as well, its not much fun when I realise that I'm probably going to have to work at some of these companies at some stage in my career.
Technology SOA is Dark SOA, its black hole creating supermass that brings everything down with it.
The clue is in the question folks, want business agility? Focus on the BUSINESS
Technorati Tags: SOA, Service Architecture
7 comments:
But it isn't really about SOA either is it? That's certainly one way to do it though on some days I feel like it might be business process re-engineering all over again but what it seems to come down to is:
There's no point to any technology project that isn't delivering business value to the business. That is something that enhances the business' ability to function rather than simply saving money (I've lost count of the number of technologies that claim that and have failed dismally in delivering).
Translation: "listen to your customer and be careful to ensure you deliver what they asked for and if they didn't ask for anything, don't ship anything". We should have been doing that a long time ago.....
Dan Creswell
http://www.dancres.org
I know its a nice concept to say SOA is not about technology. And many powerpoint architects make alot of money on presentations about this. But the harsh reality is technology will affect business performance, hence all the discussions on your previous thread.
If SOA is not about technology lets call it an exercise in business transformation and keep it out architectural discussions.
100% agree with you Mr Creswell (and not just because you could beat me up)
To the second anon, please read what Dan is saying, the primary purpose is the business value, once you focus on that and know what you are doing and why then you should focus on technology delivery, which isn't architecture its Service Oriented Delivery, and everyone should SOD IT and be proud
I've never said we shouldn't do technology delivery, but that this shouldn't be where we focus and that it isn't the primary part of SOA. Technology certainly effects business performance, mostly in a negative way because people have focused on the technology and not on the business performance.
Funny, I always believed to know what your doing is called the "requirements phase".
I guess you saying in the SOA world that architecture?
Requirements are obviously important to architecture, but more important are the principles and drivers and the context. SOA is (to me) about the Contextual and the Conceptual level (have a look at Zachman for an example architectural framework) and possibly Logical, but certainly not physical.
Architecture is 100% not the same as requirements, and from an SOA perspective often puts the requirements into a broader business perspective and provides a strong framework within which those requirements are defined.
If you think that focusing on the business is just about the requirements, then you are 100% without a doubt not doing architecture
Absolutely, this is one of the main things that the SOA technology hype plain misses:
* If you don't have a way of managing the services you have above the level of each project (and the particular requirements of each) then you are extremely unlikely to be able to make SOA work (in any way more than a new type of technology plumbing).
And managing does not just mean storing it in a repository or putting it on a web-site for developers to look at. Managing in this context is not a technology issue either.
Managing in this context has to include proactively collaborating with each part of the business on planning, defining, evangelising about, running and improving a portfolio of services that they can care about and see value in (rather than 'technical stuff' which makes their eyes glaze over faster than you can say SOAP [or REST])
... that way when you come to manage the requirements for each service / project IMO you're far more likely to end up with shared services, consolidated services, composite services, differentiated services etc rather than a new fragmented duplicated obscure legacy of services to add to the old legacies you already have.
Sam.
http://sol1.blogspot.com/
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment