Tag: Architect

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.

When choosing software frameworks as a basis of your system, you must consider not only the individual quality and features of each framework, but also how well the set of frameworks that make up your system will work together, and how easy it will be to adapt them to new software you may need to add as your system evolves. This means you must choose frameworks that do not overlap and that are humble and simple and specialized.

It will be best if each framework or 3rd party library addresses a separate logical domain or concern, and does not tread into the domain or concern of another framework you need to use.

Make sure you understand how the logical domains and concerns addressed by your candidate frameworks overlap. Draw a Venn diagram if you need to. Two data models that overlap substantially in domain, or two implementations that address very similar concerns but in slightly different ways, will cause unnecessary complexity: the slight differences in conceptualization or representation must be mapped or patched with kludgy glue code. Chances are you’ll end up not only with complex glue, but also with the lowest-common-denominator of the functionality or representative power of the two frameworks.

To minimize the chance that any given framework will overlap with another framework, choose frameworks that have a high utility to baggage ratio, in the context of your system requirements. Utility is the functionality or data representation that your project needs from the framework. Baggage is the framework’s sweeping, all-encompassing, I’m-in-charge view of the world. Does it insist on mixing data representation and control? Does its data model or set of packages and classes extend well beyond what your system needs? Do you have to become a fundamentalist in the framework’s religion, and limit your choices of other frameworks to those of the correct denomination? Does its excess complexity limit the kinds of things you can mix with it? If a framework comes with lots of baggage, then that it had also better be providing 75% of the functionality value in your project.

Your system should be comprised of mutually exclusive frameworks, each of which may be a master of its domain, but which is also simple, humble, and flexible.