At the Enterprise Architecture Conference (EAC) this week in New Orleans, as I stated in my last posting. So, what are the trends here? Not a whole lot other than the fact that the traditional EA tools are continuing to move towards SOA, and they do indeed bring some value. The fact is that SOA technology, typically development, integration, and governance tools, have charged way ahead of the approaches and meth At the Enterprise Architecture Conference (EAC) this week in New Orleans, as I stated in my last posting. So, what are the trends here? Not a whole lot other than the fact that the traditional EA tools are continuing to move towards SOA, and they do indeed bring some value. The fact is that SOA technology, typically development, integration, and governance tools, have charged way ahead of the approaches and methods that people need to leverage to get their SOA working for their enterprise. Thus, the hype has been leading the new SOA technology, and the new SOA technology has been leading any notion of common methodology, architecture, and design tools. However, in the world of EA, architecture and design tools have been around for a while, typically coming up from the days of CASE technology gone by. These tools do a few things, typically allowing the architect to create and manage artifacts for the architecture and design process, leveraging a shared repository. The trouble is that the artifacts they were managing in the world of “old EA” (not my term, by the way) had little to do with the changing concepts that SOA brought to the table. In other words, you need a new approach to account for the differences. However, all of that seems to be changing. Clearly, a trend at this conference is that the architecture and design tool vendors that lived in the world of traditional enterprise architecture, have moved, or are moving into the world of SOA. These tools include Telogic, Troux Technologies, and Agilense, at this conference. I’m sure there are a few more. So, what’s new? Not a whole lot at this point, however they are looking at the SOA model and artifacts that would be valuable within the world of SOA design automation infrastructure. This means service level understanding of the architecture, and binding to metadata, etc.. However, I did not get the feeling that this is comfortable territory for most of these guys, in other words it’s going to be learning process. At the end of the day, this technology could be as important, or more important, than ESB, governance tools, and orchestration engines. None of that technology is worth a damm without a good set of requirements, architecture, and service level design. We need to begin to focus more on approaches, best practices, and methodologies, and the tools that can make that manageable. Software Development