I got to thinking recently, “what makes a software architect a software architect?”  With that thought I then delved into the various degrees and ideas about what differentiates an architect from a senior developer.  With even more thought I pondered what breaks up architects, where are the separations within the description itself?  While out eating and enjoying a bit of beverage atop the 26th floor of the Sheraton in Tacoma a few coworkers an myself assisted me in furthering my thoughts.  Are there ways to draw borders around a program software architect versus an enterprise architect versus a business technology architect?  Are these even legitimate separations?

I’m going to, for the context of this blog entry, attempt some definitions and maybe even declare some specific “architect” guidelines.  So far I can think of several descriptive adjectives that software architects would fit into;  business, enterprise, and program.  What definitions these would probably have would be somewhere along the following initial rough drafts listed.  Of course keep in mind my actual adjective use is in “draft mode” also!

Business Architect :: A Business Architect would define a resource (contractor, full time employee, or other) that has specialized abilities to define, at an executive level, what tools would work well together to accomplish a business goal.  This person would also know how to get the best use, return on investment, and minimal amount of implementation burden with maximum usefulness of the software to the core business itself.  This person would know what parts of the Java, Web, .NET, or other technology ”world” would fit together for a particular business.  This person would see how executive decisions are made, how open or closed source would be best for the business interests, and how these people expect the software to work within their respective business environments.  This architect should be familiar with management methodologies that their suggested software implementations would interface with best during the software development lifecycle.  This architect would most likely work in or come from a small business or fast moving business environment of a few people (3 or more) to a few thousand (1-9 thousand) people.

Enterprise Architect :: A Enterprise Architect would define a resource (contractor, full time employee, or other, in a enterprise usually a full time employee) that has specialized abilities to define at a large scale what a design should look like for a particular corporate environment.  This individual would not particular know management implementation methodologies but would know how to integrate disparate technologies with the highest return and the lowest over head or cost to business flow.  This person would not be particular concerned with the executive attitudes as the primary concern is increased consistency of patterns, methodologies, and repeatable design and development efforts.  This person would understand application design scope within a department, multiple departments, and outside vendors and how these concerns will integrate with the design.  This architect would most likely work in or come from a mid-size to large corporate environment ranging from several thousand (5-10 thousand) to the hundreds of thousands (100-200 thousand) people.

Program Architect :: A Program Architect (or Application Architect) would define a resource (contractor, full time employee, or other, in a Program Architect role usually a contractor) that has specialized abilities to define a small, medium, or large scale application for a medium size business.  This person would know primarily how all layers, servers, and tools used for the application would integrate into an existing business or enterprise environment.  This architect level would be almost 100% technical and not concerned with the business itself so much or the executive attitudes or methodologies.  Of course some concern may be important but the primary focus would be the tools, servers, layers, and integrations.  This architect would most likely work in or come from a small or mid-size to large corporate environment having spent several years contracting and be familiar with a wide range of software servers, tools, development environments, etc.  Generally this architect should be familiar with small (3+) businesses to large corporate environments with thousands (100-200 thousand) people.

This is my initial outline.  If you have anything to add PLEASE comment.  I’d really like to further the details or even break things out into more specific categories and really get to the core of what makes up a real software architect role.

del.icio.us Tags: Enterprise Library, Enterprise Architect, Software Architect, Program Architect, Business Architect, .NET, DOTNET, Java, Contractor

Technorati Tags: Enterprise Library, Enterprise Architect, Software Architect, Program Architect, Business Architect, .NET, DOTNET, Java, Contractor

Many people find Generics confusing.  I hope that I can add to some confusion reduction with a quick demonstration of some standard Generics usages in the C# .NET 2.0 world.

The type-safety of C# prevents potential errors by catching them at compile time.  Every variable in C# has a defined type.  When you give the object an assignment the compiler checks if it the action is a valid.  If the assignment isn’t valid, BOOM, you get a notification.

Now a major problem comes up when you try to use collections in pre-generics C#.  The collection objects in C# are typed to hold actual .NET Framework objects.  Since anything goes in, there is no way to provide type checking.  Compounding this situation is the fact that each object getting pulled out of the collection then needs to be cast.  This creates some nasty, bloated looking code, especially once you start churning out all the collections themselves.

So today’s tip is simply to remember that generics are your friend!  No more nasty ole’ pre-C# 2.0 collections.  Generics, generics, generics!  To check out more about Generics, get the low down, and see how generics are utilized in .NET Framework for reflection, arrays, collections, serialization, and even remoting check out Microsoft‘s MSDN Section on Generics.  For more information specifically on what a generic check out this particular MSDN page.

