Latest edition of O’Reilly Software Architecture Conference was held in April ‘16 at New York. It’s a four day event conducted by O’Reilly.

First two days of the conference had parallel tracks of 2-day training courses in Software Architecture fundamentals, Microservices, MEAN architecture and Agile development. Training courses were followed by keynotes and sessions related to cloud computing and design/development of web services.

Software Architecture fundamentals training

Course agenda

Software Architecture fundamentals training course, that I had attended was conducted by Mark Richards and included the following topics in its agenda

Course format

Two day course included lectures and hands-on training exercises. Exercises were aimed at gaining practical experience by applying architecture patterns and design methodologies, discussed during the training, to real world software architecture challenges.

As part of exercise, smaller groups (about 5 to 6 members) of training attendees worked together on various real world project requirements and proposed architecture solution to other groups. These exercises also helped to get first hand experience of working with a group of Architects and debate the pro’s and cons of proposed solution.

My personal takeaways from the conference

I would like to share my take on few topics from the training agenda. Material shared in the posts would be based on my understanding and notes from the training (Note: Content I’m going to post here is not exact reproduction of the training material)

There will be series of posts, each post focusing on one aspect of Software Architecture practice which was covered as part of training agenda. I will begin the series with couple of scenarios which can be grouped under “Roles and expectations of an Architect”

Roles and expectations of an Architect

Several roles and expectations that span across multiple functions like Engineering, Technology, Business and Leadership are set for an Architect. Two specific scenarios where Architect should play key role are

  • Business requirement discussions
  • Ownership of Architecture vision
Role of Architect in business requirement discussions

In certain discussions with business or technology team, we hear suggestions about using a particular framework or tool when there is a need for introducing new business requirements in any software project.

Whenever initial business requirement discussion is driven by strong reference to any particular tool or framework, the context of discussion would focus more towards possible solutions and might mask the actual requirement. Architect should make sure that the actual requirement is well defined before discussing the pro’s and cons of certain tool or framework that has come up for discussion.

For instance, some member of business or technology team might start business requirement discussion by saying, “We should use Lucene for full text search capability”. There is nothing wrong in coming up with suggestions, but focus on the suggestions should be preceded by definition of actual business requirement. Architect should validate the feasibility and relevance of any tool/framework suggestions that has come up during such discussions and communicate back to the team with his analysis.

Ownership of Architecture vision

If there is a lack of ownership and maintenance of overall architecture vision for a software project, each individual team working on that project would focus on the perception they have of the vision and work towards it.

An architect or architecture group should be the first choice who would maintain the ownership of overall architecture vision. They should make sure that the vision is communicated without ambiguity to all the stakeholders of the project.

Architects should ensure that the overall architecture vision of the project is properly communicated across various stakeholders of the software project. Based on inputs from Engineering and Business teams, Architect or Architecture group can evolve the vision overtime which would cater to Engineering and Business requirements.

References