In the world of SOA, here is my view of the Hot or Not:
Discussing REST style services [NOT]
Building REST style services [HOT]
Debating the merits of UDDI [NOT]
Building out your service taxonomy [HOT]
I.T. doing SOA without business alignment [NOT]
Business driven SOA [HOT]
Implementing proprietary mediation tools [NOT]
Implementing standards based, federated mediation tools [HOT]
Designing one-off WSDL's [NOT]
Performing Service Oriented Information Engineering [HOT]
Debating the definition of SOA [NOT]
Creating a strategy and plan to take advantage of SOA [HOT]
Forcing last-gen object oriented methods on a SOA world [NOT]
Updating the SDLC to take advantage of SOA [HOT]
Web 2.0 as a means to create community [NOT]
Web 2.0 as SOA composition strategy [HOT]
SOA product company evangelists [NOT]
War stories from SOA trench
Blogging about SOA [NOT]
Doing SOA [HOT]
Monday, July 31, 2006
Saturday, July 15, 2006
Concern Oriented Architecture
As I look at various SOA efforts in large enterprises, I've begun to realize that their technical issues have little to do with the primary SOA patterns (client-intermediary-service, publish-discover-invoke) or styles (ubiquitous Web service connectors at the edge, etc.) Instead, the time consuming (and often expensive) efforts have to do with old fashion separation of concerns. Let's call this Concern Oriented Architecture or COA for short.
I'll temporarily define COA as the emerging discipline of separating the technical concerns and identifying remedies to those concerns in the form of engines, components, domain specific languages and other repeatable solutions. COA focuses on the technical domains (presentation, data, business logic, etc.), identifying where they are divided and how they are recombined.
As an example, one enterprise I recently visited with had the following initiatives listed as part of their SOA program:
- Create a virtual data layer across all enterprise data sources
- Break out all process logic into a new layer
- Verify that integration logic doesn't exist inside of applications
- (more...)
The concepts of separating presentation logic from business logic or business logic from data logic is well known. However, more and more emphasis is now being placed on the separation of process logic and integration logic from the aforementioned elements. The science of separation of concerns is continuing to evolve. This is good stuff, but is it part of an SOA program?
The SOA efforts that I see often have more to do with COA than they have to do with SOA. Obviously, this is due to the attention and funding that SOA initiatives are receiving. I'm ok with mixing the dollars but what is clear to me is that many of these organizations aren't even aware that they're doing this. They just think it's all SOA.
And of course there's a reason why brilliant enterprise architects are taking SOA dollars and spending them on COA initiatives. They realize that the ROI of SOA is multiplied when it is combined with COA. So where do I land on all of this? I guess my bottom line is that the analysts, press and other influencers need to do a better job of separating these efforts (our own little separation of concerns). SOA and COA need to be managed as two different endeavors that have points of intersection. Failures in COA shouldn't be attributed to SOA or vice-versa, nor should successes.
I'll temporarily define COA as the emerging discipline of separating the technical concerns and identifying remedies to those concerns in the form of engines, components, domain specific languages and other repeatable solutions. COA focuses on the technical domains (presentation, data, business logic, etc.), identifying where they are divided and how they are recombined.
As an example, one enterprise I recently visited with had the following initiatives listed as part of their SOA program:
- Create a virtual data layer across all enterprise data sources
- Break out all process logic into a new layer
- Verify that integration logic doesn't exist inside of applications
- (more...)
The concepts of separating presentation logic from business logic or business logic from data logic is well known. However, more and more emphasis is now being placed on the separation of process logic and integration logic from the aforementioned elements. The science of separation of concerns is continuing to evolve. This is good stuff, but is it part of an SOA program?
The SOA efforts that I see often have more to do with COA than they have to do with SOA. Obviously, this is due to the attention and funding that SOA initiatives are receiving. I'm ok with mixing the dollars but what is clear to me is that many of these organizations aren't even aware that they're doing this. They just think it's all SOA.
And of course there's a reason why brilliant enterprise architects are taking SOA dollars and spending them on COA initiatives. They realize that the ROI of SOA is multiplied when it is combined with COA. So where do I land on all of this? I guess my bottom line is that the analysts, press and other influencers need to do a better job of separating these efforts (our own little separation of concerns). SOA and COA need to be managed as two different endeavors that have points of intersection. Failures in COA shouldn't be attributed to SOA or vice-versa, nor should successes.
Saturday, July 01, 2006
The Four Buckets of SOA Adoption
I realize that it has been a while since I've posted (as many people have reminded me), however the lack of postings is indicative of the activity in the SOA space. Bottom line is we've been busy. In the past we were busy *thinking* about SOA or *preaching* about SOA - today we're busy *delivering* SOA. And it has been busy, on the consulting side we've picked up a ton of new clients and on the training side we'll have trained over 1,000 architects & managers this year on SOA.
However, I'm noticing something really interesting about SOA adoption. You can put the adopters in 4 buckets:
1. Companies that don't do SOA and have no intention of doing it
2. Companies that don't do SOA but keep talking about it and have mastered the blame game
3. Companies that do SOA, but poorly
4. Companies that do SOA and reap huge benefits
Bucket #1
Bucker #1 companies are often busy with compliance, security, BI or other important initiatives. They had the common sense to not do SOA half-assed and have merely delayed the program.
Bucket #2
I recently attended an architects meeting of a certain industry. I witnessed 40 chief architects patting each other on the back about their lack of understanding around SOA. Only 1 in the group had done a roadmap, created a governance program and was demonstrating real results. The others made me want to puke; not because they were Bucket #1 people, but because they were bucket #2. I heard crap like, "SOA is just EAI - and we're already doing that..." - WHAT? What are you talking about?? I wanted to slap them. Honest to God. I witnessed the single biggest threat to SOA - incompetent, lazy, American, corporate architects whose skills were so dated they should go back to their 3270 terminals and program in REXX. I suddenly felt sorry for the CIO.
Bucket #3
These are the guys who have SOA programs, spend money and don't get anywhere. The problem here is almost always the same. Bucket #3 organizations have a whip-smart EA team who can rattle off every WS-* protocol (and usually do). The problem is that they live in EA land and have no ability to get application architects, developers, etc. on board. So what do they do? The EA's just keep marching blindly to the SOA drum. They act like their piece of crap SOA reference models justify their existence. They fail to actually 'realize' the models so when a line architect says, "Were thinking about doing this project using a service oriented style. You guys have been working on SOA for a couple of years; what do you have that our project can leverage?" The EA then hands them a completely non-actionable PowerPoint with a bunch of SOA diagrams that they modified from OASIS (which sucked in the first place). The recipient of this information looks at them with disgust, walks back to his project team and reports, "The jokers in EA still don't have anything we can use."
Bucket #4
Bucket #4 is the really interesting one. They succeed. The question is how? I've scratched a bald spot on my head and think I've got some answers. Here are the characteristics:
1. They have a single person ultimately responsible for SOA who leads a larger steering committee. This group also attacks organizational and process changes.
2. They created a roadmap with realistic deadlines.
3. They have an EA group where all of the members understand SOA and understand the practical needs of the application architects with regard to SOA.
4. The Application Portfolio Governance group has created a "SOA work stream" and selected new applications are sent down an SOA path.
5. The downstream teams (project managers, analysts, app. architects, designers, coders & testers) have all been trained in SOA.
Overall, I'm having a blast. As you can imagine I'm trying to focus my time on the winners. On occasion I'll take the time to let losers know that they're on a losing path, but that usually doesn't have much effect.
However, I'm noticing something really interesting about SOA adoption. You can put the adopters in 4 buckets:
1. Companies that don't do SOA and have no intention of doing it
2. Companies that don't do SOA but keep talking about it and have mastered the blame game
3. Companies that do SOA, but poorly
4. Companies that do SOA and reap huge benefits
Bucket #1
Bucker #1 companies are often busy with compliance, security, BI or other important initiatives. They had the common sense to not do SOA half-assed and have merely delayed the program.
Bucket #2
I recently attended an architects meeting of a certain industry. I witnessed 40 chief architects patting each other on the back about their lack of understanding around SOA. Only 1 in the group had done a roadmap, created a governance program and was demonstrating real results. The others made me want to puke; not because they were Bucket #1 people, but because they were bucket #2. I heard crap like, "SOA is just EAI - and we're already doing that..." - WHAT? What are you talking about?? I wanted to slap them. Honest to God. I witnessed the single biggest threat to SOA - incompetent, lazy, American, corporate architects whose skills were so dated they should go back to their 3270 terminals and program in REXX. I suddenly felt sorry for the CIO.
Bucket #3
These are the guys who have SOA programs, spend money and don't get anywhere. The problem here is almost always the same. Bucket #3 organizations have a whip-smart EA team who can rattle off every WS-* protocol (and usually do). The problem is that they live in EA land and have no ability to get application architects, developers, etc. on board. So what do they do? The EA's just keep marching blindly to the SOA drum. They act like their piece of crap SOA reference models justify their existence. They fail to actually 'realize' the models so when a line architect says, "Were thinking about doing this project using a service oriented style. You guys have been working on SOA for a couple of years; what do you have that our project can leverage?" The EA then hands them a completely non-actionable PowerPoint with a bunch of SOA diagrams that they modified from OASIS (which sucked in the first place). The recipient of this information looks at them with disgust, walks back to his project team and reports, "The jokers in EA still don't have anything we can use."
Bucket #4
Bucket #4 is the really interesting one. They succeed. The question is how? I've scratched a bald spot on my head and think I've got some answers. Here are the characteristics:
1. They have a single person ultimately responsible for SOA who leads a larger steering committee. This group also attacks organizational and process changes.
2. They created a roadmap with realistic deadlines.
3. They have an EA group where all of the members understand SOA and understand the practical needs of the application architects with regard to SOA.
4. The Application Portfolio Governance group has created a "SOA work stream" and selected new applications are sent down an SOA path.
5. The downstream teams (project managers, analysts, app. architects, designers, coders & testers) have all been trained in SOA.
Overall, I'm having a blast. As you can imagine I'm trying to focus my time on the winners. On occasion I'll take the time to let losers know that they're on a losing path, but that usually doesn't have much effect.
Subscribe to:
Posts (Atom)