I had the pleasure of attending two conferences in recent weeks – the Australian Architecture Forum in Melbourne, and JAOO in Sydney. Both conferences held some surprises and in particular I was struck by the very different attitudes toward SOA.
The Architecture Forum was of course aimed at IT Architects and as a result it was about SOA, SOA and SOA…with a bit of SOA as well. Even when you tried to not talk about SOA (as one bold presenter attempted)…the conversation still swung around to SOA. By contrast, at JAOO, there was nary a mention of SOA. You don’t have to look far to understand why…JAOO’s by-line is “by Developers for Developers”…so the target audience and attendees were – Developers. Hence much of the content was around languages, platforms and agile methodologies.
What I enjoyed most about JAOO was the chance to meet and talk with the great lineup of speakers. Kudos to Dave Thomas for wrangling these people to this unfashionable side of the planet. Among the highlights were: Gregor Hohpe talking about the challenges of distributed systems, Martin Fowler expounding on the virtues of simplicity in design, Jim Webber trying to reconcile his two loves in life and Steve Vinoski on how a portfolio of languages helps us develop better solutions. All of this gave me the opportunity to consider the perspectives of architects versus developers. Gregor Hohpe captured the tone with his statement that an “architects dream is often a developers nightmare”.
An Enterprise Architect is generally focussed on the larger components in the IT infrastructure – how they are owned, sourced, maintained, combined and deprecated. And an architect considers not only machines and software but also data, processes and organizational structure. A key consideration for architects is how these things work together and therefore standards are important.
Developers care about delivering solutions for a particular business requirement. They care about the languages and platforms and methodologies that support their needs for correctioness, quality and maintainability. Developers have evolved techniques to deliver these qualities which are sometimes at odds with the needs of Architects and associated standards. From a developers perspective, many of the web-services standards conflict with their best practices. For example, XML is not really a language and cannot be completely treated like a language. Source-code management systems often have difficulty with XML. XML-based “languages” such as WSDL and BPEL are so complex that they require visual interfaces and complex IDEs that are at a higher abstraction than the XML “code”. The ability of these visual interfaces to “diff”, “merge” and debug are often pretty poor. Recently there has been a welcome move away from the masses of XML configuration files in J2EE in favour of java annotations. And perhaps there is further value in domain specific languages like Integration Flow Language in project Fuji.
Architects and Developers are in a symbiotic relationship which is definitely not frictionless. A good understanding on both sides of the needs and drivers of the other party will help to get everyone working in the same direction. Each should know the languages, techniques and platforms used by the other and a common understanding will lead to better ways of achieving what is ultimately a common goal.
