| By JP Morgenthal | Article Rating: |
|
| May 25, 2008 09:45 AM EDT | Reads: |
7,492 |
JP Morgenthal's BlogI've worked for Fortune 500 companies engaged simultaneously in 50+ of IT projects as well as small companies with one or two products and I don't believe there is a need for any organization to have a full-time software architect. Once the modeling is done, it is the work of coding and testing that truly takes the full-time effort. Once underway, 100 hours a month of time is enough for any architect to respond to most needs of all ongoing projects.

Those who have worked in software development, whether in corporate IT or in commercial software companies are most likely familiar with the analogy between building software and building buildings. That is, the architect designs the building and the software developer builds the building. Sometimes there is the equivalent of a structural engineer, but most often times the analogy is left in its simple form as a means of differentiating the roles and to demonstrate the separation of concerns and skills.
The importance of the analogy is to instill that without proper architecture up front, there is significant risk your building might fall down. However, the aspect no one discusses of this analogy is that the engineer is on site full time during the build out, while the architect does 80% of their work up front and then might provide intermittent reviews while the build out is occurring.
Additionally, it’s not uncommon to find that most commercial entities start building their software with engineers alone foregoing the architecture until a crises occurs, resulting in the answer, “let’s get an architect in here.” The belief here is that the architect will save the day and make sure all the buildings under development will meet coding standards and remove all future worry. Oh yes, and this is all to happen without tearing down the building and starting from scratch.
The architects answer of, “you need to start this over and do this right,” is often met with rejection and animosity toward the architect. Moreover, usually an engineer will come up with some hack to get the build out going again, which results in the architect now a full time expensive resource who in their mind couldn’t even come up with the simple answer that some engineer 1/2 the price figured out.
This all results in the architect stuck in a position where they deem all those in charge around them to be blithering idiots who have no care for the quality of the things they build as long as it leads to the end result of recognizing the revenue. In the case of real buildings, this approach cannot occur because life and death are at stake. However, in the case of software, since the impact to the actual business is minimal, when compared to loss of human life, the organization ends up with a group of hackers that look like heroes and a few architects wondering how they got into the mess they’re in.
Hence, it is my belief that until the IT industry recognizes software architecture in the same way as construction recognizes building architecture, that software architects will forever be frustrated by their situations.
Published May 25, 2008 Reads 7,492
Copyright © 2008 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By JP Morgenthal
JP Morgenthal works as a Sr. Principal Architect with QinetiQ North America's Mission Systems Group providing enterprise and SOA architecture guidance for Federal civilian agencies and an independent analyst for jpmorgenthal.com. Prior to joining QinetiQ NA, JP founded Avorcor where he developed a SOA-based Enterprise retail/manufacturing PaaS that has been the foundation of three award-winning industry solutions for customers. He is also frequent blogger and noted analyst on enterprise architecture, SOA and cloud computing topics. Morgenthal is also author of "Enterprise Information Integration: A Pragmatic Approach", which defines a methodology for using SOA and semantics to simplify integration.
![]() |
Chandra Sekhar Ghosh Dastidar 05/26/08 03:48:02 AM EDT | |||
When a software is built for a life-support system it is definitely a life-n-death situation if anything goes wrong. You might say that it does not have an immediate impact during development but in the long run a life-support machine may abruptly shutdown due to wrong security implementation or stop responding due to poor performance considerations in the software architecture. The project management would definitely need to do proper costing for proper designing of the software by employing the skills of a software architect. No role is dispensable when one commits to deliver quality sofrware. |
||||
![]() |
Paedagogus 05/14/08 09:09:43 PM EDT | |||
I see your point, but I also think you are missing the real value of an architect. Refer to Martin Fowler's, "Who Needs An Architect?" (download the PDF from his web site). What Martin has realized is that an architect is more than just a technical power hitter, or simply draws UML diagrams and spouts buzzwords. Personally, I believe that they must be able to personally code everything in their design, but more importantly, an architect is a coach and a mentor to the entire organization. That is where the long term value is for the architect. Allow me to elaborate: The ability to speak to a large audience and be understood is vital. That means having a clear tongue, limiting your vocabulary (buzzwords), and fully engaging your audience. You also have to be able to work one-on-one with developers to walk them though the development of solutions using technologies they don't understand. That has to be done as a mentor, and not by talking down to them. You have be ready and able to provide a demonstration, and to sit down right next to them as you walk them through the process. Somewhere in the middle of all that you have to also be a buffer for the developers. As a point of contact for product management, you help control scope, and leverage the architecture to minimize any impact on the developer. All of this requires a great deal of task switching; something that is very difficult for many technical minds to do. Pile on top of that the need to stay current with a rapidly changing market, and you have a position that very few people are worthy of occupying. Speaking from personal experience, architects like this are not working 100 hours per month. They are working 100 hours per week. |
||||
- The Importance of Abstraction in Cloud Computing
- Reality Check at the Cloud Expo
- Whatever the Apple iPad Is, It Apparently Leaks Like a Sieve
- Microsoft’s First Step Toward Cloud Computing
- Six Enterprise Megatrends to Watch in 2010
- Economy Drives Adoption of Virtual Lab Technology
- My Personal 2010 Predictions
- How PowerBuilder Got Its Groove Back
- Cloud Computing Was the Big News of 2009
- Adaptivity “Platinum Plus Sponsor” of Cloud Expo
- UPDATE: Adobe & IE Implicated as China’s Spy Holes
- Top Ten Reasons To Use "Real" Outlook On Your iPhone
- Kindle 2 vs Nook
- Cloud Expo New York Call for Papers Now Open
- The Importance of Abstraction in Cloud Computing
- Reality Check at the Cloud Expo
- Whatever the Apple iPad Is, It Apparently Leaks Like a Sieve
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- Microsoft’s First Step Toward Cloud Computing
- Six Enterprise Megatrends to Watch in 2010
- Economy Drives Adoption of Virtual Lab Technology
- My Personal 2010 Predictions
- How PowerBuilder Got Its Groove Back
- Cloud Computing Was the Big News of 2009
- Google Maps and ASP.NET
- Crystal Reports XI & How It Has Changed
- Converting VB6 to VB.NET, Part I
- Creating Controls for.NET Compact Framework in Visual Studio 2005
- Where Are RIA Technologies Headed in 2008?
- How to Write High-Performance C# Code
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Implementing Tab Navigation with ASP.NET 2.0
- i-Technology Photo Exclusive: Bill Gates & Steve Jobs In "Nerds"
- .NET Archives: Getting Reacquainted with the Father of C#
- Programmatically Posting Data to ASP .NET Web Applications
- i-Technology Viewpoint: "SOA Sucks"




















