In general we are agnostic about SOA. SOA is a good way to implement these subsets so that that the technical architecture is closely aligned with the business architecture. So I like SOAs from this perspective. But it's really at a lower level than what we do. What we do is identify the optimal configuration of subprojects. We answer the question of how can you break this big project up into the best possible configuration of smaller projects? How you implement those projects, we largely leave to the implementation teams.
Does the arrival of cloud computing help simplify the world or just add another layer of complexity?
In my opinion, it adds another layer of complexity. I like the idea of cloud architectures, not for everything, but for many things. But it is a serious mistake to put a large, complex system on the cloud. That's going to be very difficult to do, very difficult to manage. And if you're successful, you'll be trapped on that particular vendor.
So what you want to do is break these systems up into smaller pieces. And then for each one of the pieces make the best possible implementation deployment decision, such as should we use service-oriented architectures to implement it? Should we use the cloud as the deployment platform? But you do that after you've removed as much of the complexity as you can by splitting up the project into smaller projects.
So far we've been talking about green field, starting from scratch. Could your approach help a company get a handle on a big existing system that breaks too often?
Yeah, it can. Because in many cases what you find in these very large systems are a few complexity hotspots, or what I call complexity knots, that one part of the system where everything seems to break. Or, if it's interacting with some other system, the interactions fail. A lot of times the problem is that one function has been placed in the wrong place. And if we move it from one system to another it can dramatically reduce the complexity. You can really extend the life of a system by doing something like that.
We had a situation like that where we were looking at two insurance systems that had to work together. And every time information was passed from one to the other there was a high probability of failure. We showed through complexity analysis that the problem was not how they were packaging the information or that one group was not dealing with the information correctly. The problem was that they shouldn't have been passing that information in the first place. If they slightly adjusted the functionality so the right system was doing the right analysis, the whole problem went away.
That's not uncommon. Now, of course, you'd like to do this with a new system, because the more you can reduce complexity in the first place the better long-term payback you're going to have.