Once you realize it's a $3 million or $4 million system you realize you've got less than a 25 percent chance of success unless you do something different. You can use decompositional design to carve the system up into four small systems, but the chances are that you're going to end up with a worse situation. So instead, we come in and do the pre-planning, which is before the system architecture is created. We figure out the optimal way to take the large collection of functionality and carve it into smaller projects, so that each one of those projects is as simple as it can possibly be. It may be four subprojects. It may be eight. It will be whatever the mathematical analysis tells us is the best way to do it.
There are a lot of benefits to doing this. First you've greatly increased the chances of success, because each one of those projects is small enough so it has probably an 80 percent chance of success. You've also reduced the cost of the project, because cost is directly proportional to overall complexity. And you've made it much easier to determine what functionality needs to be in each one of the pieces.
It is a multi-stage process. First we identify the business functions. Then we do synergistic analysis, which tells us which functions need to live in which subsets. And those subsets eventually turn into independent projects. So it's not a short process, but relative to the cost of doing the entire project it's very fast and it's more than paid back by the fact that you reduce the complexity of the overall system and therefore reduce the cost and the failure rate.
NW: Do you mostly work in SOA environments?
Sessions: 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.
NW: Does the arrival of cloud computing help simplify the world or just add another layer of complexity?
Sessions: 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.
NW: 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?
Sessions: 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.