Enterprise Integration & Web Services
Over the last couple of years, I spent a lot of time working with with EAI packages like Tibco and Vitria to integrate applications across the enterprise. The benefits are lucrative, but only if a large portion of the enterprise can be integrated on a common information bus. One of the largest issues is that each vendor has a proprietary solution that is being hailed as that common bus. Web Services promise to provide a standards-based approach to integration, but many of the features required for enterprise deployment are not part of the standards and again reside in proprietary extensions.
In my opinion, the most interesting part of Web services movement is the renewed focus on Service-Oriented Architectures (SOAs). While the concept is intriguing, a lot of hype overshadows many of the real issues to be resolved. My latest article on SOA tries to shed some light on this.

I started to collect a set of enterprise integration patterns. I found that many integration projects reuse a set of common patterns, but very little of this knowledge is available outside of EAI architect's heads. My paper on enterprise integration patterns was accepted to the PLoP 2002 conference. This has now become the basis for my book Enterprise Integration Patterns.

Application / Integration Servers
There is a huge amount of interest in .Net. I have seen a lot of die-hard J2EE developers convert. I need to spend a little more time on .Net.

It is interesting to observe the application / integration convergence. .Net is great example, Web Services-based integration is completely integrated into the development environment.

At last, we are seeing some better IDEs in the market. IntelliJ IDEA is the best Java IDE I have seen. It has many built-in refactorings. Eclipse is interesting as well as people start to add integration-related panels (e.g. visual XSL editors).

Cranking Code
If you haven't put a flame mail together yet for my views on the first few topics, maybe you are ready to hit the 'Send' button now. I firmly believe that an architect that has not sat down in front of an IDE for a long time is losing a significant portion of his or her effectiveness. I believe that a good architecture takes characteristics of the tools and languages into account. That's hard to do if you have never written a line of code. I do not deny that there are some very good architects who never code, but I have seen a lot more bad ones...

Software Development Processes
I am convinced that one of the key factors to successful software projects is the definition of a process that takes factors like technology, tools, staff experience into account. Too many people seem to rely on high-level, top-down 'methodologies' like RUP etc. Nothing bad about the RUP, I like many of their ideas, but it does not (and cannot) tell the project manager what to do next. Understanding the technology in detail, knowing the tools and their quirks (I guarantee there are some), understanding the solution architecture is the key to my task planning. My task plan resembles the architecture. Systems architecture is driven by dependencies and layers of abstraction. The same philosophy applies to the task plan. I believe that a good architecture is a key factor to a successful division of work, and a successful integration.
Currently, I am working with Martin Fowler on developing an agile approach to EAI projects (see our LOMA talk). My previous EAI 'Methodology' was built on top of ideas extracted from RUP as well as a series of books written by Gerald Weinberg.

Visualization of Technical Concepts
I spend a fair amount of my time creating presentations and drawing diagrams. While I am often dismissed as a "PowerPoint Jockey" or "Marchitect", I believe that the visual representation of architectures or dependencies is one of the most neglected areas in the field of software design and architecture. Using UML does not necessarily guarantee readability. Creating correct, meaningful and appealing diagrams remains a very difficult task. Maybe it is the combination of left and right-brain interaction that makes it so challenging.

Human Aspects of Software Development
My interest in this area really started when we read 'Peopleware' by DeMarco and Lister for the Technology Management class at Stanford (thanks to Prof. Tom Kosnik!). I agreed with almost every sentence in this well-written book. It is hard to believe how many project managers run a software project the same way they would run a meatpacking plant. Software development is still a maturing discipline compared to other engineering disciplines and human factors like developer experience and the working environment are the biggest determining factors to project productivity. Day in and day out I work in environments where people work in noisy cubicle environments where their days are interrupted by 'status meetings'. It seems like consultants end up at the bottom of the food chain when it comes to work space -- surprising when you consider that the client pays some $300 per hour for their services.