Saturday, September 05, 2015

Making the best use of Architects in an Enterprise

I have worked with many types of Architects over the past 10 years. Most of my work experience is in the Enterprise world, which gave me a chance to work with more Architects than a non Enterprise developer would get. They come in different shapes and forms, Software Architects, Product Architects, Technical Architects, Solution Architects and drums roll….Enterprise Architects. Although you may not see this in formal job adverts there’s such a thing as Architect Astronauts as well.


Although we got architects coming in different shapes and sizes, unfortunately I have not seen many adding a lot of value to a project delivery. Yes, some of the above mentioned architects by definition of their role does not have anything to do with a delivery, at least not in a direct way. I won’t be stretching the truth if I say that architects are people who have been in the industry for a considerable amount of time and have done a lot of delivery work themselves - albeit prior to them being architects. Given that, it’s counter intuitive in a way, that Enterprises in general values architect input in more strategic and high level areas and ignore the value they could provide in shipping software.

First, I’d like to discuss whether it’s beneficial for an organization to encourage its architects to play a more involved role with the delivery teams. Then in the cases where it is, I’d like to discuss some techniques one can use to get the best out of the role ‘Architect’. During the process the I’ll also try and see how an architect him/her self could benefit by being more involved in project delivery.

Benefits of Architects involving in Delivery
In my past experience most architects engage with the delivery teams either at the start during elaboration or at the end during roll out (specially when things turn out to be nasty). In my opinion this is not the optimum use of an architect. Software Architecture by definition covers the aspects of Software Development that’s hard and costly to change. By dis-engaging with the delivery team after the initial phases you are losing valuable feedback that you get during the lifetime of project development. Feedback that is essential in identifying the pieces of your software that need to change, adapt to the ongoing changes and new findings. Most of the time architect is not to be found until the project gets close to delivery and at that point most of the decisions that have been made have become too difficult to change.

Another disadvantage of not being in touch with the teams is that the architect losses upto date information re: how the technology landscape is moving. How can a person who is suppose to make organizational level technological decision get himself disconnected with the best possible source of relevant technological information. A dis-engaged architect has no chance of keeping the product architecture respond to changing requirements while making sure it also aligns with the enterprise architecture vision as well.

So what would be the best possible way of getting the best out of the Architects. Assigning him delivery tickets from your sprints might not be the best possible tactic. Yes, there’s nothing like delivering cold hard code that gets you right in to it. But considering the varied aspects of an Architects’ role, burdening him with direct delivery artifacts might not be the most efficient use of his time. It might even be detrimental to the team. The team velocity might see weird up and down spikes based on how busy the Architect is with other commitments.  

Tactics for enhancing Architect Engagement


Daily Stand Ups
Daily stand up is an efficient method of getting to know the pulse of the team. Most importantly it would give the architect an opening to know the challenges the team is facing. These challenges / problems could be the spark for more significant architectural changes. Alternatively architect could intervene early to direct the team in case the problems are due to a mis-understanding of the requirement or technology. By assisting the team through these difficult tasks the Architect could also gain some trust and appreciation from the team members which is vital in the long run.

Code Review (of Architecturally significant pieces)
In general code reviews is a great way to intervene and understand what’s actually delivered by the team. But considering the various commitments an Architect might have, it’s important that only a selected set of code reviews are performed by the Architect. I think the selection should be driven by the Architect, to examine architecturally significant deliveries. An example is any framework code done in the early phases of the project. In-fact I’d prefer the Architect to write or at least heavily get involved in writing most of the framework code, let alone reviewing it. In addition to framework bits, some other significant areas could be integrations, complex business logic, high usage areas etc…It’s also important to let go certain areas of the code both for efficiency reasons and also to enhance the decision making and ownership of the team.

Pair programming
Similar to code review, pair programming is a great way for the architect to keep a close eye into any architectural feedback coming from the team. It also helps the team members to learn from a more experienced engineer. Even little things like development utilities and shortcut keys could assist the development of the junior team member. It can work the other way too, specially for a time poor architect, this is a good way to learn a few tricks of the trade from a developer.

In a large enough project, it’s inevitable that you need to some research and proof of concept work before you commit to a particular technology or method. An example would be to check which logging framework to use for the logging in your project, specially if there are specific requirements around logging in the project. Architects with their wider understanding of the projects’ landscape put together with their experience with different technologies and processes are ideal candidates to carry out these pieces of work commonly known as Spikes.

Some of the key technological and tool selections generally need to be backed up by a solid spike. As with everything else, this benefits both the project and the architect, not to mention the team members.
Tooling Research & Purchasing
I am firm believer of usage of proper tooling in any given software development project. Sometimes its unfortunate that some of our Enterprise clients don’t put enough emphasis on the tools, which can end up costing them thousands of dollars of programmer time and rework. One thing I’ve noticed is that when the source of a tool request is a developer, the chance of approval diminishes. But a knowledgeable architect can do these things and own a tool request or an upgrade. Not only an architect can really justify the availability of a tool among team members, he/she is in a much better position to justify the purchase of a tool to a customer as well.

By being engaged in this kind of productive role towards the team, makes the Architect a popular figure among the team - one of our own -, a key requirement for a healthy working relationship between the development team and higher ranks in the company.

Process Improvements
Since Architects are not fully engaged in the day to day activities of a project, once it goes into full swing, he/she is in a great position to provide valuable feedback re: the software development process. For one this architect should be able to convert daily practices into more measurable heuristics on which decisions can be taken. A good understanding of current trends in software development practices as well as hands on experience on delivering software are key to understanding the (sometimes implicit) process quirks within a team and modelling them to known patterns.

This modelling is quite important, as that disconnects the actions of individuals or team, from the individuals themselves. When providing feedback to somewhat intangible aspects like ‘process’, the experience of architects can be drawn in to model the day to day activities into known software development process models.

In an Enterprise environments, software architects in general play a more strategic and advisory role. While appreciating the value of that, it’s imperative that software development teams also utilize architects to improve their capabilities around delivering working software.

An important shift in thinking about this is to engage the architect in one of many contributory roles. Not only these tasks will help the team to deliver software, it will help the team to understand the overall picture external to their delivery, will also help junior members to look up to senior members of the community and improve their skills. On the other hand it will also assist the architects themselves to get in touch with what’s happening in the industry at ground level and valuable project level feedback that could then be sent up in to the organization hierarchy.

Do your architects play a role in delivering software in your organisation? If so, what techniques do you use?
Post a Comment