Suppose you are having a conversation with the CEO, CFO or even the Business Manager and you try to help them understand that the package they are so excited about, and whose vendor has done a really impressive demo, is not going to solve all their problems.
In this particular situation what I found is that resorting to Geoffrey Moore’s Core/Context model I can find a really nice way to explain what the problem is.
First, draw the quadrant and remind them that by definition packages implement processes that are Commodity. So a package will be drawn on the right end side. Remind them that software vendors make no money by delivering processes that are unique, which they could only sell once. And so you won’t find those types of processes in the package. This means that when you are installing a package in a particular organization you’ll have to customize the package for a collection of processes and functionality that are specific to your company. This means you are now using a package to implement a collection of processes that are half in the Deploy quadrant and half in the Manage quadrant, which means you are going to implement a package right in the middle of this line here. Because by nature the left end side of this diagram is where all change happens, it’s a very unstable world. Remember, this is the invention Zone where new ideas and differentiating processes appear. And so it’s a world of trial and error, it’s a world of instability and changes in the processes and in the correspondent software.
And so the IT backlog is going to be growing out of change requests from the business that target the processes on the left end side. But if you have a package installed here, that supports those functions and processes, those changes are going to have to be implemented in the package. And so, as time goes by, the package becomes more and more customized, more difficult to change, more difficult to maintain and more difficult to upgrade to new versions that are released by the vendor. So before making a buy decision, you need to perform a gap analysis between the functionality you require and the features the package provides out-of-the-box. As a general rule, if this gap analysis determines that more than 10% to 20% of your requirements demand package customization, you need to reevaluate the pure buy decision. Such high levels of package customization are going to create a maintenance nightmare for your IT. You know that so you have to pass that knowledge to the CFO or the CEO. So the question that they usually ask you at this point is “Ok, I got it. So, what’s the solution to this? What should we do?”
For these scenarios, building the old solution from scratch is not a feasible option. Go ahead with the package, but make sure that it has a very extensive collection of open APIs, preferably Web Services APIs. For the processes that are custom and which lie on the left end side of the diagram, use a composite application platform or development framework. Build a custom application and glue it to the package via Web Services. The final solution should be a composition of something that you build and something that you buy. You’ve created the solution where you have isolated the piece that is stable and needs to stay stable from the part that is going to change.
In this case, of course, you need to look for a development framework and processes that are geared towards supporting that change. Because the promise you are making to your CEO or CFO here is that you have now an architecture and the capability that enables you to respond to business change requests fast and effectively. I don’t know if you realize this but you have just explained to a non-tech person the basics of a Service Oriented Architecture, where systems need to be isolated from each other but loosely connected. You have also given them a sense of how expensive software change is dependent on the component that is going to be impacted by that change.
In my next video, I will tell you how I usually explain the full impact of a Service Oriented Architecture to a CEO or CFO and going to detail on some of the IT practices required to implement a no non-sense pragmatic approach to SOA.