Problem : Architects and Project Delivery Folks do not see eye to eye.

This is true at times because of the reason that they have different mandates and see the process of software creation / management and delivery as a separate entity. The architects want everything to be done with a view that supports strong rational and creates a scalable , flexible and extensible architecture, clean code along with a strong sense of quality of attributes and extra architecturally important aspects. Whereas delivery folks are more inclined to meet the product delivery deadlines with reasonable quality adherence to the delivery. Delivery can gravitate towards get the job done and meet the timeliness with delivery pressure. They naturally push towards time and money as influencing their decisions and not so much on practices such as clean code, re factoring , loosely coupled architecture , services/interfaces, packaging , modularity. All of this is expected to be inherent in the architecture design churned out by the architecture team. These quality attributes of the architecture such as ease of user experience, scalability , robustness, long term flexibility of the system etc are things that an architect ponders and packaging all of this in a time period is the worry of the delivery people. So as is seen these two goals although they look quite contrary are really needed to work like the wheels of a bullock cart to pull through the bulwark of the delivery machinery. If you were to measure the two teams on same parameters it would create conflicts.

With agility thrown in good measure in projects , everyone on the team is expected to be an architect more or less. But this does not really work in reality as being an architect requires specialized skills and not easy done. But with just enough design and architecture that is continually evolving they say do what derives immediate value to the project or solution. Traditionally the role of an architect is not directly focused on the delivery and more so on direct revenues. The delivery folks can claim we did the real work and hence we are more responsible for direct revenues for the company. The architect community can say we are the ones who are responsible for all the design and blueprints for you delivery folks to go ahead and execute it. Also that all of your application code runs on our backbone platform layer /infrastructure layer and hence we are ones who move the Earth. Either way this debate serves no purpose to anyone involved. This is like the heart saying I am more important than the head etc. Both need to exist for things to work.

Have come across situations in former companies where there were separate teams for the both departments and when it worked well. Also there were instances when delivery folks were seeing doing all the work and taking the credit for. This at times forced architecture folks also to say that we need to have delivery responsibility for our pieces. Anyways all said and done architecture and delivery units needs to be accountable for its operations.

Organization Maturity : It works for some companies to keep them separate

There are companies that do a good job of both Strategy at the conceptual level and also the delivery when it comes to the nuts and bolts. These companies have a strong architectural practice and have reached a certain level of maturity with regard to their people and process.

Keeping these units separate ensures that each work for their independent part contributing to the whole. This requires that the architecture folks are not burdened with delivery pressures which are unreasonable and same with delivery folks not being pushed to climb the wall whenever there is a client delivery. If things are planned well with scope for 11th hour changes and the separation of duties and roles clearly defined then each team can be a proud owner of the aha moment in the teams when their pieces fit together with the overall piece and function together as one.

Companies that have a well defined architecture function in them and know well how to articulate and see for themselves the value of keeping these two departments separate. Teams where they are misaligned can work counterproductive to the organization vision and not achieve the same results of teams in tandem.

Setup the units to work in tandem and for the organization vision and not against other.

 Who reports to whom and where is the common ground for these two teams.

There are instances where an Architect’s services are used by a manager in meeting project deliverable’s. Also an Architect can leverage on the project manager to get quality deliverables by seeking the managers help in executing the project as per the plan.

Have seen both these units working alongside and reporting to the product/solution unit head or in some cases being run as part of one unified team without formal separation. Here again these are prescriptions and we can use what suits best for a given situation and the context of the company that is setting up an architectural practice. Architecture team is accountable for the architecture pieces and the engineering teams are responsible for the engineering functions. As long they work together mutually leveraging on each other’s key capabilities this will be a good working model.

Blurring the Lines : Getting all involved in the process of software delivery

