Tag: Architect

Today’s solution is tomorrows problem

No one can predict the future. If you accept this as a universal truth, than the question becomes how far ahead is the future? One decade? Two years? Twenty minutes? If you can‘t predict the future than you can‘t predict anything beyond right now. This very moment and the ones that preceded it are all you are know until the next moment occurs. This is the reason we have car accidents – if you knew you were going to have an accident on Thursday you would probably stay home.

Yet we see software architects try to design systems that will be, for lack of a better term, “future proof” all the time. It‘s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today‘s distributed framework will become tomorrows DCOM. In short, today‘s solution will always be tomorrow‘s problem.

If you accept this fact, that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don‘t worry about what the future will hold, choose the best solution that meets your needs today.

One of the problems architects have today is analysis paralysis and a big contribution to that problem is trying to guess the best technology for the future. Choosing a good technology for right now is hard enough, choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now because anything else will not only be wrong choice tomorrow, but the wrong choice today.

Software engineering is often compared to well-established disciplines such as civil engineering. There‘s a problem with these analogies; unlike the very tangible products created by these traditional practices, software doesn‘t really exist. Not in the traditional sense anyway. Those of us in the world of ones and zeroes aren’t constrained by the same physical rules that bind classic engineering paradigms. While applying engineering principles to the software design phase works well, assuming you can implement the design in the same manner used by more traditional engineering approaches is unrealistic.

Both business and software are living, moving entities. Business requirements change rapidly due to things like newly acquired business partners and marketing strategies. This makes it very difficult to approach a software project in the same manner as a traditional engineering pursuit such as bridge construction. It is highly unlikely that you’ll be asked to move the location of a bridge halfway through a construction project. However, it is very likely that the acquisition of a business partner will require you to add support for organization-based content management to an application. This comparison should put things into perspective. We often say that software architecture decisions are difficult to change but not nearly so much as things that are literally and figuratively set in stone.

Knowing the products we build are pliable and that the requirements surrounding them are likely to change puts us in a different position than someone building an immovable object. Engineering endeavors of the physical flavor are much easier to implement in a “plan the work, work the plan” nature. With software things need to be tackled in more of a “plan the work, massage the plan” fashion.

These differences aren‘t always bad news, at times they can be advantageous. For example, you’re not necessarily constrained to building the components of a software system in a specific order so you can tackle high-risk issues first. This is in direct contrast to something like bridge construction where there are many physical limitations surrounding the order in which tasks are accomplished.

However, the flexibility of software engineering does present some issues, many of which are self-imposed. As architects we are very aware of the “soft” nature of our craft and we like to solve problems. Worse yet, the business owners are vaguely aware of these facts. This makes it easy for them to push big changes. Don‘t be too eager to accommodate large architectural changes just because it appeals to your solution-providing nature. Decisions like that can break an otherwise healthy project.

Remember that a requirements document is not a blueprint and software doesn‘t really exist. The virtual objects that we create are easier to change than their physical world counterparts, which is a good thing because many times they‘re required to. It‘s ok to plan as though we‘re building an immovable object; we just can’t be surprised or unprepared when we‘re asked to move said object.