(Could this be flamebait - probably! But here goes anyway)
By Architect here I'm not talking Enterprise level folk who pretty much don't code much anyway - they're really IT strategists and don't need to apologize. I'm talking about the Architect for a small division or one team or a small number of teams not entire divisions of people with over 500+ developers.
Non-Coding Architects (NCAs) are also known as "Ivory Tower Architects" or "Astronaut Architects" or "Powerpoint Architects".
These NCA folks can be really quite dangerous and give dev teams a bad name - pretty much as any leader who really doesn't have the ability would hurt his organizaton. In addition, one general trait of NCAs that I've observed is their tendency to criticize the work of others to ensure the spotlight of accountability is off them. Either that or they can spew so many technical and complex terms that you're not really sure what they said - but the sounded smart so you're happy to have them on the team. Right?
The developers know these guys (or gals?) couldn't code their way out of a wet brown paper bag - the problem is no-one else can see this so typically the developers have to suffer through the bad design decisions that inevitably result.
But how can you spot one? For most developers it's pretty easy but just in case you can't I've compiled a list of example scenarios that should help - comparing the often dogmatic attitude of the NCA with the pragmatism of the experienced Coding Architect (CA).
Scenario: Need to map an object data model to the database
NCA: According to the J2EE spec we should be using Entity Beans.
CA: Entity beans are terrible - let's write our own DAOs or use Hibernate/iBatis/Toplink. Why do we need an App Server for this? Let's try to stay with J2SE.
The essential issue: J2EE Entity / Session beans were too slow and cumbersome for too long - you also need an app server (which cost mucho $$$$ if you go IBM/BEA). Why not use lighter frameworks such as Spring which will work pretty much anywhere? The NCA wants to adhere to the "spec" from Sun. The CA has been burned before and knows better.
Scenario: We need only one instance of an Class per JVM
NCA: Hey design patterns are cool - let's use a Singleton!
CA: How do I code thread-safe singletons in Java? How do I unit-test a Singleton? Let's try to avoid this if we can?
The essential issue: Design patterns are great - but sometimes the pattern is more trouble than it's worth. It's hard to code singletons right, especially for thread-safety. Also they're hard to unit test because singletons are stateful classes whereas unit tests should be as stateless as possible
Scenario: Users say our app is too slow
NCA: We need to create and perform a performance test suite across all our supported operating systems, and supported database platforms. We need to buy (insert your favorite expensive and unwieldy toolset here) and test all user workflows.
CA: I know where the bottleneck is because I live with the code daily - we keep loading the same static data over and over again. We'll do some analysis but at least this will get us most of the way.
The essential issue: These days you don't have the time! The first few performance improvements in a new application are usually easy to spot (if you work with the code daily). Some analysis though to verify your hypothesis is required though. Do those initial improvements first and then you can perform the full-blown analysis.
Scenario: Our CIO says we need to use SOA / Web Services now!
NCA: We should use the WS-* specifications
CA: You know the WS-* specs are still in development and somehow apps with Web Services and SOA are proceeding along fine - let's be careful about which standards we adopt and have a plan in place in case they change. Hey what's this REST thing? That's pretty simple!
The essential issue: Simplify, simplify, simplify! WS-* specs are just getting too heavyweight and are getting bogged down by vendors. Don't get locked in analysis paralysis or worse adopting so many WS-* standards your dev team needs 6 months of training before writing a line of code.
Scenario: We need logging in our application
NCA: We should use Commons Logger as our default logger
CA: Log4j gives you so much more useful functionality that gets abstracted away by Commons Logger - let's use that instead. Log4j's appenders are just soooo cool!
The essential issue: You log file is a very important artifact and you'll want to do different things with different parts of it (e.g. send emails on errors, log some stuff to the database, send something to a message queue etc.). Log4j lets you do that - but in most cases you need to use the XML configuration. Commons wrapper let's you use Log4J underneath but only with the log4j.properties files - you lose access to many of the cool appenders with pattern matching capabilities.
Scenario: Our J2EE vendor provides a useful non-standard set of functions - should we use them or write our own?
NCA: Let's make sure to write all our EJB code without hooking in to specific WebSphere/WebLogic etc. extensions. Let's stay vendor neutral. So let's write it ourselves!
CA: It would take us longer to write our own code to do this - so why not use the extensions and just ensure we wrap them in some facade / abstraction that doesn't leak anything container-specific.
The essential issue: Save time! Anyway, what are the odds you will switch J2EE app server vendors?
Scenario:We've got lots of code duplication
NCA: We need an AOP solution
CA: Just refactor!
The essential issue: AOP is cool - but do you have the time for your developers to learn about point-cuts etc. Anyway the problem isn't lacking AOP it's often laziness (or the absence of support for closures!)
Scenario: Architect is asked to speak to software developers
NCA: Use words such as "alignment", "leverage", "synergy", "the long tail", "thought leadership" and the latest buzzwords (SOA, Web 2.0, ESB).
CA: Use words such as "regression tests", "refactor", "reuse", "Keep it simple", "usability and easy of use"
The essential issue: Are you a managing up or managing down? Are you trying to be a Servant Leader and help your team whilst also helping management (they don't need that buzzword soup either)
Software Lifecycle phase - Requirements
Guess who is who here
"We need a full month of off-site JAD sessions to gather requirements" vs. "We need a paper/HTML prototype"
Software Lifecycle phase - Architecture
"We need UML diagrams for each class and interaction with Rational Rose" vs. "We just need to document key classes and flows - let's use Visio or StarUML"
Software Lifecycle phase - Design
"Let's do it this way" vs. "How should we do this?"
Software Lifecycle phase - Coding
"JDepend says your code needs to be more adaptable" vs. "JUnit says we need to fix some unit tests!"
Software Lifecycle phase - Testing
"Why did you do it that way?" vs. "How can I help?"
"Why is that broken?" vs. "You've got plenty of bugs on your plate. Let me fix that!"
"That keeps breaking? Why?" vs. "Yeah that's a troublesome piece of code - can we do any refactoring and perhaps add more unit tests"
I look forward to your comments and stories. I especially love the stories of Architects who really don't understand the technology and come up with the craziest ideas and the developers who save their asses (or not!).