The bottom line here is that BPM can sell SOA. Thus by supporting and promoting BPM, you will also be exposing the need for SOA.
Monday, June 9, 2008
Gartner AADI - Service Oriented Development presented by Michael Blechar
Michael described an interest point concerning BPM. When a business unit starts documenting and defining their business process, not only do they start to get value through visibility and repeatability but they quickly start to see the value of SOA. This is due to the fact that once the processes are documented, people will want to fine tune and alter them to accommodate changing requirements or to make them more efficient. They will quickly see that without separating the individual units of work or activities they are not able to achieve this flexibility. Additionally, other units will see the processes and what to utilize them in whole or partially. Again, without the separation and granularity this is not possible.
The bottom line here is that BPM can sell SOA. Thus by supporting and promoting BPM, you will also be exposing the need for SOA.
The bottom line here is that BPM can sell SOA. Thus by supporting and promoting BPM, you will also be exposing the need for SOA.
Gartner AADI – Moving towards Advanced SOA presented by Yefim Natis
An interesting concept is the idea of Software Oriented SOA and Business Oriented SOA. The difference being that one is technology focused and one is not. While it’s never accurate to break things down to only 2 sides, there is some value is evaluating your SOA initiative against this dichotomy.
This difference was noted as a “Thing to Avoid” in Yefim’s morning session here at the AADI conference. A Software Oriented SOA is one which is driven largely by the developers and “techies” as Yefim called them. There is little if any business alignment and services are viewed as software deliverables. A Business Oriented SOA on the other hand blends the technology with the business and views services as business enablers.
The results of these two approaches can and will be drastically different. Without a business focus, most SOA branded activities will ultimately lead to further disconnect and added complexity.
Obviously Yefim’s presentation covered much more than this but this one point resonated with me as I have personally seen instances of both types of SOA initiatives and I think you can guess which ones have been more successful.
This difference was noted as a “Thing to Avoid” in Yefim’s morning session here at the AADI conference. A Software Oriented SOA is one which is driven largely by the developers and “techies” as Yefim called them. There is little if any business alignment and services are viewed as software deliverables. A Business Oriented SOA on the other hand blends the technology with the business and views services as business enablers.
The results of these two approaches can and will be drastically different. Without a business focus, most SOA branded activities will ultimately lead to further disconnect and added complexity.
Obviously Yefim’s presentation covered much more than this but this one point resonated with me as I have personally seen instances of both types of SOA initiatives and I think you can guess which ones have been more successful.
Monday, February 11, 2008
SOA Challenges: Silo Service Development
One of the more common things I am seeing these days is the development of services in an application or siloed context. The popularity of and propaganda about web services has made this type of development very popular.
Rather than creating a .NET or Java API as they would have in the past, teams now simply create a Web Service API. Unfortunately, since these services are not being created with a broader picture in mind, there is no focus put on schema development or reuse, namespace management, consistency or versioning, WS-I compliance, top-down design or interoperability.
Essentially what these teams are doing is adding more complexity to their system then they would have had if they created a typical interface. Furthermore they are adding latency and reducing the performance of their system while not getting any of the other added benefits of a more managed service oriented approach.
Additionally, because these projects contain all the traditional tiers (Data, Business Logic and Presentation) they are also responsible for consuming the very web service they are creating. Simultaneous development of a service and its consumer is very difficult without a structured and planned approach. There is no single correct way but typically it involves a defined, solidified interface and a dummy implementation. This allows the consumer development to proceed unimpeded by the service development. The service team can then “release” operations individually and do integration testing on a smaller scale allowing the system to gradually take shape rather than going for the "big bang" integration approach.
Many companies are on this path. Those that have no centralized or organized SOA effort are inadequately prepared to change this behavior. Those that do (yes, even companies who have great SOA stories fall victim to this) need to ensure that NO web service gets created without the SOA team's knowledge and influence. If nothing else, the SOA team needs to be aware of the project and either help the project team align their services with the broader vision or prepare (and plan) for a refactoring effort later on.
Rather than creating a .NET or Java API as they would have in the past, teams now simply create a Web Service API. Unfortunately, since these services are not being created with a broader picture in mind, there is no focus put on schema development or reuse, namespace management, consistency or versioning, WS-I compliance, top-down design or interoperability.
Essentially what these teams are doing is adding more complexity to their system then they would have had if they created a typical interface. Furthermore they are adding latency and reducing the performance of their system while not getting any of the other added benefits of a more managed service oriented approach.
Additionally, because these projects contain all the traditional tiers (Data, Business Logic and Presentation) they are also responsible for consuming the very web service they are creating. Simultaneous development of a service and its consumer is very difficult without a structured and planned approach. There is no single correct way but typically it involves a defined, solidified interface and a dummy implementation. This allows the consumer development to proceed unimpeded by the service development. The service team can then “release” operations individually and do integration testing on a smaller scale allowing the system to gradually take shape rather than going for the "big bang" integration approach.
Many companies are on this path. Those that have no centralized or organized SOA effort are inadequately prepared to change this behavior. Those that do (yes, even companies who have great SOA stories fall victim to this) need to ensure that NO web service gets created without the SOA team's knowledge and influence. If nothing else, the SOA team needs to be aware of the project and either help the project team align their services with the broader vision or prepare (and plan) for a refactoring effort later on.
Monday, January 21, 2008
SOA Challenges: Schema Management
Everywhere I go I see this challenge. How can you create a network of interactive, useful, business oriented services if they do not speak the same language?
I'm not talking about the format in which data is transferred (e.g SOAP or POX or JSON). I talking about the business specific semantics used to represent the data. Just because two people speak English does not mean they can communicate. They must have a vocabulary they both understand. Have you ever listened to a NASCAR post race interview? I'm pretty sure that's English but I have no idea what they are talking about.
The same is true when developing services.
Web Services are officially the flavor of the month. Every project now at the very least involves a web service API and many utilize web services as their only business tier API. While this is a topic in of itself, as it relates to the topic at hand, this is root of the problem.
A recent post by Jeff Schneider points out this issue and leaves little hope for the traction it is getting. The desire and push to develop services has lead almost everyone to do their leaping before their looking. It is these same people who will eventually proclaim SOA just another passing fancy even though they did little to make it a success.
Of course in order to do this properly, an enterprise needs to provide its teams with the appropriate tools and resources in which it can be accomplished.
To name a few:
I'm not talking about the format in which data is transferred (e.g SOAP or POX or JSON). I talking about the business specific semantics used to represent the data. Just because two people speak English does not mean they can communicate. They must have a vocabulary they both understand. Have you ever listened to a NASCAR post race interview? I'm pretty sure that's English but I have no idea what they are talking about.
The same is true when developing services.
Web Services are officially the flavor of the month. Every project now at the very least involves a web service API and many utilize web services as their only business tier API. While this is a topic in of itself, as it relates to the topic at hand, this is root of the problem.
A recent post by Jeff Schneider points out this issue and leaves little hope for the traction it is getting. The desire and push to develop services has lead almost everyone to do their leaping before their looking. It is these same people who will eventually proclaim SOA just another passing fancy even though they did little to make it a success.
Of course in order to do this properly, an enterprise needs to provide its teams with the appropriate tools and resources in which it can be accomplished.
To name a few:
- A centralized object repository
- Tools for navigating and extending existing objects (both internally and externally managed schemas)
- A versioning solution
- An environment for hosting and referencing all internal schemas (e.g. http://schemas.mycompany.com)
- Governance around the use and proliferation of namespaces and objects (I'm talking to you EAs)
I am currently evaluating a solution I hope will offer all of these things so I will let you know what I find. Stay tuned...
Tuesday, August 7, 2007
The Sweet Comfort of the Maturity Model
Not long ago I was talking with a colleague about various SOA implementations we had seen. On one in particular I commented that it was not a SOA but rather what I like to humorously call JBODMWS. That of course stands for "Just a Bunch of Discoverable, Managed Web Services". This is definitely better than what a lot of companies have, but I stressed that simply registering a bunch of web services from different departments and different lines of business does not a SOA make. Even managing the services centrally, while a significant step in the right direction does not qualify as SOA. In fact, what it qualifies for is exactly what I called it, JBODMWS.
My colleague maintained that it was indeed a SOA. This of course set me off on my lecture circuit on how SOA was not about creating a bunch of web services and registering and managing them. Its about composition and granularity and categorization and flexibility and, you know, all that other stuff. Once my colleague understood my argument he made the comment that to this day perplexes me. He said, "OK, I see. But it is still a SOA, its just a SOA maturity level 0."
What do you say that? I can't argue with it. Its not UNtrue. But it certainly isn't necessarily accurate. Needless to say our conversation ended then and there and I have been thinking about it ever since.
What is this monster we've created called the Maturity Model? Sure its useful and when used in the correct context it can be a very important measuring stick. But is that how it is being used? Are people comparing themselves against the model, determining where they stand and then making plans and preparations on how to get to the next level?
I'm afraid to say I don't think so. I think people are evaluating where they stand, finding they are at level 0 or level 1 and then forgetting about it. Did they do anything to get to level 1? Probably not. Maybe next time they evaluate themselves (or have some else do it) they will find they are at level 2. Great! But how did you get there. Did you mean to? What level will you be at the next time you evaluate yourself? Will you even do it again?
I think in reality the maturity model is being used as a blankey. You know the thing Linus had in the Peanuts. It seems to make people feel good about where they are. Consider the following:
Which makes you feel better?
- Your fat
OR
- Your skinny maturity level 0
To be fair, the blame needs to be spread just a bit. It is not just IT departments that are snuggling in the warmth of the maturity model. It is the consultants as well. Do you have the balls to tell someone they are not where they think they are? Or will you just tell them they are maturity level 1 and make them feel better.
Don't get me wrong, I am not saying to hell with maturity models. I'm just saying, don't let it be a passive artifact you warm up to in order to explain your current state. Let it be an active artifact that you are consistently measuring yourself against. Your plans should involve a strategy for achieving the next level. Only then will you be using the maturity model for what it was meant for.
Until next time,
This is Jason Henley, International Heartthrob... Maturity Level 0.
Friday, August 3, 2007
SOA, I could just K.I.S.S you! - Part 6
Welcome back. If you missed the first five parts of this series, please follow the links below to start at the beginning.
Step 1 - Stake in the Ground
Step 2 - Education
Step 3 - Organizational Governance
Step 4 – Evaluate Your Infrastructure
Step 5 - Pilot Project
Step 6 - Wrap up
Wrap up.... Wrap up!! How can I just wrap it up now when there is so much left to do?
Well its simple (the theme remember). Much of what is left to do simply involves sticking to it. Learning at each step. Actually allocating some time to analyze services for compliance and reuse opportunity etc.
Now I realize that I've left out some huge pieces. Namely Business Process Modeling, Master Data Management, Service Design, Service Management, Orchestration, Security, Service Life Cycle Management, Service Versioning... I think I could go on for a while but I'll stop there.
These are all very important topics and things that you need to look at and address. The point I want to make is that you do not have to paralyze yourself by taking all of this on at one time.
I hate to say it because it feels like a give up but Rome was not built in a day, and assuming your SOA actually gets built, it will be no different.
At the very core of SOA, in my humble opinion, are very simple concepts not complicated ones, and while the solutions themselves are not always simple, keeping those simple concepts and goals in mind will help you see the solutions that are right for YOU!
Step 1 - Stake in the Ground
Step 2 - Education
Step 3 - Organizational Governance
Step 4 – Evaluate Your Infrastructure
Step 5 - Pilot Project
Step 6 - Wrap up
Wrap up.... Wrap up!! How can I just wrap it up now when there is so much left to do?
Well its simple (the theme remember). Much of what is left to do simply involves sticking to it. Learning at each step. Actually allocating some time to analyze services for compliance and reuse opportunity etc.
Now I realize that I've left out some huge pieces. Namely Business Process Modeling, Master Data Management, Service Design, Service Management, Orchestration, Security, Service Life Cycle Management, Service Versioning... I think I could go on for a while but I'll stop there.
These are all very important topics and things that you need to look at and address. The point I want to make is that you do not have to paralyze yourself by taking all of this on at one time.
I hate to say it because it feels like a give up but Rome was not built in a day, and assuming your SOA actually gets built, it will be no different.
At the very core of SOA, in my humble opinion, are very simple concepts not complicated ones, and while the solutions themselves are not always simple, keeping those simple concepts and goals in mind will help you see the solutions that are right for YOU!
SOA, I could just K.I.S.S you! - Part 5
Welcome back. If you missed the first four parts of this series, please follow the links below to start at the beginning.
Step 1 - Stake in the Ground
Step 2 - Education
Step 3 - Organizational Governance
Step 4 – Evaluate Your Infrastructure
Step 5 - Pilot Project
What more can one say about pilot projects. If you do a search right now for SOA Pilot Projects, you will find somewhere in the vicinity of 300 results, one of which is an article co-authored by MomentumSI's own Alex Rosen.
So to save time (mine) I will simply concede that there is not much more information I can add on this topic. I will therefore leave it at this:
1) DO A PILOT PROJECT!!!
2) Learn from said pilot project
3) Roll those lessons into your overall plan (if you need more infrastructure, now you at least have some data)
4) Finally, tackle another project only this time, do it better.
I'll close this wonderfully short entry by passing along some great advice I once read:
Lather, Rinse, Repeat... Ah the simplicity....
____________________
Next Step - Wrap up
Step 1 - Stake in the Ground
Step 2 - Education
Step 3 - Organizational Governance
Step 4 – Evaluate Your Infrastructure
Step 5 - Pilot Project
What more can one say about pilot projects. If you do a search right now for SOA Pilot Projects, you will find somewhere in the vicinity of 300 results, one of which is an article co-authored by MomentumSI's own Alex Rosen.
So to save time (mine) I will simply concede that there is not much more information I can add on this topic. I will therefore leave it at this:
1) DO A PILOT PROJECT!!!
2) Learn from said pilot project
3) Roll those lessons into your overall plan (if you need more infrastructure, now you at least have some data)
4) Finally, tackle another project only this time, do it better.
I'll close this wonderfully short entry by passing along some great advice I once read:
Lather, Rinse, Repeat... Ah the simplicity....
____________________
Next Step - Wrap up
Subscribe to:
Posts (Atom)
