Are you a hands-on architect?

What do you do as a designated Architect of the team? Are you still hands-on with implementation design and coding?

Hands-on Software Architect

Do you spend most of your time creating an up-front architecture and design with lots of artifacts(Architecture views, process and flow diagrams, models etc) and posting these architecture and design documents for reviews, updates,  presentation to the management and development teams for feedback and comments? Or Do you like moving quickly to evaluation, validation and experimentation of your design and architecture by quickly implementing the skeleton architecture with the development teams and other stakeholders and following it with validated architecture refactoring and iterative evolution?Do you consider working skeleton-code with running tests as an architecture artifact? These are a few questions which define your architecting mindset and process followed to architect and design.

Software architects find immense satisfaction and pride in developing the architectural artifacts in  isolation with the occasional ceremonial presentation. They find more comfort and security in their isolated ivory towers. Inspired by the real-world infrastructure architecture and architecting process, software architecture has been envisaged as a big up-front process, only for specialist –  ‘An art’, which can be performed by fewer designated individuals. They communicate occasionally with artifacts created in isolation, and leave as soon as possible to enlighten other projects.

Lonely Architect

I see following reasons for this “Architecting-in-Isolation” mindset in architects:

1. Software architects do not understand the boundaries of software architecture. They tend to do a lot of up-front design with limited feel for  a ‘Just enough architecture’ which can enable quick design and implementation.                                                                                                        
   

   Undefined boundaries of Software Architecture

2. Software architects do not emphasise on continuous validation, evaluation and experimentation of architecture. Architecture does have elements which can be re-factored,  iterated, and developed incrementally with more validated learning and feedback from stakeholders.
3. Software architecture and design emerge and there are many unknown-unknowns. Architects tend to assume lots of things up-front. They cover it up with known architectural styles, patterns, past experiences and best-practices and ignore the fact that architecture and design will evolve and emerge as it get coded.                                                            
   

   Unknowns of Software Architecture

4. The architecting cycle is very long, non iterative and incremental, and executed away from the development process. Architecting process is detached from the development process.

        

Software Architecture and Development teams in isolation

There are other reasons which keep architects away from the development teams. Like, involvement in other  parallel projects. I will not discuss them here.
 
One big challenge architects always face is in deciding when to stop up-front architecture and design work, and start enabling design and implementation. Most of the time, architect tend to overload lots of detail in their early architecture artifacts. They attempt to define, every component, every interface, many views and system quality concerns; almost every minute detail that crop-up in their minds at the early phase of the product design. They tend to make lots of assumptions about the design and architecture without validation and verifications. Working away, in-isolation, from other stakeholders, they do not know what is just-enough optimal architecture and design  for development teams to get going with implementation. They do not see the waste they are creating by big up-front design activities and impediments bought to the flow of agile and lean development of working and well-crafted software.

Architects needs to embrace lean and agile architecture and architecting process. They need to get their architecture artifacts consumed as soon as possible in the design and implementation iterations. They need to understand, that working code, which can validate their architecture decisions quickly and help them to evaluate design options is more effective than big architecture document created over weeks of isolated research. Now, I am not saying architecture should not be documented.  Documentation can always be done incrementally and iteratively. Just lay down enough details, avoid long component diagrams, class details, pages,of flow and sequence diagrams, data models and deployment scenarios etc. Keep it simple, short, quickly communicable and consumable.

Even if it takes to write only just few draft pages, few wire-frames, hand sketches and board diagrams, Do it!. It has to be lean. Avoid all forms of waste which do not add value up-front.  Design, in short iterations, communicate continuously,  work closely with your developers and code for the skeleton architecture and cover it with the unit and acceptance tests. Take it to other stakeholders – product owners, Dev-ops, QA etc for reviews and feedback. Continuously re-factor and iterate over architecture and design. “Validated learning” about the architecture obtained through incremental architecture development and continuous validation is more effective than big up-front architecture and design activity which do not add much value and is very difficult to validate.

Now, experts will debate on how much you can actually re-factor software architecture. Well off-course, not to the extent that you can re-factor code, but yes, there are elements of architecture which needs to be  iterated and re-factored. Like, components and service interfaces  can be understood only after understanding the component usage and interaction patterns, service and resource relationships and dependencies. Interface design needs continuous refactoring. If you try to identify and design all your interfaces up-front, by making all architecture decisions at the start, just imagine the mess.
.

Functional models, Data models, thread models, development models, process and deployment models all evolve as you learn more about the system and its architecture and design. Sooner you get the working software, better you can evaluate and validate your architecture and design.
Which means architects need to be hands -on. They should be working closely with the development team to ensure that architecture and design is quickly and correctly translated into working code. 