Fundamentally everything that we do is ensure we run our business well and architecture is an auxiliary unit along with other units which have to work in tandem to ensure continued success of the unit as a whole. At times we can have engineering and architecture being seen as main units and each having a target to achieve . Engineering may need to ensure that the work that is churned out by the team is of the highest quality and flawless and that it ensures customer delight.  For the sake of discussion lets us leave out the other sub functions such as support , QA , various PMO functions all of which go into engineering as an overall practice and keep it that way. So this being the case engineering most often gets to get a feel for how the project is rolled out as they are close to the implementation arm of the company. Of course  professional services team will have a better feel for how the project is structured during rollouts. On the whole when the architecture is not closely involved with the delivery aspects unless there are some show stoppers or implementation glitches it is easy for them to be isolated from when software meets the road or goes live. It is quite natural for some units to end up working in silos and as disconnected entities. The ideal way to run them is to allow one and all to get the overall organizational big picture and get the people motivated to work towards that. This would help all people pulling in the same direction.

Running an Architecture practice as a revenue unit.

At times architecture divisions are run like Research and Development units without a direct revenue accountability. It is difficult to attach value to innovation best example is that of twitter which is estimated to market capital in billions but is yet to monetize on its key capabilities. Also the case of whatsapp where the actual revenues are not as much as what it got bought out to by Facebook. But the fact that a certain innovation or practice and potentially is of huge value and needs nurturing and careful support from the management before actual / real value starts to show up in monetary terms. As long as there is an innovation culture on the team on all fronts attaching a revenue value to architecture can be counterproductive. But you can have soft targets which enable engineering teams to combine engineering efforts coupled with architecture add-ons which then bring out enhanced product experience and a customer that is hooked onto your product or solution. Directly attaching a monetary value may not be possible as these parameters are subjective .

There are instances of companies where architecture practices are run like revenue units where they are accountable for bringing home and driving projects end to end. Here architecture teams are entrusted with the twin job of architecting and being involved in the day to day activities of the group as well. In fact Research and Development units are measured based on their thought leadership, papers published at industry seminars and traction generated , key research findings, IP monetization and how many projects were executed and how many deals clinched and what revenues benefits are there based on the research activities. So keeping the end goal in mind helps the organization to work towards one.

Solution avoid silos : Some best practices for creating good cohesion between architecture and delivery teams

a)It is therefore a good practice to have members of the architecture team and delivery units on common group mailing lists when the engineering activities are being planned from start to finish. This gives the stakeholders of both the teams to partake in the whole process of delivering software as one unit.

b)Have a common portal share point or any such mechanism where all concerned have access to know what is happening in and around the delivery units.

c) Have a common group mail list which circulates information to all stakeholders. People actionable to be specifically mentioned in the “to section” and the ones in the “cc section” it will be for your information purposes only. For example an core engineering function would have engineering member in the to list others in cc and vice versa.

d) Invite  stakeholders from all concerned in the final delivery for all meeting that are of  interest to all and who have a say and influence in the matter.

e) Collect review comments from people if not able to make it to the meeting directly.

f) Have a job rotation policy of people from architecture and delivery for the ones  interested and look forward for an all rounded experience. People from both teams get a well rounded experience.

g) Invite customers and have members from both team hear from  the customer pain points directly instead of a customer facing team informing the teams on the issues. Organize customer meet-ups and regular interactions and action on the points arrived at by prioritizing based on a timeline

h) Have and organize tech talks regularly and encourage knowledge exchange regularly between the teams.

i) Share Reward and Recognition appropriately

There have been instances where the architecture teams worked towards creation the platform and the infrastructure portions and the delivery teams get the credit for doing a good job of the delivery or brick bats for a sloppy delivery if things go wrong. The other way around architecture develops a framework and becomes quite popular and solves most customer pain points and gets rewarded. But delivery teams associated with the framework are left behind.

But by having all concerned on the same page these things can be avoided and no single team entirely gets the credit or blame for the same if things were to fall apart. There is popular thing that works most often in management which says that if you want a job well done then do it without having the credit factor to it , a job well done itself is the reward. It can be done well when there is no inclination from either teams to clamor for the credit for having done it well. At the end of the activity the team as a whole gets to howl and party this way all the key stakeholders from all team concerned gets to celebrate success.