I’ve been thinking about this during my free times for more than a month. Since our development teams are exciting and eager to moving itself to agile development process while we, as the architects who have to take care a lot of many tasks and needs from several stakeholders and projects, have to take care of them and response to their demands in order to let them run and enjoy their works.

It boils down to a conclusion that we may also need to change our process or method of working too. In Bangkok side, we have to be able to response to the needs of development teams along with other stakeholders while keep it in balance at the same time. So we need to make our method of working more flexible and clear.

Architects, have to do the architecture design and govern it through the implementation to deployment and support and maintenance. While in the agile manifesto, dev tends to prefer and trust in thinking and prove it through testing and refactoring (to make “Emergent Design”) than what they call us “Big Design Up Front”.

In order to works with teams that are trying to do agile process, we need some guidelines or rules in making decision about what requirements or architectural elements that are needed to be passed through architectural design process strictly or we can leave it to be solved at development level. Here are those criteria that I can think of for the moment, the more or higher those elements or requirements are like these concerns, the more it has to pass-through formal architecture design process, prototyping, and governance.

1/ How much this requirement or functionality or module or project is:

  • Less clear and concise
  • Critical or important
  • To access, feed, inject, process, or manipulate something into the critical system or the system that is a single-point-of-failure of a system
  • Complex
  • Risky
  • Cause impacts to others
  • Be the foundation work for other works/teams
  • Urgent
  • Distributed processing
  • Heavily connected to many parties such as the integration works
  • High cost
  • Quality attributes are highly concerned
  • Frequently change the responsible product managers

2/ How much the development teams used for this module or system or functionality or requirement are:

  • Less skilled
  • Less mentally matured
  • Less process-wise matured
  • Distributed across time-zones and spaces
  • Politically divided
  • Limited in resources
  • Frequently change their staff

3/ Technology and tools

  • Less mature
  • Low activity (for open-source technology)
  • High licensing costs
  • Less vendor support
  • Low and slow response in their discussion boards (for open-source technology)
  • Hard to do maintenance and high TCO
  • Unclear between technology choices
  • Vendor’s status is uncertain

4/ Budget for your project

  • Limited
  • Uncertain and need long time for approval process

5/ Project and timeline

  • Strict and rigid
  • Tight
  • Uncertain
  • Frequently change project managers

6/ Environment and infrastructure and its management

  • Less mature
  • Limited
  • Distributed
  • Concerns in security
  • Need long process for changing something

Other things than this, I think we can leave it to be solved or try at development level in order to let them do development faster and more agile as they need, while we will join them in the potentially architectural-related refactoring and emergent design discussions, we will then gather the results and feedbacks back to do formal design and communication for formal reviewing to make some formal change in the design as appropriate.

The good signs that we already have are, we are starting to do “Incremental PIA” and self-assessment process on top of the formal PIA and technical governance review process. So I think these ideas could fit together.

I will share my idea with you all about the whole process in architectural design iteration in order to work with across smaller development cycles later.

What do you think?