How Should EA Work With App Delivery To Remain Relevant?

I visited a client recently, a large company with global operations and a large application delivery organization. A senior VP in charge of a large part of that organization told me an interesting story about its experience with a change in the way it approaches EA over the past few years. In brief, he said:

  • “A few years ago our architects were mostly dispersed into various parts of the delivery organization; we didn’t have an EA group.
  • “Then we recognized that we needed an EA group to better manage our use of technology, so we pulled those people out of delivery and formed them into an EA group.
  • “Since then EA has spent a lot of time understanding our business, building capability maps, and focusing on a more strategic level.
  • “But now I’m hearing cries of anguish from the delivery teams that they don’t have enough direct engagement and support from the architects in their delivery efforts. The delivery teams are concerned that EA has moved too far away from the actual delivery of business value, that EAs are not helping enough, and that it’s harming the effectiveness of the delivery organization.”

This leader lamented that it seemed that the strategic focus of EA has delivered a lot of models, the value of which is not evident to some in the delivery organization. Furthermore, some of the architects are just itching to get back into delivery, so they can work with their old buddies and do something more tangible. He asked – “what should we be doing?”

I opined that if it was up to me, I’d establish a rotation for some of the architects, those that have the capability and the inclination to help delivery teams (mostly application architects and middleware experts, I expect) so that they periodically spend time assigned to critical delivery efforts, for perhaps six or even twelve months at a time. I recommended that the architects join the teams in a way that they would “roll up their sleeves, working side by side adding value, helping deliver better outcomes.” Meaning, not just reviewing stuff but doing actual architecture and design work.

Then, after this “delivery rotation,” those architects would return to the central EA group, better informed about what’s going on in the real world, the architectural challenges being faced on critical delivery efforts, and with knowledge they can turn into reusable architecture assets like design patterns.

Our client found this advice very interesting. So much so that he arranged a follow-up inquiry with Randy Heffner. The call happened a couple of days later, and Randy brought in a perspective of architecture governance processes as a means to simultaneously achieve deeper developer-EA collaboration and stronger architectures. In his research on SOA governance, Randy has seen specific mechanisms like project architecture reviews, service portfolio management, service interface design reviews, and service implementation patterns drive higher satisfaction with SOA and better project results. Building similar processes, together with a collaborative culture (as opposed to “aloof architects”), into the broader context of architecture governance (of which SOA governance is a subset) can bring similar results.

What have you experienced in your shop? How do you keep your architects plugged into delivery without taking the wind out of the sails for EA? Or do you even have this issue?