HP announced yesterday that it is trying to extend governance beyond just the registry as a best practice for its customers – an approach that we, who pioneered automated SOA governance, have been taking for years.
The earlier you catch issues in the lifecycle, the more time and money you’ll save. It’s nice that HP is providing a simple Eclipse plug-in to inspect XML artifacts during development, but that’s just the tip of the iceberg .To fully automate SOA Governance you need a policy management solution that governs across all of the various IT infrastructure – spanning IDEs, source control systems, build systems, asset management systems, registries/repositories and beyond. And it is not just XML artifacts but all the various assets created including design documents, source code, assemblies, XML and Web Services.
I’m sure it will also be some time until HP realizes that every large enterprise has infrastructure from vendors other than HP that need to be governed as well. Most of WebLayers customers are also HP Systinet users and figured out very quickly that policy management and enforcement needs to extend beyond just the registry. This is a common affliction for infrastructure companies that have many hammers, and they are searching for the nails to drive with them. It's not about the technology that I can sell you, it's about the business objectives that I can enable and support for you.
Having said all that I am glad to see HP has finally seen the light about the importance of a more comprehensive approach to design-time governance, as it will help bring attention to an important industry trend focused on making sure that you are actually building your SOA in support of your business objectives. I've seen too many HP Systinet implementations that are populated with poorly constructed services that fail to deliver on the promise of SOA. I think it's about time that HP starts to talk about how to best avoid the problem of ‘Garbage in, Garbage out’.
Wednesday, January 30, 2008
Wednesday, December 5, 2007
Forget the Horse....just use the Cart
I was intrigued by this post from Tom Cozzolino from Liquid Hub asking the question "Will the absence of a governance strategy doom your SOA project?". SOA Governance means many things to many people, but I think that everyone can agree that a well formed and well executed SOA Governance strategy is critical to the success of any SOA initiative. In fact, a governance strategy is critical to the success of most any IT project that you may be working on. I say this with the understanding that "governance" is really a catchall phrase for implementing the necessary controls to insure that the business objectives that you establish for your IT initiatives are actually being realized by the projects as they are being delivered.
My experience tells me that most organizations today are investing in SOA projects. Some do not categorize their investment as "SOA" specifically, but let's face it we are all using XML, Web Services, and the evolving standards to build new applications, integrate existing systems, and create new products and services for our customers. We are doing this for two primary reasons:
1. We have to be able to react more quickly to changing market dynamics so that we can remain competitive, and "SOA" provides an opportunity to do that by providing standard building blocks that will allow me to continue to use the new assets and services that I am creating in new and different ways, giving me the ability to rapidly create new applications from composite services, and
2. We have to break the cycle of spending the majority of our budget (in most cases up to 80% of our IT budget) on "keeping the lights on". We have to shift the balance so that more of our money is spent on innovation and new development.
In both cases SOA provides the means to the end that we are trying to achieve. The questions really begin after we have made the decision that we need to do this. How do we get started? That is the question that I get most often. The answers that are generally provided are similar to what Tom is recommending. Go buy a registry/repository and make sure that everyone is putting their assets into the reg/rep so that they can be discovered and used by other projects. In theory it sounds great, in practice it is "Forget about the Horse....just use the Cart".
The analogy is simple. If you standup a registry/repository and have everyone put their work into it you are simply allowing poor design practices, poor development practices, and likely poor services to be made available for consumption. You are doing more than "Putting the cart before the horse", you are eliminating the horse altogether.
The single largest killer of SOA initiatives within enterprises today is the first time a poorly conceived and developed service is used by a project team and it fails. Confidence falls, momentum stalls, and the doubters get a clear indication that this "SOA thing" will not work. A simple and long standing fact of "garbage in, garbage out". Something we all learned decades ago. This is what you will get if your first step in any SOA initiative is to provide a registry/repository to your project teams without the necessary governance policies in place to certify your services.
I contend that you should take a different view of governance for your SOA initiatives. I contend that you should apply the same principles that you are already using, with one exception. SOA is an architecture – you can’t buy this. To achieve SOA, you first need to define the standards, guidelines and best practices you need the organization to adhere to as services are built. These should be codified as policies and form the basis for your governance initiative, from DAY ONE.
You probably have already established some type of governance process (ok, call it an SDLC applied to SOA), and that process includes a formal set of "gates" that you take your projects through where you can review the work that is being done. When you review the work, you are applying a set of policies to determine if the artifacts you are reviewing (design documents, component code, WSDL's, XML Schema, etc.) comply with the policies that you have established to ensure that the business objectives that you are trying to achieve are being met. The exception is that you should remove the mundane task and tedious work of applying these policies to the artifacts, and automate the enforcement of those policies.
You should do this as early in the project life-cycle as possible (I say Day One), and you should provide continuous and consistent enforcement across the entire life-cycle. This cannot be accomplished if you wait until the artifacts are published to the reg/rep. What about the design documents that are typically stored in a document repository or file system? What about the component code (Java, C#, Cobol, etc.) that is typically worked on in some IDE and stored in a source code repository? Yes, what about the WSDL's and XML Schema that makeup the interfaces for your services?
In order to have a comprehensive Governance approach, you need to establish and enforce policies from inception through operations for your IT projects including your SOA projects. You do this today, generally with a manual approach. Why not automate that with a comprehensive Policy Management solution and free your resources to focus on exceptions and higher order problems?
My experience tells me that most organizations today are investing in SOA projects. Some do not categorize their investment as "SOA" specifically, but let's face it we are all using XML, Web Services, and the evolving standards to build new applications, integrate existing systems, and create new products and services for our customers. We are doing this for two primary reasons:
1. We have to be able to react more quickly to changing market dynamics so that we can remain competitive, and "SOA" provides an opportunity to do that by providing standard building blocks that will allow me to continue to use the new assets and services that I am creating in new and different ways, giving me the ability to rapidly create new applications from composite services, and
2. We have to break the cycle of spending the majority of our budget (in most cases up to 80% of our IT budget) on "keeping the lights on". We have to shift the balance so that more of our money is spent on innovation and new development.
In both cases SOA provides the means to the end that we are trying to achieve. The questions really begin after we have made the decision that we need to do this. How do we get started? That is the question that I get most often. The answers that are generally provided are similar to what Tom is recommending. Go buy a registry/repository and make sure that everyone is putting their assets into the reg/rep so that they can be discovered and used by other projects. In theory it sounds great, in practice it is "Forget about the Horse....just use the Cart".
The analogy is simple. If you standup a registry/repository and have everyone put their work into it you are simply allowing poor design practices, poor development practices, and likely poor services to be made available for consumption. You are doing more than "Putting the cart before the horse", you are eliminating the horse altogether.
The single largest killer of SOA initiatives within enterprises today is the first time a poorly conceived and developed service is used by a project team and it fails. Confidence falls, momentum stalls, and the doubters get a clear indication that this "SOA thing" will not work. A simple and long standing fact of "garbage in, garbage out". Something we all learned decades ago. This is what you will get if your first step in any SOA initiative is to provide a registry/repository to your project teams without the necessary governance policies in place to certify your services.
I contend that you should take a different view of governance for your SOA initiatives. I contend that you should apply the same principles that you are already using, with one exception. SOA is an architecture – you can’t buy this. To achieve SOA, you first need to define the standards, guidelines and best practices you need the organization to adhere to as services are built. These should be codified as policies and form the basis for your governance initiative, from DAY ONE.
You probably have already established some type of governance process (ok, call it an SDLC applied to SOA), and that process includes a formal set of "gates" that you take your projects through where you can review the work that is being done. When you review the work, you are applying a set of policies to determine if the artifacts you are reviewing (design documents, component code, WSDL's, XML Schema, etc.) comply with the policies that you have established to ensure that the business objectives that you are trying to achieve are being met. The exception is that you should remove the mundane task and tedious work of applying these policies to the artifacts, and automate the enforcement of those policies.
You should do this as early in the project life-cycle as possible (I say Day One), and you should provide continuous and consistent enforcement across the entire life-cycle. This cannot be accomplished if you wait until the artifacts are published to the reg/rep. What about the design documents that are typically stored in a document repository or file system? What about the component code (Java, C#, Cobol, etc.) that is typically worked on in some IDE and stored in a source code repository? Yes, what about the WSDL's and XML Schema that makeup the interfaces for your services?
In order to have a comprehensive Governance approach, you need to establish and enforce policies from inception through operations for your IT projects including your SOA projects. You do this today, generally with a manual approach. Why not automate that with a comprehensive Policy Management solution and free your resources to focus on exceptions and higher order problems?
Friday, November 9, 2007
Real ROI from SOA case study
I'm not sure if everyone noticed this week's Info World's article Five ways to roll out SOA (Nov 5th, 2007).
In this article, Galen Gruman describes 5 case studies of Big-name companies that "are jumping into SOA, changing the way organizations plan, develop, and deploy enterprise applications".
One of the most interesting quotes he provided was directly related to SOA's always elusive ROI.
"For Thomson Financial, the results of service compliance automation are dramatic, Mitevski says: “It used to take 20 people in a highly orchestrated process across various groups to go live [with a service]. Now it takes just a single person.”"
This number translates to huge savings in human resources, TTM (time to market) and TCO (total cost of ownership).
If you will add to that what Gartner says: "It is 30 times more expensive to fix issues that are caught in production", you can begin to understand why the ROI from design time governance is so much higher then attempting to use registries/repositories or WS Management runtime solutions.
Yes, you must have them as part of your Governance infrastructure, but if you want to get things right you should start with a Policy Management solution that spans across the entire life cycle. Just the same way Thomson Financial did.
In this article, Galen Gruman describes 5 case studies of Big-name companies that "are jumping into SOA, changing the way organizations plan, develop, and deploy enterprise applications".
One of the most interesting quotes he provided was directly related to SOA's always elusive ROI.
"For Thomson Financial, the results of service compliance automation are dramatic, Mitevski says: “It used to take 20 people in a highly orchestrated process across various groups to go live [with a service]. Now it takes just a single person.”"
This number translates to huge savings in human resources, TTM (time to market) and TCO (total cost of ownership).
If you will add to that what Gartner says: "It is 30 times more expensive to fix issues that are caught in production", you can begin to understand why the ROI from design time governance is so much higher then attempting to use registries/repositories or WS Management runtime solutions.
Yes, you must have them as part of your Governance infrastructure, but if you want to get things right you should start with a Policy Management solution that spans across the entire life cycle. Just the same way Thomson Financial did.
Re: Observations from the InfoWorld SOA Executive Forum 2007
Re: Observations from the InfoWorld SOA Executive Forum 2007
Too bad Dave Linthicum left the conference before the presentation from Jon Eisenstein, the Global CTO of GE Money.
In that presentation he would have heard about "a true agile architecture" with focus on "ROI".
John described 2 past attempts at an enterprise wide SOA initiative and he explained why they failed as well as what to do so things will not "go horrible wrong".
I will make sure to add here a link to Jon's presentation once it is available online.
Too bad Dave Linthicum left the conference before the presentation from Jon Eisenstein, the Global CTO of GE Money.
In that presentation he would have heard about "a true agile architecture" with focus on "ROI".
John described 2 past attempts at an enterprise wide SOA initiative and he explained why they failed as well as what to do so things will not "go horrible wrong".
I will make sure to add here a link to Jon's presentation once it is available online.
Monday, October 29, 2007
Re: It’s JADR (Just Another Damm Registry)
Re: It’s JADR (Just Another Damm Registry)
In a best of breed world, Registry/Repository vendors will always try to differentiate their solution and provide extra "proprietary" capabilities. The Registry/Repository market is being commoditized as we speak. Every major platform vendor as well as some small vendors provides their own flavor of a solution. Expecting a standard to bridge the gap among the different Registry/Repository solutions is doomed to failure. Registry/Repository solutions should be chosen based on their fit to the specific environment and use case.
Bridging the gap today rather than hoping and praying for a standard in the future will leave you with no real solution.
"So, what can be done?"
One of the solutions that are available right now is vendor agnostic Policy Governance solution. This way you can benefit from the best of breed Registry/Repository while making sure it ensures consistent content across the different solutions you have or may have in the future. Just be careful not to fall into the "bundled"policy management solution pitfall, make sure they can run with other platforms you may have.
As explained in a recent Burton Group paper: "A pure-play policy management solution, such as WebLayers Center, offers the most comprehensive and flexible policy management capabilities of all policy management options."
Bottom line, for most enterprises, waiting is not an option.
In a best of breed world, Registry/Repository vendors will always try to differentiate their solution and provide extra "proprietary" capabilities. The Registry/Repository market is being commoditized as we speak. Every major platform vendor as well as some small vendors provides their own flavor of a solution. Expecting a standard to bridge the gap among the different Registry/Repository solutions is doomed to failure. Registry/Repository solutions should be chosen based on their fit to the specific environment and use case.
Bridging the gap today rather than hoping and praying for a standard in the future will leave you with no real solution.
"So, what can be done?"
One of the solutions that are available right now is vendor agnostic Policy Governance solution. This way you can benefit from the best of breed Registry/Repository while making sure it ensures consistent content across the different solutions you have or may have in the future. Just be careful not to fall into the "bundled"policy management solution pitfall, make sure they can run with other platforms you may have.
As explained in a recent Burton Group paper: "A pure-play policy management solution, such as WebLayers Center, offers the most comprehensive and flexible policy management capabilities of all policy management options."
Bottom line, for most enterprises, waiting is not an option.
Monday, October 1, 2007
Opportunity Knocks
Last week I attended the IBM Venture Partnering Symposium at their Almaden Research Center in California. At first I was shocked that IBM announced this meeting the last week of the sales quarter. Would any senior IBM executives (and Partners) dare to leave the office during this week? The conference room held about 300 and over 350 people attended! The question for all of us is, “why”?
The simple answer is “opportunity”. I have been in the technology industry since (gulp) 1979. The energy around this event reminded me of other opportunities such as the introduction of HPs first LaserJet in 1984 and Scott McNealy’s brash statement in 1991 that he would create a Partner Channel that would exceed $1 Billion within 2 years. We still see the success of HPs LaserJet and Sun Microsystem Partner Channel exceeded $1 billion in the first year!
Yes, opportunity is knocking right now with IBM. Specifically, IBM has positioned its corporate strategy to win with Partners. Why else would all of IBM’s top executives attend a Partnering Symposium the last week of the quarter…because they are committed to their Partner strategy.
Top billing at the Symposium was SOA, SaaS, and delivering value around the convergence of Software and Services. As a SOA software vendor I walked away very excited. First, IBM was heightening the value and awareness of SOA as well as outlining a way for Partners to align with IBM. Robert LeBlanc said it best, “we (IBM) will look to our Partners to provide assets (solutions) to deliver business value and innovation to our customers”. Consider the magnitude of this statement; IBM is embracing its Partners around their multibillion dollar global services group. Sign me up.
So, how do WebLayers and its Partners make the most of this opportunity? First, we need to deliver a solid solution around SOA (WebLayers Center) wrapped with a service package that installs, implements and supports policy management needs of our customers. Second, we align ourselves with IBMs field sales force as well as their service groups. Together we then deliver the business value and innovation that customers are demanding.
Anyone interested? I am recruiting Partners that have an established SOA practice. You can email me at Partners@weblayers.com. I look forward to hearing from you.
The simple answer is “opportunity”. I have been in the technology industry since (gulp) 1979. The energy around this event reminded me of other opportunities such as the introduction of HPs first LaserJet in 1984 and Scott McNealy’s brash statement in 1991 that he would create a Partner Channel that would exceed $1 Billion within 2 years. We still see the success of HPs LaserJet and Sun Microsystem Partner Channel exceeded $1 billion in the first year!
Yes, opportunity is knocking right now with IBM. Specifically, IBM has positioned its corporate strategy to win with Partners. Why else would all of IBM’s top executives attend a Partnering Symposium the last week of the quarter…because they are committed to their Partner strategy.
Top billing at the Symposium was SOA, SaaS, and delivering value around the convergence of Software and Services. As a SOA software vendor I walked away very excited. First, IBM was heightening the value and awareness of SOA as well as outlining a way for Partners to align with IBM. Robert LeBlanc said it best, “we (IBM) will look to our Partners to provide assets (solutions) to deliver business value and innovation to our customers”. Consider the magnitude of this statement; IBM is embracing its Partners around their multibillion dollar global services group. Sign me up.
So, how do WebLayers and its Partners make the most of this opportunity? First, we need to deliver a solid solution around SOA (WebLayers Center) wrapped with a service package that installs, implements and supports policy management needs of our customers. Second, we align ourselves with IBMs field sales force as well as their service groups. Together we then deliver the business value and innovation that customers are demanding.
Anyone interested? I am recruiting Partners that have an established SOA practice. You can email me at Partners@weblayers.com. I look forward to hearing from you.
Monday, September 17, 2007
Policy Looms Large at BEA World 2007
Greetings from BEA World 2007. It’s been a great week in San Francisco and we’ve had some great conversations on SOA governance with customers, prospects and BEA personnel.
One of the most interesting presentations from BEA was entitled “The Importance of Policy in SOA.” BEA recognizes an appropriately broad definition of policy – from design to development to runtime. They see the agility from SOA coming from a policy-based approach versus the rigidity of embedding policy within application logic.
Today BEA has a number of products that each provides a stove-pipe approach to managing policies. They discussed their roadmap to address policy requirements. The first part of the roadmap was the delivery of the new AquaLogic Registry Repository (see below).
The next delivery will be a policy management platform to centrally author, manage and push policies to various decision points and enforcement points (agents) along the lifecycle.
BEA clearly understands the value of having policy management decoupled from the enforcement points. I applaud their vision.
…..
The new AquaLogic Registry Repository V3 was announced on Tuesday. BEA has packaged the enterprise repository (formerly Flashline) together with the service registry (OEM from Systinet). There are two interesting elements in this offering:
1) The integration of workflow capabilities – this helps automate the process of moving assets through the service lifecycle. This is a good first step but doesn’t address if the services/artifacts conform to standards or architectural policies in an automated fashion. This is critical information to have in making the decision to promote services through the lifecycle.
2) Metadata Interoperability Framework (MDIF) - is a Java-based API for reading metadata from BEA and third party products, expressing the metadata in SCA form, and interacting with ALRR (submit, link, search and download). This makes it easier for third parties to integrate once and eventually share throughout the BEA products. It is also useful in a broader context to express support for SCA.
…..
On a side note... VMworld was held adjacent to the BEA show and was packed. The official count was 11,000 participants and it sure had a positive vibe. It’s been a while since I’ve been to a show and seen so many free t-shirts, magicians, and the good old “money machine” (where people try to catch dollar bills being blown about in a glass booth).
One of the most interesting presentations from BEA was entitled “The Importance of Policy in SOA.” BEA recognizes an appropriately broad definition of policy – from design to development to runtime. They see the agility from SOA coming from a policy-based approach versus the rigidity of embedding policy within application logic.
Today BEA has a number of products that each provides a stove-pipe approach to managing policies. They discussed their roadmap to address policy requirements. The first part of the roadmap was the delivery of the new AquaLogic Registry Repository (see below).
The next delivery will be a policy management platform to centrally author, manage and push policies to various decision points and enforcement points (agents) along the lifecycle.
BEA clearly understands the value of having policy management decoupled from the enforcement points. I applaud their vision.
…..
The new AquaLogic Registry Repository V3 was announced on Tuesday. BEA has packaged the enterprise repository (formerly Flashline) together with the service registry (OEM from Systinet). There are two interesting elements in this offering:
1) The integration of workflow capabilities – this helps automate the process of moving assets through the service lifecycle. This is a good first step but doesn’t address if the services/artifacts conform to standards or architectural policies in an automated fashion. This is critical information to have in making the decision to promote services through the lifecycle.
2) Metadata Interoperability Framework (MDIF) - is a Java-based API for reading metadata from BEA and third party products, expressing the metadata in SCA form, and interacting with ALRR (submit, link, search and download). This makes it easier for third parties to integrate once and eventually share throughout the BEA products. It is also useful in a broader context to express support for SCA.
…..
On a side note... VMworld was held adjacent to the BEA show and was packed. The official count was 11,000 participants and it sure had a positive vibe. It’s been a while since I’ve been to a show and seen so many free t-shirts, magicians, and the good old “money machine” (where people try to catch dollar bills being blown about in a glass booth).
Subscribe to:
Posts (Atom)
