Separation of Concerns
Jeff Schneider has blogged about how he's noticed that many large organisations are expending a large proportion of their (supposedly) SOA efforts into what is actually work on good old-fashioned separation of concerns.
This is an interesting question - this 'Concern Oriented Architecture' (please Jeff, no more acronyms!) is based around decoupling different pieces of configuration/code from each other so that they can each be defined and managed more easily, but primarily so that they can be shared, reused or assembled more readily - If that is the case, aren't these shared/reusable things actually shared/reusable technical _services_?
They may be, and that is the reason I think why this 'COA' is sometimes presented as being SOA. However, shared or decoupled technical services may be good technical design, but they are not directly related or aligned to any kind of service that a business provides. Jeff and others have blogged about this misdefinition before. One blogger (who shall remain nameless) has even taken to chastising a form of this as 'SOD IT' (Service Oriented Development of IT) !
However, I'm more positive about this approach. Even if it shouldn't be the destination, it doesn't mean it's not a valuable exercise. And what's more, it may well be a valid step on the maturity curve for many organisations toward SOA proper as it may constitute a modernisation of their software infrastructure that enables them to start providing more meaningful services. But (as Jeff says), it does need to be considered separate so that it is not misrepresented. If you are working on an SOA roadmap or transformation exercise, I would recommend ensuring that this is a separate work-stream, and that the business case for doing it holds water independently from the other workstreams. Make sure you ask the hard question for each component or layer, of whether each is really needed or whether it's a technology 'nice-to-have'. It may well be needed, but we all know that just as many value propositions have been blown in the past by over-engineering the technology as have by underengineering it, and sooner or later you will get asked those hard questions, so best have done the analysis before you do.
Technorati Tags: Software Architecture Service-Oriented Service Architecture SOA Enterprise IT EII ESB BPM
This is an interesting question - this 'Concern Oriented Architecture' (please Jeff, no more acronyms!) is based around decoupling different pieces of configuration/code from each other so that they can each be defined and managed more easily, but primarily so that they can be shared, reused or assembled more readily - If that is the case, aren't these shared/reusable things actually shared/reusable technical _services_?
They may be, and that is the reason I think why this 'COA' is sometimes presented as being SOA. However, shared or decoupled technical services may be good technical design, but they are not directly related or aligned to any kind of service that a business provides. Jeff and others have blogged about this misdefinition before. One blogger (who shall remain nameless) has even taken to chastising a form of this as 'SOD IT' (Service Oriented Development of IT) !
However, I'm more positive about this approach. Even if it shouldn't be the destination, it doesn't mean it's not a valuable exercise. And what's more, it may well be a valid step on the maturity curve for many organisations toward SOA proper as it may constitute a modernisation of their software infrastructure that enables them to start providing more meaningful services. But (as Jeff says), it does need to be considered separate so that it is not misrepresented. If you are working on an SOA roadmap or transformation exercise, I would recommend ensuring that this is a separate work-stream, and that the business case for doing it holds water independently from the other workstreams. Make sure you ask the hard question for each component or layer, of whether each is really needed or whether it's a technology 'nice-to-have'. It may well be needed, but we all know that just as many value propositions have been blown in the past by over-engineering the technology as have by underengineering it, and sooner or later you will get asked those hard questions, so best have done the analysis before you do.
Technorati Tags: Software Architecture Service-Oriented Service Architecture SOA Enterprise IT EII ESB BPM
posted by Sam Lowe at
11:29 pm
0 Comments:
Post a Comment
via Haloscan
<< Home