How to spot the dreaded non-coding architect
(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!).
Labels: Career, design, Software, Software Architect
posted by Frank Kelly at 8:09 PM
View blog reactions
29 Comments:
really funny!!
6/30/2007 1:41 AM
Great post, Frank....
I think you have nailed one anti-pattern for architects: the Buzzword Architect.
I wonder if there are others?
This has real potential (a la light bulb jokes).
Scenario: Need to map an object data model to the database
The Technophile Architect says that the double schema problem is too heavy, so let's just use an OODB that has a customer base of 2 sites, one of which is a Mom of the startup.
The Senior, Megalomaniac Architect says that he wrote a DB for IBM in the 1960s and that we can just do it again. It will be better than a bloated, general solution like "Oracle".
The "Resume-Driven Design" Architect says that they will store data via Active Records on a Ruby on Rails app, and then expose the DB layer as via .NET using a thin adapter layer in C#.
and so it goes....
6/30/2007 2:34 PM
Yee-ouch!!
I'm not officially an architect, but I am a contributor on our architecture team... And several of your (anti-pattern) points exactly match some of the things I've said in recent weeks...
Thanks for the reality check... I'm going to reflect on your suggestions and see if my position changes on any specific points.
6/30/2007 10:56 PM
This is is dead-on. I was once on a project where the so-called "architect" had no clue what she was doing, she just churned out reams of incoherent UML diagrams that would not even produce a working system if someone could figure out how to implement it in code. Oh, and all data access was through entity EJBs. I bailed on that project at the earliest opportunity, and the project was scuttled about 4 months later.
7/01/2007 11:38 PM
Great post!
I met a lot of such Architect and almost all of them were telling me something from your list.
7/02/2007 8:39 AM
I work for a team where the management appointed "architect" has no development experience what so ever. So he does not actually do architecture at all.
7/02/2007 11:13 AM
Dude -- you are lucky that your architect even knows what an EJB is, or UML for that matter (besides Use Case diagrams). Most "architects" I've met are customer-facing salesmen for COTS products.
7/02/2007 11:55 AM
Rather than any kind of argument against or for a NCA seems like just a soapbox article for giving your opinion on various technologies.
too bad might have been interesting instead it's just another one-sided opinionated rant (like I'm sure a NCA would offer, coincidence?).
7/03/2007 12:34 AM
I agree with you about the non-coding architects but the EJB/Spring conversation is a sore spot for me. In the hands of a white-paper architect versus an experienced coder the discussion turns into an impossible to follow Coke-Vs-Pepsi comparison about the abstract nature of the tool while the problem being solved is completely lost.
For any architectural conversation, it's the context you have to understand - do I need a car or do I need a bicycle? Well, it depends on what you're doing with it. I think that's what you're objecting to about WPAs - they design buildings without considering anything else - who uses it, materials on hand, the natural landscape, costs, delivery schedules, etc.
Well, I'd say that NCAs will deliver something all right - the problem is that they tend to deliver first and plan later, always thinking incrementally. Sounds good but in practice it means their only toolkit for solving problems is the IDE. The app is too slow? Let's code up some tests in Eclipse. The DB model is fubared? Wipe a little Ajax on it from Eclipse and add an abstraction layer to put the data manipulation load on the browser.
Give a CA/CA wannabe CVS access and what you get is a bunch of busy beavers playing Jenga with your application, piling on code to fix tiny little tactical problems without the 50,000 foot view and in the process they create a great big strategic problem that makes ripe pickings for the salesman-posing-as-SME referred to by the earlier commenter.
my .02. Maybe I'm just not RAD enough.
7/03/2007 12:46 AM
"CA: I know where the bottleneck is because I live with the code daily "
Absolute rubbish. Measure. Don't guess.
7/03/2007 3:54 AM
CCA - Chief Coding Architect: It is incorrect that log4j xml configuration can't be used with commons logging.
7/03/2007 9:02 AM
To anonymous who said "Rather than any kind of argument against or for a NCA seems like just a soapbox article for giving your opinion on various technologies."
This isn't based on just some willy-nilly opinion as much as the cold hard realities of successful and failed projects I've experienced as a developer.
Where the NCA's make the large bulk of their mistakes *IS* on the technologies and really it's about being dogmatic vs. pragmatic.
I'm not sure I get your point about being "one-sided" - the entry was meant to be one-sided.
-Frank
7/03/2007 9:39 AM
To anonymous who said "CA: I know where the bottleneck is because I live with the code daily
Absolute rubbish. Measure. Don't guess.".
I did say right after that "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.".
So I agree analysis is important but if your an architect who is in the code most of the day - you should be fired if you're not aware of some of the key bottlenecks before your users spot the issue.
If you need to do major analysis to find the first few bottlenecks you're too far removed from the code or really don't understand what you are architecting.
7/03/2007 9:44 AM
To baker who wrote "CCA - Chief Coding Architect: It is incorrect that log4j xml configuration can't be used with commons logging."
Please please please tell me how!
Here's the last I knew
Commons Logging Link
Some other people seem to have hit the same issue link1
and link2
Hopefully you can set me straight!
-Frank
7/03/2007 10:17 AM
"Please please please tell me how!
Here's the last I knew"
I followed the link that follows and it says:
"Configuration of the behavior of the JCL ultimately depends upon the logging toolkit being used. Please consult the documentation for the chosen logging system."
which to me says "use the log4j configs". Did I not read that right?
7/03/2007 11:05 AM
Really cool post.
Read this through trying to ask myself, which group, I personally fall into. Thanks for this reality check.
7/03/2007 11:06 AM
Nice post! It was interesting to read through your arguments and remember all those different times when projects went "sour" due to the lack of vision/thought on behalf of the architect.
7/03/2007 2:00 PM
I think yo make some very valid points....although you tend to throw the baby out with the bath water. Some tools are better for some problems. EJB has its place as do the WS* standards.
I have coded the 'standard' way and alternate ways. Both can be equally jacked up. As an architect for a coulple of places and now doing a strictly developer role, I see both sides. Some times its good to have a basic set of standards in your org. Further I have worked for IBM. They are a good bunch. They were doing Spring before it was fashionable.....Again different tools solve different problems. Knowing when to use and how to map them might be the better definition of a 'good' CA.
Hell, I wrote some awk scripts a while back, because it was the simplest way to get the job done *at the time* for *that problem*.
7/03/2007 2:49 PM
The responses are a case in point why Architects should not be coding. Coders are too tied to the technology, and have their biases. Wouldn't touch .NET while I was coding, but quite happy to use it in a solution now. When you are too close to the technology there is no long-term vision and the focus is on getting the problem solved as simply and quickly as possible.
I used to be a damn good coder - but don't need to prove that to anyone anymore.
7/04/2007 7:17 PM
Architecture is about enabling business capabilities, and software architects make artifacts that bring different view points to meet the business requirements identified earlier at a high level. I don't understand the distinction/ classification of Architects. From the description, if seems like CA is actually a developer / Software Engineer role. No doubt, Architect role is a tough role that interfaces with the Businesses and Software Developers/ Technical Leads.
7/05/2007 6:49 PM
To anonymous who said "Architecture is about enabling business capabilities, and software architects make artifacts that bring different view points to meet the business requirements identified earlier at a high level"
Yes architects enable business capabilities but so do developers, project managers and business analysts.
What the software architect is tasked to do is to be responsible for "all things technical".
What exactly does that mean? I suggest you take a look at this entry What is Software Architecture and this entry on What it means to be a Software architect and please take a look at some of the references in this entry What it takes to be a great Software Architect.
In the cited IBM link the author, a senior IBM architect says off-the-bat "First and foremost, the architect is a technical leader, which means that, as well as having technical skills, the architect exhibits leadership qualities."
Enterprise architects tend to operate in the space you mentioned but the software architect (down a the team-level) bears the ultimate burden and responsibility for the technology aspects which frankly the business shouldn't have to care about except insofar as it is (as you said) an enabler.
7/06/2007 9:55 AM
The reason many of the points on this post are true is because the new-age architects are usually people who don't want to code.
In the past, the ones who didn't want to code, became coder-manager - i.e. Project managers. Nowadays - they try to stay more *technical* and become architects.
And many of the things you mentioned - trying to glorify other's mistakes so theirs would stay under the radar - are really accurate.
I have also found that they are really good salesman and can pretty much sell hair-brushes to bald guys. Another known trait is cowboy mentality of shooting from the hip...
7/06/2007 10:41 AM
Enterprise architects tend to operate in the space you mentioned but the software architect (down a the team-level) bears the ultimate burden and responsibility for the technology aspects which frankly the business shouldn't have to care about except insofar as it is (as you said) an enabler.
True.. however Enterprise Architects are accountable for the high-level technology decisions. From personal experience, it is very hard to keep up with technology while developing the other skills and knowledge needed to be a good Enterprise Architect. It is a tricky situation - some of the scenarios you mentioned can happen when EAs try to do technical architecture at a lower level than necessary.
7/06/2007 11:35 PM
Hmmmm I agree "Enterprise Architects" are in a very tricky position that is highly dependent on what the organization thinks they could/should do.
Just take a look at a recent entry about a Job ad I saw for a CTO who still needs to do coding!!!
Best,
-Frank
7/07/2007 5:23 AM
Or as I say in 9 ways to turn SW projects into mud, if you've got people determined on solving everything with squares, circles and dashes, get them ready for a long and prosperous burger-flipping career at MacDonalds... ;)
.t
7/07/2007 11:35 AM
I tend to agree with your article. I actually see two categorizations of non-coding architects. There are the business analysts turned architect because of their years with a company/industry, and there are the non-coding architects who have been separated from coding over the years because of added responsibilities (in other words, they are in meetings all of the time). I find the first type would be more inclined to run into the anti-patterns you mentioned. The second type seems to be more practical when architecting and although they may sometimes run into issues, they are usually able to ask the right questions (the key in my mind to being a good architect). I also find the second type has more trust in the opinions and statements of senior developers, while the first type tends to do architecture by magazine and not even garner the opinions of developers. If I had to pick a non-coding architect, I would take the second type.
That being said, I have seen issues with coding architects. Things that should be simple tend to get blown out of proportion for a multitude of reasons. Either there is a battle of wills, or past experience comes in to play. Also, not all coding architects trust developers. The coding architect can become very selfish believing they are always right or that if they don’t do it, it will never be done the right way.
7/11/2007 11:42 AM
This is so true! I'm working with an architect at the moment who last wrote C stuff on DOS back in the early 90's which was even out of date then.
Next thing he's an architect at a financial org and knows all about WCF/WS-*/SaaS distributed apps etc and hasn't written a line of code whereas I've lead a team delivering MASSIVE apps (10000+ concurrent web clients) and this current app is much smaller scale.
11/15/2007 4:35 AM
I work for one of the regional banks in NSW (sydney). We have an Enterprise Architecture team, where the top level executives (EAs) have narrow focus in the sense that they seem to be IBM mainframe centric and pro IBM and think that the target architecture should be J2EE and DB2. They seem to be deliberately anti Bill Gates / Microsoft and hence won't allow developers to even experiment with some of the new stuff in the microsoft world, such as vs2005/8 ..They talk about open systems, but are pro ibm. The developers have to put up with heavy weight websphere and unfriendly DB2 crap for some of the new applications, while there are numerous existing applications which are working very well in old Microsoft tech (old visual studio version 6 prior to .NET), but we are not allowed to upgrade to new versions of .NET. The business is not willing to put up millions to re-write everything in j2ee, but the architecture keeps trumpeting the same message of J2EE target architecture. The EAs are too much technology focused, rigid and restrictive...The developers are not even allowed to experiment with some of the newer technologies of either microsoft or other techs like ROR etc. This is a pathetic situation...
The EAs should be more concerned with generating and providing valuable business solutions and aligning, generating value, providing risk, resource and human capital management...essentially more on IT governance...
They should leave the developers and Project delivery managers alone to give them some stake in the ground, to choose the type of technology they see fit for a new idea/service or release, ofcourse, in line with broad and flexible guidelines of strategic technology direcions from EAs. In other words, the EAs should not be too rigid and dictating...and the developers and PMs should have some say in choosing the technologies as appropriate...
I would like to see some comments from some passionate, objective and impartial developers and architects ....
11/19/2007 4:26 AM
There is nothing wrong with Singletons. There is one thing worse than someone who espouses using Design Patterns and that is someone who espouses not using them. Singletons work, they work in multi-threaded environments and they are easy to code. You are showing your own prejudices in this article.
8/18/2009 9:04 AM
Post a Comment
Links to this post:
Create a Link
<< Home