Among the host of new challenges facing SOA and other development efforts are some that are, well, traditional. A prime example is the familiar communications gap between enterprise architects and development teams.

At the Application Architecture, Development & Integration Summit 2010 in Los Angeles, Calif., Gartner Analyst Nicholas Gall offered some practical advice for addressing this disconnect. He said that developers and architects appear to reside in separate worlds, but that architects need to be in touch with the real-world issues which confront developers as they deal with SOA.

The specification hand-off is an area to address, according to Gall. Today, the biggest thing architects do is "deliver specs," he maintained. "One of the problems is they are not user friendly," he continued.

"Developers are the architects' end users. [Architects] should do everything [they] can to delight users," he said. " Specification documents should be well-structured and well written, he continued, "and only as formal as necessary."

You lost me at "SOA"...

SOA stems from some notion that we should build all our modules and layers with the express goal of complete decoupling - the consumer should not have to know ANYTHING about the producer, the entire "protocol" MUST be specified by some ardous, verbose, illegible and often XML-based meta-data descriptor (I'm looking at you SOAP...). In reality, 99,9% of all systems does not need this decoupling and it just adds tons of unnecesarry complexity. The consumer and producer will always reside closeby, both in the architecture and in the codebase. A simple REST/JSON transport, heck even some pipe-delimited low-level TCP/IP contract would suffice.

In that context, a "SOA Enterprise Architect" becomes just about as useful as a chocolate kettle.

If all your architects are doing is producing SPECs to be consumed by the Developers - you are doing it wrong.  BY DEFAULT, doing so will cause the architects to appear as if in an ivory tower, their items will be naturally disconnected from what is really going on and the problems needing to be solved.  Picture Tecture / Ivory Tower never works, Architects should embed with teams and code...

+100 - I certainly hope the "deliver a spec" method continoues to be shown up as the rubbish methodology it is!

+100 - I certainly hope the "deliver a spec" method continoues to be shown up as the rubbish methodology it is!

 

depends on whats is in the "spec".

But most places I have seen there is a huge disconnect. 

The problem is on both sides  -

if the "spec" has detailed design with class diagrams, sequence diagrams and object interaction, data model, error handling etc then its a good spec by a good architect and everyone talks the same language. (UML hopefully).

A lot of times most of the enterprise architects ( some application software architects too) talk in high level "boxes" without any idea of technology or environment. How many architects can really write code ? very few. if they don't know how technology/software stack works they cant do good detailed design.  High level design is technology agnostic, but when it comes to working with developers with "detailed SPEC", architects need to know the technology stack in detail. 

On the other side lot of times developers dont think beyond their "current project". thats #1 issue. Somehow get things shoved to production is their goal.  How many developers understand UML ? how many can even tell difference between a dotted line and a solid line from one class  to another?

Also how many do test driven coding and write tests ? how may really try to understand problem before writing code ? its mostly write code first and design will follow  :). 

So bottom line - architects come down to code level so you know what a developer has to work with and developers please go over architect's design & understand why its done that way before starting to code, think beyond one class and one project - think long term good design.

Hopefully one day they will understand each other :).