What are the Real Issues in Making or Breaking Enterprise SOAs?
The enormous amount of coverage in the press about Service Oriented Architecture (SOA) implies that that it seems to be generally considered a good thing. A useful approach. And indeed it is probably fair to say that it is moving towards becoming a best-practice way to plan, design, develop, implement and operate Enterprise IS / IT.
But as some are fond of saying, the concepts in SOA are not new concepts to IT. This is a common objection I get when talking about the topic, and sure, SOA is in some ways effectively the most recent iteration of some very familiar best-practice concepts that underpinned concepts in IT like Object Orientation, Transaction Processing, 3GLs, and more. However that's no bad thing, after all it's not reinventing those concepts, or plagiarising them. Instead it's leveraging the experiences and technologies of these previous iterations, and building upon them. The result is that it moves the debate up a level, to one where it can achieve more. Most importantly, this iteration, the one around based around Services, is in terms the business already explicitly uses, rather than some purely technology concepts that need to be translated to business terms.
Indeed, the Chief Architect from a large Financial Services company that I worked with a lot a couple of years ago on SOA adoption in his organisation was fond of saying that everyone, whether they be from the Business of his company, or his IT department, or the outsourced partners he worked with, they all intuitively ‘got’ Services, and that was powerful.
So, there is an inordinate amount of material on the Web and the seminar circuit explaining what SOAs are, explaining how the concepts work, why they are good for IT projects, for IT shops, and (albeit it normally in generic and abstract terms) why they are good for businesses. The content experts, software vendor CTOs in particular, are very well quoted and publicised on the subject. And it's useful, albeit with inevitable agendas, on raising awareness of the concept and the approach.
There is also quite a lot of information on adoption of SOA, on success rates of initiatives for it, of the project characteristics and sizes and other useful metrics. The industry analysts firms are particularly active at this. They also tend to rate the capabilities of the software vendors' products being used at how good they are at enabling the initiatives. With both these sides, it works well to help cut through the software marketing machines and bringing clarity to who's doing exactly what, and how well.
This is all good information, but there is something missing. The practitioners view and the managers view. And I don't mean practitioners of implementing the technologies. I don’t mean experiences on how easy it is to implement some standard like WSDL, work-arounds for some of the scalability issues, or anything else about experiences with implementing the technology, or making micro-level design decisions.
The real inhibitors to Enterprise-level SOA realisation are not project implementation issues, and they’re certainly not technology implementation issues. The big issues are far more complicated, they are Organisational, Architectural, and Cultural issues.
We're in the comparitively early days in dealing with these types of issues in the IT / IS industry, whether the approach be Service-Oriented or some other, and these issues have had far too little attention as people would far rather think about the conceptual stuff. But now, especially with SOA having emerged, which is critically dependent on these issues for success, this is where we really need to direct more of the industry focus going forward.
Technorati Tags: service-oriented SOA
But as some are fond of saying, the concepts in SOA are not new concepts to IT. This is a common objection I get when talking about the topic, and sure, SOA is in some ways effectively the most recent iteration of some very familiar best-practice concepts that underpinned concepts in IT like Object Orientation, Transaction Processing, 3GLs, and more. However that's no bad thing, after all it's not reinventing those concepts, or plagiarising them. Instead it's leveraging the experiences and technologies of these previous iterations, and building upon them. The result is that it moves the debate up a level, to one where it can achieve more. Most importantly, this iteration, the one around based around Services, is in terms the business already explicitly uses, rather than some purely technology concepts that need to be translated to business terms.
Indeed, the Chief Architect from a large Financial Services company that I worked with a lot a couple of years ago on SOA adoption in his organisation was fond of saying that everyone, whether they be from the Business of his company, or his IT department, or the outsourced partners he worked with, they all intuitively ‘got’ Services, and that was powerful.
So, there is an inordinate amount of material on the Web and the seminar circuit explaining what SOAs are, explaining how the concepts work, why they are good for IT projects, for IT shops, and (albeit it normally in generic and abstract terms) why they are good for businesses. The content experts, software vendor CTOs in particular, are very well quoted and publicised on the subject. And it's useful, albeit with inevitable agendas, on raising awareness of the concept and the approach.
There is also quite a lot of information on adoption of SOA, on success rates of initiatives for it, of the project characteristics and sizes and other useful metrics. The industry analysts firms are particularly active at this. They also tend to rate the capabilities of the software vendors' products being used at how good they are at enabling the initiatives. With both these sides, it works well to help cut through the software marketing machines and bringing clarity to who's doing exactly what, and how well.
This is all good information, but there is something missing. The practitioners view and the managers view. And I don't mean practitioners of implementing the technologies. I don’t mean experiences on how easy it is to implement some standard like WSDL, work-arounds for some of the scalability issues, or anything else about experiences with implementing the technology, or making micro-level design decisions.
The real inhibitors to Enterprise-level SOA realisation are not project implementation issues, and they’re certainly not technology implementation issues. The big issues are far more complicated, they are Organisational, Architectural, and Cultural issues.
We're in the comparitively early days in dealing with these types of issues in the IT / IS industry, whether the approach be Service-Oriented or some other, and these issues have had far too little attention as people would far rather think about the conceptual stuff. But now, especially with SOA having emerged, which is critically dependent on these issues for success, this is where we really need to direct more of the industry focus going forward.
Technorati Tags: service-oriented SOA
posted by Sam Lowe at
11:12 pm
|
0 comments
Permalink
del.icio.us this
