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.
Some tips he offered were:
- DO make architects more like developers, even suggesting they could work with developers in pair-programming sessions on occasion.
- Do not make developers more like architects – it is important that both groups achieve the type of work they were hired to do.
- DO make developers understand the bigger pie – meaning to become more interested and aware of the stakeholders that use their software product.
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
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
be well-structured and well written, he continued,
"and only as formal as necessary."Atom and Spring frameworks mentioned
Gall pointed to some open source projects as examples of well structured specification documents. These samples included the IETF RFPs, as well as the Spring and Atom frameworks. APIs are the area of most concern, he said.
"The biggest piece of the pie, we believe, is APIs. When it comes to the interfaces between applications and the various services, that is where the most coordination has to happen," said Gall. But architects often give developers tools instead of true APIs, according to Gall.
The WS-* stack is "not an API, it is a tool kit," said Gall. So, developers go out and develop "stovepipe after stovepipe" -- applications that are not capable of being shared efficiently -- as opposed to developing an API that can be used over thousands of applications, he said.
"Handing the WS-* toolkit to a typical developer almost guarantees stovepiped interface design," Gall asserted.
Software framework for understanding
"We have not made the same progress in API design that we have made with UIs, "APIs still make people's heads explode most of the time. He noted one cloud computing organization that limited its API 'verbs' to a mere collection of 12 items. He contrasted that to organizations he has visited that have 1700 WSDL files on hand.
The APIs for frameworks such as Atom and OData show you how to design good APIs, he said.
Frameworks can be a means to help developers, suggested conference attendee Michael Kinstrey, but only if they are truly proven to be effective.
"Frameworks are a dime a dozen. The good ones are the ones that last," said Kinstrey, Computer Scientist at GE Global Research.
"A key to a successful framework," said Kinstrey, who, together with a colleague, has created a services framework for use at GE Global Research, "is that it is not forced upon team members."
"It is important that frameworks for development are not imposed on people, but are instead offered as an alternative way of doing things – so that people can discover it on their own," said Kinstrey.
This was first published in November 2010