There is a common practice in most of the IT organizations we visit. Everyone calls it something different: “build once, use multiple times” or “Service Oriented Architecture” or any of a variety of other names. The general idea is that if we can figure out how to build what we are working on now, so that it will help people in the future, then we should. For example, if we are building an application that needs to look up customers from a customer database, then let’s build a Customer Lookup Service so that no one else will ever have to write that code.
Who could argue with this premise? Of course, we’d like to build things once and not have to write them again. Of course, we’d like future teams to be able to build on what we’ve created. Unfortunately, this is one of those ideas that sounds good in theory, but in practice looks very very different.
Let’s look in more detail. First, to clarify the theoretical argument, let’s restate it more clearly: “In order to optimize our overall portfolio of technology assets, it is worth adding work to some projects, so that future projects will benefit.” Notice the key addition: we are adding work to current projects: design work, project management work, development work, testing work, documentation work, etc. Not only does this mean that the current project (let’s call that Project A) is bigger, but because bigger projects are riskier, it is more likely to fail. Every single time we increase the scope of a project, we increase its likelihood of delay or overall failure. Is it worth it to help out a future project (let’s call that Project B)? The number one challenge in most IT organizations is failure to deliver projects. Are you sure you want to make it harder?
Despite the fact that we’ve made it less likely to succeed, let’s say that Project A is successful and it deploys. Now, a year later, Project B comes along. Thank goodness we built that Customer Lookup Service, they should be able to just plug it in. Of course, the developers from Project B look at the service hoping it will help, but it is just as likely to need some updating. Maybe they need different fields, or they need to be able to pull multiple customers at the same time, or… well you get the idea. It needs to be slightly different than what was originally written. They go to the original team (assuming they are still around) and ask for changes. In most organizations, this is likely to be a slow, time consuming process. Longer than writing something from scratch. In other words, Project B is now saddled with the expectation that it should use the service, even though it will take them longer. We’ve made Project B more likely to fail.
I’ve had a change of heart on enterprise architecture and design. I think we are wasting our time and resources on something that is unlikely to yield results.
