Comment Dangerously Costly (Score 2, Insightful) 124
I think the overwhelming consensus of the posts is that anyone with experience knows that this term is meant to combine a lot of generally accepted patterns that allow for long-term return on previous development and overall system flexibility. Anyone trying to tell you otherwise is inexperienced and misinformed.
Recently at PDC this topic was raised to these folks: Gregor Hohpe, David Ing, Tony Redmond, Steve Swartz and their response was exactly what you've read in these posts.
It's true that management loves this term. Have you seen the latest tech-management publications sitting on their desks? Headlines read: "Leverage SOA Now!" and such. Now, if you're someone that is held accountible for major architectural decisions and you're the one that the department manager poses these questions to, it's a fantastic opportunity to recalibrate expectations for things that you already do or have been told in the past that you cannot do because of time/cost limitations.
On the topic of code reuse, here's, humbly, how I've seen the most benefit:
My 2-cents.
Recently at PDC this topic was raised to these folks: Gregor Hohpe, David Ing, Tony Redmond, Steve Swartz and their response was exactly what you've read in these posts.
It's true that management loves this term. Have you seen the latest tech-management publications sitting on their desks? Headlines read: "Leverage SOA Now!" and such. Now, if you're someone that is held accountible for major architectural decisions and you're the one that the department manager poses these questions to, it's a fantastic opportunity to recalibrate expectations for things that you already do or have been told in the past that you cannot do because of time/cost limitations.
On the topic of code reuse, here's, humbly, how I've seen the most benefit:
- * Identify the points in your architecture that can be supported by low-level plumbing code and factor that out to shared libraries - share them however it makes sense operationally/architecturally - does not have to be exposed as Web Services.
- * Take a close look at your business and identify the core, slowly-revisioned processes and functions. Factor those out and create shared libraries - share them however.
- * Perhaps the most important thing here is to not do any of this without giving this shared functionality an explicity owner. Someone that can answer when there's a problem and evolve the design.
My 2-cents.