So I was, as I do every week, just looking through the job postings to see the types of things that are posting, what percentages of jobs are out there, and what the rates are.  It is, as a consultant, very important to keep up with all those things.  The reasons range from assuring that I’m not falling behind with technology to seeing who and where pressure is coming from for the project and company that I am currently working for.

Every once in a while I still see these postings that are morbidly outdated and out of touch with reality.  It’s almost as if Paris Hilton is out there writing these job descriptions and setting the rates!  I personally am offended to see anyone or any company out there asking for a “Senior” anything software related for $30 bucks an hour.  Now don’t get me wrong or out of context.  $30 is a good rate for a lot of developers out there, but for a senior .NET engineer or senior Java engineer is ridiculous.  The current rates in market for an average Senior .NET or Java Engineer is about $40-$47 bucks an hour.  For a company that is serious about longevity, peak performers, and concerned about getting the best of the best, the rates skip up to at least $55-60 an hour.

So to all those guys out in the field looking for work, if there are any left at this particular junction in the industry, don’t accept low ball rates.  It does you and the rest of us bad and sets the perception of managers and other artificially low, because I guarantee the movers and industry experts aren’t going roll over for these low ball amounts.  If you’re faced with this dilemma at this time in the industry please shoot me an e-mail and lets talk, I’m sure I can roll you into one of the friendly and competent recruiters that I know, who I know hire appropriately, scope well, and present honorable and good rates.

Every year there are literally dozens, hundreds, possibly even thousands of software projects that fail.  The projects that fail range in scope and price.  Project efforts of a few hundred dollars to the behemoth project of tens or hundreds of millions of dollars.  These projects follow known problematic approaches that are outlined extensively with anti-patterns and other various books about things like the software development Death March.

There is one underlying concept that is lacking in project failure; there is no agility to the process.  It’s to rigorous, to whatever.  The really awesome and downright cool thing about software development is that IT DOES NOT HAVE TO BE THIS WAY!  I was just reminiscing about one of my past jobs that was saved from its death march status of sick anti-patterns.  The solitary agile method used was postponing, not even on purpose, the actual method for application deployment.  The amazing thing is that it all started from a last minute disappearance of money.

I was working at a particular consulting entity called PSI Net Consulting Solutions.  They had been working on the MACWIS Project for the Mississippi Department of Human Services.  The project was horribly behind, all types of things had slipped, but because of budget cuts and quick thinking on the part of the project workers some streamlined usage of Citrix and other tools where used at the last minute to save hundreds of thousands of dollars and finally get the application deployed.  This Government project was brought home for me recently while beginning to read the book “Lead Software Development – An Agile Toolkit”.  In the introduction of the book a speech is mentioned where Jim Johnson, chairman of the Standish Group told about how Florida and Minnesota developed their respective WIS (Welfare Information Systems) and how one state got it right and the other went through a horrible non-agile, very un-lean approach.  The difference being a 200:1 improvement.  One project lasted well past 10 years and exceeded 230 million dollars, the other cost 1.1 million and lasted a little longer than a year.

The basics of this post is that no matter how proven lean process, elimination of waste, and other methods are, they still get ignored.  But I must move away from this topic for just a minute and drive home another, far more important point.  Even though there is so much attention paid to process, to control, to the “method”, the fact of the matter is it all boils down to the team, the individuals and their respective abilities and the ability of management to line those people up with their strengths.  Sometimes people don’t have particular strength and they need moved out of the project path to assure success.  As they say it only takes one bad apple.

No matter how good the method is, without the right people it will fail.  This is another point of strength for agile.  The reason I say that is agile attracts the people who want to succeed, that understand how things generally work, and those that really push for agile usually have seen what it can do.  Agile lean or whatever you call it.  Get strong individuals who can take the elements of whatever agile methodology and make it as lean as possible.  Generate code, refactor, clean up previous code messes, don’t make sphagetti.  Focus DB Gurus on the DB, get the coders on in the code, get the BAs talking to customers and so on and so forth.

To be lean, you gotta make sure the people you have are the right ones for the job.  Without the right people, even lean and agile process is nothing but a death march.

While working on some AJAX and module add-ins for Community Server 2007 I started checking out the videos on the www.asp.net site.  Definitely some good material and something that almost any web developer should be checking out.