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.

No comments: