December 2005

Monthly Archive

Simon Guest on Architect Personas

Posted by on 19 Dec 2005 | Tagged as: Software Architecture

Simon Guest posted an entry on “Architect Personas” in which he identifies three different personas in software architecture:

  • Enterprise Architect – Strategic Architect, Chief Architect, Business Architect
  • Solutions Architect – Application Architect, Data Architect, Integration Architect
  • Infrastructure Architect – Technology Architect, Systems Architect

I thought this was quite an interesting concept and I also enjoyed one of the comments made by Mitchell Land regarding the Solutions Architect. He says:

“I think you can create another triangle solely for the Solutions area in which you have Software Architect, Data Architect and, perhaps, Integration Architect. Some people are more accomplished in one area over the others. The individual who is accomplished in all three is a true Solutions Architect”

I agree with this statement but also believe that the titles data architect, application architect, and integration architect are a bit misleading. My belief is that these titles are created just to categorize somebody as senior in their particular area of software development. If these category of software developers are titled architects it creates confusion for those who do not understand a solutions, enterprise, or infrastructure architects role. They may say things like “aren‘t software architects just a senior developer”.

I had a conversation recently in which it was brought up that the use of the architect title is perceived to equal a lead or senior software developer. The interesting part was after discussing this back and forth we thought it may be helpful to describe the lead and senior level developers. These are roles which are greatly needed within organizations for more granular domain recognition and team mentoring. By doing so we may get a better distinction between a lead or senior software developer and a software architect.

Software Design Aesthetics

Posted by on 15 Dec 2005 | Tagged as: Software Architecture

During a very interesting meeting with Nicole Tedesco this last week I was enamored by the following statement:

Aesthetics move whole societies

I found this statement incredibly profound. We were discussing a recent article, “Envisioning a New Language: A Conversation With Sun Microsystems' Victoria Livschitz” regarding the concepts used in the Metaphors conceptual language. As development teams and organizations, we strive for better designs which improve overall software quality and eventually organizational value. In order to satisfy a good design we must meet both functional and aesthetic results.

The International Society for Mathematical and Computational Aesthetics (ISMCA) describes aesthetics in software design as an important tool for structuring systems. In software design we use conceptual metaphor, the description of one conceptual domain using another conceptual domain, as a way to communicate the interactions within a system. Conceptual models, such as those created in UML diagrams, allow developers to understand a larger domain in which they implement a component or sub-system. As a developer becomes more experienced and talented in their craft, the value of such models becomes increasingly important. Developing their components or sub-systems within the context of a larger system domain allows them to make better decisions in aesthetic design.

While I was at the No Fluff Just Stuff software symposium in Redmond, Washington, Dave Thomas delivered a presentation on the topic “Herding Racehorses and Racing Sheep” in which he discussed a software developer's progression towards mastery. If you haven't been to one of Dave's presentations you should based on his presentation skills alone. A major point in the presentation was a description of the Dreyfus Model which contains the following stages:

  1. Novice – Works without concern for an encompassing context and reacts based on rules
  2. Advanced Beginner – Uses more sophisticated rules and starts to put them into context
  3. Competent – Recognizes more contextual elements but still does not formulate understanding of encompassing task. Starts to seek more advanced mentoring and education but is easily overwhelmed by larger concepts
  4. Proficient – Mostly performs tasks intuitively and learns from the experience of others
  5. Expert – Performs almost all tasks intuitively and work on these intuitive skills rather than goal based planning

While building our skills through the first three stages, we have a difficult time understanding conceptual models of systems. We continually encounter metaphors which either surpass our comprehension of the domain or we interpret it incorrectly within the domain. Upon understanding the domain metaphors, we pack this information into our bank of conceptual analysis of the domain. Over time, this bank gets large enough that we are able to rationalize metaphors which seem similar to a currently understood metaphor. At this point we progress into the fourth and eventually the fifth stages of the Dreyfus Model.

All of the above information brings me to a few recent trends in the software development realm: XML, SOA, web services, AJAX, Ruby on Rails, and Python. Many of these concepts and languages have been around for quite some time. Arguably, all have risen in status over the past five years. I would also argue that all of these are either overly utilized or recommended inside IT organizations. There has been an incredible increase in XML, SOA, and web services marketing literature this year with the hype of ESB (enterprise service bus). AJAX, Ruby on Rails, and Python have all been professed as Java and .NET killers based on their “simple” usage.

Now, I do not wish to be known for bashing these concepts and languages themselves, but I do believe the marketing and hype behind them are misleading. Most applications do not need to use XML, SOA, or web services. AJAX, Ruby on Rails, and Python are not going to solve all of our IT organizational issues such as operational and maintenance costs. They are, however, another set of tools which, when used in their context, can improve software development business value. XML, SOA, and web services may allow large organizations integrate disparate systems or small organizations deliver services to customers. AJAX will enhance the web experience in both functional and aesthetic appeal, but will probably not be necessary for all web sites. Ruby on Rails and Python will allow for quick prototyping of systems and may find particular niches in IT utility applications. It is probably not your first choice for EAI, ESB, or SOA based systems.

As software developers and technologists, we must look more deeply into the current marketing and vendor hype. Most, if not all, software vendors are driven by their competition within specific domains. If vendor A has a package which is a solution for domain Y and vendor B comes up with another solution for domain Y which also addresses domain Z, it is almost intuitive that vendor A will add solution for domain Z to their product. This is not necessarily based on customer need or software design aesthetics, it is usually for marketing buzz. We must be able to look past this, even when it comes from our industry‘s luminaries, and make decisions from our own domain context and conceptual models. We all work within a larger domain whether it be the an IT or development organization, a corporate enterprise, government agency, consultancy, or open source community. The goal should be to deliver the most functionally and aesthetically pleasing software possible by those involved. Not to use the next hot technology buzzword on the market.

The Catalyst for Business-Driven Technology

Posted by on 15 Dec 2005 | Tagged as: Software Architecture

My wife asked me last night what my title meant, software architect, in terms of job function. Since explaining all of the roles a software architect plays during a normal project, I have started using a phrase which I heard from Paul Preiss, president of the IASA:

The synergy between business and technology

Using this as a platform, I went on to explain some of the topics I attempt to address using business and technology such as communication techniques, unified modelling, product design, and coding. After this explanation my wife put what I said in her own chemistry-based terminology:

Oh, so a software architect is a catalyst for business using technology

I thought “Wow, what a great term to use for software architects and their role in an organization”, at least as I understand it. So, I decided to figure out if anybody else had made such an association. Come to find out someone else has made this analogy. The book is by Marc Sewell and Laura Sewell titled “The Software Architect's Profession: An Introduction” written in 2002. The excerpt which I originally found from the book which contained the word “catalyst” is located at I can not reproduce the content here, but please take a look and let me know what you think of the excerpt.