Friday, July 28, 2006
SOA Governance
The HP deal that got Mercury which included Systinet is getting a lot attention. It seems that SOA was a primary driving force behind the acquisition. When you actually need a registry and run time governance for SOA is still up for debate. What do you think? Registry now or registry later.
Saturday, July 22, 2006
Vendor Driven IT Strategy
One primary advantage behind using Service Oriented Architecture and Event Driven Architecture is the flexibility these concepts/practices provide an IT organization to drive its own strategy and activities. One might think that this ability exist regardless of the software vendors and architectural styles in use by an organization. The reality is when you hook up with a software vendor you inherit their vision or lack there of the future. This vision will ultimately translate into time and effort for an IT organization.
The typical IT organization goes into a planning/budget cycle for each fiscal year. Generally speaking it has to address these areas: Things it has to do (Maintenance of existing applications, security, support of existing stuff etc), Things the business clients want to do (new projects and enhancements), Innovation efforts (Looking at new stuff, R&D), Pain Points (Things that causing the organization problems). Ideally you would like your organization to spend most of its time and money addressing what the business clients want/need and innovation. I think in reality a lot of organizations spend most of their time with maintenance and pain points. Why does this happen?
Most IT organizations are heavily invested into software from multiple vendors. IBM, Microsoft and Oracle are some of the big ones but there are a lot of smaller ones that have deep penetration into IT organizations. These companies have a goal and that goal is to sell more software and services to the IT organization (Yes I know they want to "Partner" with you). Makes sense right? The problem is that this goal is usually in direct contradiction to the IT organizations goals. What's the typical IT organizations single goal? Produce more business value at a lower cost. Anybody got a goal out there to product less business value at a higher cost? I think probably not but that's what happens in a lot of cases after significant investment in these vendors.
So what cost so much time and money? How about patching existing software, upgrading existing software, rewriting code because of end of life issues with vendor provided software, vendors that head off in a new direction, vendors that are purchased or merged with another vendor, vendors that disappear from financial issues. All of these have a significant impact on an IT organizations budget and staff. The second part of this equation is how all of the above software was implemented and wired together.
So the IT organization invests heavily with the vendors and then does what most organizations do. They implement it in silos and then come back and wire it together in the most tightly coupled brittle manor possible. That completes the one two punch. So now not only is the organization in a constant state of change due to the vendor, that change has far reaching impact to applications that have no direct relation to the problem vendor.
So how do we fix all of these issues? How do we move the IT organization to a state where it defines its own strategy and is not at the mercy of the vendors? The real answer is that it's not possible to completely fix this. The goal should be to reduce the disruption as much as possible.
SOA and EDA have a lot in common. One key point they both address (if done correctly) is the loose coupling of applications. This is a big step in reducing the impact of software changes within an environment. Vendor A decides that version 90 of its widget repair suite is going to get a new data model. You have 20 other applications that directly invoke Vendor A's API. That upgrade just got a lot harder. It happens almost every day in a lot of IT shops. Vendor A's strategy has now impacted your IT organization on a much greater scale than just the original implementation group. If the organization had taken a different approach with let's say messaging (asynch when possible), intermediaries, and common XML data representations then the impact has just been reduced significantly.
Layering standards based implementations on top of SOA/EDA architectures can help reduce the impact even more. It can also give the organization the flexibility to make changes at the vendor level. Let's say Vendor A decides to drop support for a component your organization is heavily reliant on. You still must provide the implementation that component provided but now with a different supplied component from that vendor or one from a completely different vendor. With a standards based interface, the impact to the downstream applications will be kept to a minimum level. Standards based interactions can also be used within an application suite. Most application suites are made up of multiple components. These components interact usually with the vendor provided proprietary implementation. There can be significant advantage to abstracting these interactions.
Ultimately moving to SOA and EDA styles of architecture can be difficult and even expensive. It's not the same way of doing business. I do believe that allowing your vendors to drive your organization is ultimately more costly than shaking up the IT organization to a new way of designing and delivering applications. Just remember in the end vendors will make business decisions that are best for them, not you.
The typical IT organization goes into a planning/budget cycle for each fiscal year. Generally speaking it has to address these areas: Things it has to do (Maintenance of existing applications, security, support of existing stuff etc), Things the business clients want to do (new projects and enhancements), Innovation efforts (Looking at new stuff, R&D), Pain Points (Things that causing the organization problems). Ideally you would like your organization to spend most of its time and money addressing what the business clients want/need and innovation. I think in reality a lot of organizations spend most of their time with maintenance and pain points. Why does this happen?
Most IT organizations are heavily invested into software from multiple vendors. IBM, Microsoft and Oracle are some of the big ones but there are a lot of smaller ones that have deep penetration into IT organizations. These companies have a goal and that goal is to sell more software and services to the IT organization (Yes I know they want to "Partner" with you). Makes sense right? The problem is that this goal is usually in direct contradiction to the IT organizations goals. What's the typical IT organizations single goal? Produce more business value at a lower cost. Anybody got a goal out there to product less business value at a higher cost? I think probably not but that's what happens in a lot of cases after significant investment in these vendors.
So what cost so much time and money? How about patching existing software, upgrading existing software, rewriting code because of end of life issues with vendor provided software, vendors that head off in a new direction, vendors that are purchased or merged with another vendor, vendors that disappear from financial issues. All of these have a significant impact on an IT organizations budget and staff. The second part of this equation is how all of the above software was implemented and wired together.
So the IT organization invests heavily with the vendors and then does what most organizations do. They implement it in silos and then come back and wire it together in the most tightly coupled brittle manor possible. That completes the one two punch. So now not only is the organization in a constant state of change due to the vendor, that change has far reaching impact to applications that have no direct relation to the problem vendor.
So how do we fix all of these issues? How do we move the IT organization to a state where it defines its own strategy and is not at the mercy of the vendors? The real answer is that it's not possible to completely fix this. The goal should be to reduce the disruption as much as possible.
SOA and EDA have a lot in common. One key point they both address (if done correctly) is the loose coupling of applications. This is a big step in reducing the impact of software changes within an environment. Vendor A decides that version 90 of its widget repair suite is going to get a new data model. You have 20 other applications that directly invoke Vendor A's API. That upgrade just got a lot harder. It happens almost every day in a lot of IT shops. Vendor A's strategy has now impacted your IT organization on a much greater scale than just the original implementation group. If the organization had taken a different approach with let's say messaging (asynch when possible), intermediaries, and common XML data representations then the impact has just been reduced significantly.
Layering standards based implementations on top of SOA/EDA architectures can help reduce the impact even more. It can also give the organization the flexibility to make changes at the vendor level. Let's say Vendor A decides to drop support for a component your organization is heavily reliant on. You still must provide the implementation that component provided but now with a different supplied component from that vendor or one from a completely different vendor. With a standards based interface, the impact to the downstream applications will be kept to a minimum level. Standards based interactions can also be used within an application suite. Most application suites are made up of multiple components. These components interact usually with the vendor provided proprietary implementation. There can be significant advantage to abstracting these interactions.
Ultimately moving to SOA and EDA styles of architecture can be difficult and even expensive. It's not the same way of doing business. I do believe that allowing your vendors to drive your organization is ultimately more costly than shaking up the IT organization to a new way of designing and delivering applications. Just remember in the end vendors will make business decisions that are best for them, not you.
Thursday, July 20, 2006
Combining SOA and Event-Driven Architecture Using an Enterprise Service Bus @ SOA WEB SERVICES JOURNAL
Nothing really new here that Brenda Michelson and others haven't already covered. But the article is still a good read and another confirmation that SOA and EDA can coexist and should.
Tuesday, July 18, 2006
Microsoft, Xen to run Windows, Linux side-by-side - Yahoo! News
XenSource goes over to the dark side. Forever will it dominate their destiny. On a serious note maybe it will be good, XenSource could use some help on the install department.
Friday, July 14, 2006
SOA Technology Adoption Reaches 90% in 2006, New AberdeenGroup Report Finds @ SOA WEB SERVICES JOURNAL
I don't know if anyone has seen this report but it is a load of you know what. 90% adoption rate, more like 10% would be my guess. A lot of companies are studying SOA and it's impact. But 90% implementing it? I don't think so.
Thursday, July 13, 2006
Microsoft Virtual PC 2004 System Requirements
You got to love Microsoft. They are giving away their virtual pc software for free. Check out the listed OS support, notice the OS/2 Warp. Yeah that's right, all you warped freaks out there can now run OS/2 in a free Windows vm software system. I hear the rush of the crowd.
In a small footnote at the bottom of the page, they did mention that it will support most x86 operating systems. So if you wanted to do something useful like run Solaris or a Linux variety you could.
In a small footnote at the bottom of the page, they did mention that it will support most x86 operating systems. So if you wanted to do something useful like run Solaris or a Linux variety you could.
Monday, July 10, 2006
Sun's open-source odyssey | Tech News on ZDNet
Sun maybe late to the game but they have some good software. It will take time to tell if the strategy will work.
Wednesday, July 05, 2006
Curious about WS-Addressing
I'm plowing through the mountain of standards relating to web services. One that is interesting to me and that I'm kind of on the fence on is WS-Addressing. I am curious to what others think about this. I can see some of benefits especially the address (endpoint) and reply-to parts. But I can also see increasing the complexity for the developers by requiring them to know a lot more about the implementation than they had with just a simple URL.
Without WS-Addressing, the developers just implemented their web services consumer with the provided WSDL which basically was just manipulating objects in their native format (Pretty easy stuff assuming you are using Doc/Literal). With WS-Addressing they would be required to populate the header of the SOAP message. This is not contained within the WSDL. It does requires more in-depth understanding of the SOAP message structure. Of course I guess that they will have to learn sooner or later based upon the other WS-I standards coming out. Either that or run away screaming, kind of like J2EE.
I'm wondering from a practical (not purist) standpoint if implementation based upon some other method is not better? What does everyone think? WS-Addressing the way to go? Or is it too much added on to the developer? By the way I use an intermediary or middleware layer as the entry point, I don't allow point-to-point connections or interfaces.
Without WS-Addressing, the developers just implemented their web services consumer with the provided WSDL which basically was just manipulating objects in their native format (Pretty easy stuff assuming you are using Doc/Literal). With WS-Addressing they would be required to populate the header of the SOAP message. This is not contained within the WSDL. It does requires more in-depth understanding of the SOAP message structure. Of course I guess that they will have to learn sooner or later based upon the other WS-I standards coming out. Either that or run away screaming, kind of like J2EE.
I'm wondering from a practical (not purist) standpoint if implementation based upon some other method is not better? What does everyone think? WS-Addressing the way to go? Or is it too much added on to the developer? By the way I use an intermediary or middleware layer as the entry point, I don't allow point-to-point connections or interfaces.
Monday, July 03, 2006
Subscribe to:
Posts (Atom)