You, as an architect, must take the initiative

Simply by having an "architect" word in your title or role description automatically puts a heavy burden on you. Automatically people will assume, and rightfully so, that you have the responsibility of gathering and synthesizing information and making early design decisions. Your colleagues and stakeholders will expect guidance from you - well before and after the official software design phase commences.

As an architect you should be very well aware that you're under a spot light at all times. Nobody will ever tell you that the right time has come to start architecting. If someone has to tell you that now is the right time to start architecting it means that you're not paying attention. There are, of course, times when it appears that no action is required. For example, requirements are too fluid and insufficient to start designing, or a business case for a solution has not yet been well defined, or perhaps the funding has not yet been approved. The times of uncertainty are the times when the rest of the organization / team needs you the most.

As an architect, or rather as a Firebrand Architect, you should take initiatives to position the flow of the project / solution to enable you and the team make disciplined rational decisions. If you take the initiative, then you control the pace of the development. This does not mean that you have to fight for control with marketing or the R&D group. This means that you need to proactively monitor the environment and understand how the ongoing developments will constrain your downstream design space.

For example, if the requirements team is struggling with analysis try to evaluate if they are diving into details too soon. User your software engineering skills. Perhaps they are lacking a coherent vision document, lack requirements gathering structure, or simply lack resources. Determine if you can provide high level help based on your previous experiences. In the case of writing a business case you can provide insight of how this type of a solution would blend with existing systems and help determine time to market.

If you control or influence the pace and flow of your project progress before and after the software design phase you maximize the design surface area with which you can work to create software that's fit for purpose when the official design phase commences.


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement