I just ran across a 2 1/2 year old post about what a software architect is on Mike Sax's weblog that was a comment to a post I made . Mike quotes Alan Cooper quite nicely:
Web designers are called programmers, programmers are called engineers, engineers are called architects, and architects are never called!
I just wanted to say that I am (and was at the time of my original post) familiar with Alan's quote and whole-heartedly agree!
People are constantly doubting the abilities of .NET and SQL Server when it comes to enterprise capabilities. For this reason, I'd like to keep track of some stats from popular applications. One of these is My Space, which has been using .NET 2.0 since before it's official release. Before that, the application was built using Cold Fusion. As for the metrics, My Space gets 2-2.5 billion page views per day and has an average of 4-5 million simultaneous users. Compared to the Cold Fusion system, the server load decreased by 2/3. While it may be an interesting statistic, the performance difference between Cold Fusion and .NET shouldn't be the focal point. The true point of this post is the load .NET can handle. If I get more numbers from other systems, I'll post them as well.
Processes exist for a reason. I think we all know that. Nobody can acurately say that processes are bad. They can be taken too far, tho, which is why agile processes have grown so rapidly in the software development arena. Personally, I think a lot of that has to do with trying to get away without documentation, but that's a different issue. Honestly, agile processes don't have anything to do with the level of effort put into documentation. Anyway, all of that's besides the point. I read a post, If Not Agile, Then What , by Rockford Lhotka a while back and I've been meaning to remark on it. Over the years, I've put a lot into defining and working to better development processes. This came from being in a process-heavy organization. At the same time, I've always appreciated the fact that the processes in place were more than I thought necessary. There are certain architecturally significant steps I believe are important for any development project, but the level at which they should be achieved can vary a great deal.
Rockford talks about how nobody follows any process 100% and no process was built to be 100% followed. Well, those aren't his words, but it's the basic jist of it. One thing I've always wanted to do was create something like a step-by-step process for defining your own development process. Basically, you'd input your criteria and out would pop a suggested process, documented from front to back. You could, of course, pick and choose what you actually used; but the core concept is that the practices -- along with their pros and cons -- would be given to you so you can make an informed decision. That's one thing you have to be able to do as a consultant: allow your customers to make thier own decisions. If you want to bury yourself, I'll hand you the shovel; but not before telling you what I believe could happen, what to look out for, and what your options are going to be if my foresights have come to pass. Defining and following a development process is a weak point in most organizations. Sure, people might deliver, but is there enough documentation? Beyond that, how much is enough? There's no single answer for these questions and the thousand others that would typically follow. This, of course, is why I've always wanted to formulate the process generator I mentioned. I don't know if I ever will, but it will always be in the back of my mind.
If you're interested in software engineering processes, I suggest you give Rockford's post a read. I'm always interested in people's opinions regarding engineering processes because it helps me take in different viewpoints and better understand the necessary flexibility for any process to survive across multiple projects, which is almost a must-have for a development organization. The more processes in one organization, the more wasted time and money that goes into managing these processes. I don't think most developers realize the importance of a well-defined process because they haven't been exposed to larger system development teams and organizations where project scheduling and documentation isn't something that can be debated without risking project success.
If you haven't seen it yet, check out the domain-specific language (DSL) tools video
on Channel 9
. I admit, the video isn't all that exciting, but the capability is. The simple fact that we can now build designers so easily is astounding to me. I've never been one to care enough to learn some of the advanced graphics stuff you can do in .NET, but I've always wanted a complete model-driven architecture (MDA)
environment. This is a means to that end. I'm excited about it. I can't wait to dig in and create my own! Then again, there's always that pesky time thing...