A 3-D approach to Software Architecture

The 3 'D's of software architecture: Discuss - Design - Develop

The role of a good software architect begins very early, at the requirements understanding stage, and continues throughout the application lifecycle all the way to delivery and support. Such an architect's role can be summarized as: Understanding the client's business problems, evaluating them, and then helping to deliver optimum solutions that meet the clients' needs well, and at the same time are clean and maintainable.

To achieve it: DISCUSS, DESIGN, and DEVELOP. A good rule of thumb: Spend 1/3 of your total time on each of these.

DISCUSS. An architect will start the project conceptualization by discussing with the customer to find out their exact problems and their desired solutions. The "customer" may be external (a business client) or internal (another department within the company), or may even be a Business Analyst assigned to work with the end-user.

Focusing on finding out the real problems, separating the must-haves from the good-to-haves, and then prioritizing the ones that are most important for the customer's business, is crucial. And there's no way it can be achieved without extensive and intensive discussions.

DESIGN. This is the phase that connects the customer's business requirements with the technical software solution. Consider factors and requirements such as: Scalability - what volumes of data / updates / traffic / registrations are we talking about? Responsiveness - what's an acceptable response time... 1 second or 1 minute for a query? Platforms and toolsets, security, availability, disaster recovery - all these, and more, factor into a rock-solid design.

DEVELOP. Finally, work closely with the development team to make sure everything is implemented properly. There's just no way to simply draw a bunch of UML diagrams, hand them over to the dev team, and walk on over to the next project. Effective architects will work hand-in-hand with the developers, because often design portions change, unexpected problems come up - even customers' own requirements evolve (really!).

And, of course, the 4th "D": DELIVER! Delivery of a solution that meets the customer's needs, on-time, under-budget, and is ready not only for easy maintenance but also for future extensibility, is the goal of a software architect's work.

And "delivery" doesn't mean just handing over the solution, and then moving on! Code-complete is just the beginning. Architects take responsibility for the entire application lifecycle (ALM) of their projects: They will continue to give high-level technical assistance to their customers, research and recommend relevant upgrades to management and customers, coordinate with the development, QA and support teams to make sure customers' needs remain addressed, and keep tweaking their system architecture to keep it updated and in pace with relevant technology advancements.

What do you think? As a software architect, do you regularly find yourself using this philosophy in your day-to-day work? Please do share your thoughts and comments!