Category: Software Architect

Design patterns are one of the most valuable tools available to the software architect. Using patterns allows us to create common solutions that are easier to communicate and understand. They are concepts that are directly associated with good design. This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project. If you find yourself trying to shoehorn your favorite patterns into a problem space where they don‘t apply, you may be a victim of pattern pathology.

Many projects suffer from this condition. These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying “Now, which one will I use first!?”. This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”. Design patterns are excellent tools for mitigating necessary complexity but like all tools, they can be misused. Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail. Be careful that your appreciation for patterns doesn‘t become an infatuation that has you introducing solutions that are more complicated than they need to be.

Stamping patterns all over a project unnecessarily is over-engineering. Design patterns are not magic and using them doesn‘t automatically qualify a solution as good design. They are reusable solutions to recurring problems. They have been discovered and documented by others to help us recognize when we‘re looking at a wheel that‘s already been invented. It‘s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately. Don‘t let your desire to exhibit design pattern knowledge cloud your pragmatic vision. Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.

As a software architect, have you had a hard time getting your architecture project well funded? The benefits of software architecture are obvious for architects, but are mythical for many stakeholders. Mass psychology tells us that “seeing is believing” is the strongest belief for most people. At the early phase of the projects, however, there is little to demonstrate to convince stakeholders of the value of sound software architecture. It‘s even more challenging in the non-software industries where most stakeholders have little software-engineering knowledge.

Mass psychology also shows that most people believe in “perception is reality.” Therefore, if you can control how people perceive the architectural approach you propose, it‘s virtually guaranteed that you control how they will react to your proposal. How can you mange stakeholders‘ perceptions? Make a strong business case for your architecture. People who have the budget authority to sponsor your ideas are almost always business-driven.

I have employed the following five steps to generate solid business cases to successfully sell my architectural approach many times in my career:

• Establish the value proposition. The value proposition is your executive summary of why your organization‘s business warrants a particular software architecture. The key for this is to compare your architectural approach with existing solutions or other alternatives. The focus should be put on its capability to increase the productivity and efficiency of the business, rather than how brilliant the technologies are.
• Build metrics to quantify. The values you promise to deliver need to be quantified to a reasonable extent. The more you measure, the more you can bolster your case that sound architecture will lead to a substantial return. The earlier you establish metrics, the better you manage people‘s perceptions that help you sell responsible architecture.
• Link back to traditional business measures. It would be ideal if you can translate your technical analysis into dollar figures. After all, the only constant parameter in the traditional business measures is money. Find business analysts as your partners if you are not comfortable with financial work.
• Know where to stop. Before you know where to stop, you need to prepare a roadmap that captures a vision with each milestone on it tied directly to business values. Let the stakeholders decide where to stop. If the business value for each momentum is significant, you‘re most likely to get continued funding.
• Find the right timing. Even if you follow the above four steps to generate a solid business case, you may still not be able to sell your ideas if you pick the bad timing. I remember one of my proposals did not get approved for a long time until another project turned out to be a total failure because of poor architectural design. Be smart on timing.