Came across the above whilst surfing and just had to add my two cents worth.
I came across this post by Frank Kelly; clearly, his life has been made hell by what he calls the dreaded non-coding architect.
Therefore, I had to respond as the non-coding architect. I am going to follow the format put down by Frank because I think it is the best way to highlight some of the differences. Frank uses the annotation of NCA for non-coding architect and CA for coding architect, I am adding one myself, EA for experienced architect.
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.
The EA approach would be to consider the environment, including time constrains, available skills, the overall architectural strategy (what the organisation has done before that has worked and fitted with the way the businesses needs to operate). In addition, one would consider their own experiences for what they are, and arrive a preferred option.
All things being equal, I personally would go with simple and easy and write our own data access objects. Once I got buy-in to this approach or during the process, I would prototype of some interfaces and mock objects to demo how I thought we needed to implement.
Then down at pub on Friday night I am going to try to convert everyone to DB4O and after the five drink talk about evil things like how to bring RDBMS to their knees.
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
The EA approach again would be to consider what we are doing from a big picture point of view, asking questions like are we going to maintain the code, is that application mission critical or a little tool that is going to have a 1 year half life.
Assuming that we are going to live with this for years and that I have not shot myself in the foot with deadlines (getting better at this these days). I am going to go singleton, knowing that it will take extra investment now which I hope to earn back in later maintenance cycles, even if I am no longer at the organisation during those maintenance cycles.
But that is not where I am going to leave this issue, clearly folk are worried about the implementation of the singleton so I am ensure the project manager reallocates time to the task and I am going to get as hands on as I can, to help out.
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.
The EA approach is instincts plus benchmark. I don’t know about you guys but the times I have heard this comment I get a feeling in my stomach like I have had a bad curry, this is followed quickly by a flash back to the Tuesday afternoon when I made the call not parameterize and not to thread a certain package.
However, experience has taught me to stop and measure, understand what the user thinks is slow and define it. You will be amazed at the number of times there is a total mismatch between your gut and that the user is really talking about. Work out if this code issue or a UI issue.
Most importantly profile stuff, but not everything that executes, you know the stuff that could be problems, times when you have to reconstitute objects, opening connections, when you have been casting madly. The point is profile, refractor and optimize the really fat things areas where you can get a measurable result.
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.
The EA would had his or her CIO medicated early be right inside their head, so something like web services would not come out of the blue. He/she the architect would have already played around with the technology and would be aware of what others are doing out there.
He/she would understand that Web Services are about strategic integration of applications by the bar is still very low out there. Most folks that are going to consume your services are capable of doing stateless soap messages. Therefore WS-* are probably something we need to know able but probably a project for next year. Gold rule kiss, Keep it simple stupid.
REST is ok, but I would look initially to what we already know or have, if a .net house, then WCF (Yuck – personal opinion only) if Eclipse a work in the part. Not make which tool, get the contract done upfront, step out of the day-to-day and think from the perspective of the person who needs to consume the service.
Again, if you as the Architect have done a good job on the design, where the web service is going to plug into to your application is obvious, and you should have not cut across issues that things like security can bring up.
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.
The EA would say yes logging is key critical, and in fact, there should be a standardised approach over all applications.
Because I am, a bit twisted on this issue I would be pushing to build a logger that is flexible and fits with the way the organisation is going to do things. If not possible Log4j is cool, easy to use, but for the benefits a homemade system can deliver, I will be going to CTO to look for some dollars for a little internal project.
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?
The EA would say vendor lock in can be a problem but let us get real; it is an issue of degree. This is the type of issue where the architect really can come into play; he/she need to balance the upside with against lock in issue.
Often it is matter of selecting which of the extensions you are going to implement and how you are going to implement those extensions. Again, it is key to look at the environment, are you building an application for commercial resale, or is this an in house application (this can affect how likely the server need to be swapped out)
Bottom line, if you have great relationship with the vendor and their product is hot and it is any in-house app that you understand the life cycle off, then I would say leverage leverage leverage (notice the use of the architect word ‘leverage’) and use those puppies to make you life easier.
I would call myself a non-coding architect, more focused on the big pictures then the correct use of semaphores. Luckily, I have come from a strong coding background and can understand some problems a coder can face day to day.
However, I believe that if you call yourself a coder, you need to work towards being the best coder that you can be; you need to take a work document from an architect and bang it out in record time in the correct form, with test cases and adequate documentation. I am saying that if you code do that professionally.
As an architect I write code to test things, prototype against new API’s, demonstrate new methods for doing things, etc. This is in fact a some part of my job, a lot of my time is spent working out what to do and how to do it, and getting others ‘manager’ on the same page.
I believe that development without an architect is just as dangerous as installing a bad architect in a team. I can accept that there is some bad architects out there as there are some bad developers, what sets us apart from the non-professional amateur hacks is how we deal with them.