Try this to successfully achieve incremental and iterative architecture. Based on the known use-cases and user stories,  list down some known high-level components, their relationships, important interfaces, some notes on desired  threading models, sketches of data models, few non-functional concerns and constraints like failure scenarios, required performance with measurable numbers etc. Enable some early-communication and brainstorming discussions with the development team.
Even before you document details, sit down with the team to code the skeleton architecture components and elements with the acceptance tests for the required user stories.  Define and name the system components and their interacting behaviour and interfaces. Define both the construction and interaction behaviour of the components. Functions are implemented with with no real code but well named classes and behaviours and covered with tests. Use ubiquitous domain language to define the components, classes and function names. Run the tests to ensure that component wiring is complete and correct with right interfaces as per the use cases. Ensure tests are developed and become the specifications of the desired behaviour.


The important thing for an architect is to know how much time she allocates for herself  to get involved in day-to day implementation and design activities as early as possible and  see the architecture getting codified.  This is the only way to know how well the architecture is realized in design and code.
I believe, coding is a  designing-activity and lots of design actually happens when we code. Can you see your architecture and design in code?

Try to answer the following questions for yourself:

• How much detail is enough to create and communicate architecture?
• Where do we think that the architecture is just enough for design and implementation  to take over?
• Do you know about the risks associated with each element of architecture? Based on these risks how early you get these things designed and implemented? How much time you allocate to risky architecture component’s implementation?
•  Do you continuously validate your architecture? And how?
•  How much are you involved with the development team and how often do you receive the feedback on the architecture and design issues?
• Do you see architecture and design getting evolved as you code and implement? And how?
• What is your architecture documentation process? is it on-time up-front process?
• Are you still coding? Do you allocate time to get involved in implementation and coding? Coding exercise will help you to understand the architecture and design decisions better.

Creating Lean and Agile Software Architecture

“The lean and agile way of developing software architecture” has been my primary area of study for some time. I have been doing research study on this area and developed significant understanding of what researchers and practitioners of agile software development and software architecture have to say about this challenging subject which has been mostly ignored by lean and agile gurus and coaches in their expression of agile methods and principles.

 

 Many extreme agile practitioners and thought leaders discard any form of architecting activities in agile environment. They believe that software architecture emerges as result of incremental and iterative designing and implementation activities of teams and can be re-factored to the desired structure incrementally throughout the implementation cycle. This group of agile practitioners views all upfront architecture and designing activities as waste, documentation-intensive and high ceremonial activities which slow down the early valuable delivery to customer and reduce capabilities to respond to changes. They embrace principles of ‘YAGNI thinking’ (You aren’t gonna need it) to extremes, and controvert any upfront architecture-centric work during software development.  

 

On the other extreme are those ‘software architecture perfectionist’ and agile phobic groups who believe that software architecture in large and complex systems requires extensive, careful planning, upfront decision making, deep analysis, synthesis, centralized evaluation and it cannot be left to iteration teams to make those critical architecture decisions during their daily design and implementation activities. They are skeptical about the effectiveness and reliability of agile methods to solve software architecture problems. They are uncertain and fearful about the changes agile practices are bringing to their traditional and centralized software architectural practices of ‘big upfront design’. How often have we heard this in skeptical scrum team?  –  “Agile says no to architecture and design, so we did not do any at the start of the iteration. There would have been less re-work and no re-factoring issues if we had designed it all upfront”. 

 

As lean and agile approaches mature in handling software architecture in complex products, there is strong realization and need for complementary approaches to blend software architecture and iterative lean and agile software development activities by principles and practices for better quality software products and processes. Especially, large and complex software system development teams have realized that efficiencies, flexibilities and reliabilities of agile methods have to work in synch with effectiveness and elaborate details of established software architecting practices, which reduce cost and time, and provide an integrated and structural approach to software design and development. There is a need to architect solutions which embrace change, and design them within an incremental, iterative and shared framework to incorporate continuous feedback from all stakeholders. This means, software architecture has to be agile by its ‘form’ (structure) and by ‘process of architecting’. A shared, and consistent understanding of software architecture need to exist in different agile teams to realize agile architectures. Lean and agile methods can no longer ignore the software architecture aspects and there is immense need of a unified , collaborative and coexisting approach to architecting and designing lean and agile software. 

 

I plan to present my thoughts in a series of following upcoming blog posts:

 

• Integrating software architecture with Lean and agile software development principles and practices.
• Lean and agile software architecture by form and structure.
• Lean and agile software architecting process
• Differences between traditional and lean&agile software architecting.
• Who are agile architects and what do they do differently
• How lean and agile principles guide software architecture?
• Tools, techniques and artifacts for agile and lean software architecture.