Enterprise Integration Zone is brought to you in partnership with:

Behind DotNetBlocks.com is a software engineer with over 10 years of experience in Microsoft technologies and is currently obtaining a Masters in IT. His primary focus is typically on software architecture, web applications, and interactions amongst various systems. Todd is a DZone MVB and is not an employee of DZone and has posted 47 posts at DZone. You can read more from them at their website. View Full User Profile

Is Architecture Evaluation a Waste of Time and Money?

10.17.2012
| 5984 views |
  • submit to reddit
How many of us have worked at places where the concept of software architecture was ridiculed for wasting time and money? Even more ridiculous to them was the concept of evaluating software architecture. I think the next time that I am in this situation again, and I hope that I never am I will have to push for this methodology in the software development life cycle. I have spent way too many hours/days/months/years working poorly architected systems or systems that were just built ad hoc. This in software development must stop. I can understand why systems get like this due to overzealous sales staff, demanding management that wants everything yesterday, and project managers asking if things are done yet before the project has even started. But seriously, some time must be spent designing the applications that we write along with evaluating the architecture so that it will integrate will within the existing systems of an origination.

If placed in this situation again, I will strive to gain buying from key players within the business, for example: Senior Software Engineers\Developers, Software Architects, Project Managers, Software Quality Assurance, Technical Services, Operations, and Finance in order for this idea to succeed with upper management.

In order to convince these key players I will have to show them the benefits of architecture and even more benefits of evaluating software architecture on a system wide level.

Benefits of Software Architecture Evaluation

  • Places Stakeholders in the Same Room to Communicate
  • Ensures Delivery of Detailed Quality Goals
  • Prioritizes Conflicting Goals
  • Requires Clear Explication
  • Improves the Quality of Documentation
  • Discovers Opportunities for Cross-Project Reuse
  • Improves Architecture Practices

Once I had key player buy in then and only then would I approach upper management about my plan regarding implementing the concept of software architecture and using evaluation to ensure that the software being designed is the proper architecture for the project. In addition to the benefits listed above I would also show upper management how much time is being wasted by not doing these evaluations. For example, if project X cost us Y amount, then why do we have several implementations in various forms of X and how much money and time could we have saved if we just reused the existing code base to give each system the same functionality that was already created? After this, I would mention what would happen if we had 50 instances of this situation? Then I would show them how the software architecture evaluation process would have prevented this and that the optimization could have leveraged its existing code base to increase the speed and quality of its development.

References:
Carnegie Mellon Software Engineering Institute (2011). Architecture Tradeoff Analysis Method from http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm

Published at DZone with permission of Todd Merritt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mohan Kumar Muddana replied on Wed, 2012/10/17 - 2:43am

Able to convince the stakeholders and managers is a big challenge. Though I agree your points.

Orlin Gueorguiev replied on Wed, 2012/10/17 - 3:40am

Hi Todd, I believe that in Your analysis of the reasons to why architecture is being neglected, You forgot one of the biggest problems - lack of understanding from management. Management is normally not an IT professional and can't understand the reasons why IT wants good architecture, automated building tools/tests, etc. So, because they see no benefits in this disciplines, which then reflects in how they set the team priorities. A new feature generates immediately user value, while architecture does not. Until the people, who manage IT do not understand that you can't build a large scale software without a given set of tools and processes, things will continue to be as they are now.

Stephane Vaucher replied on Wed, 2012/10/17 - 1:31pm

The concept of technical debt was created to help developers communicate the issues with bad design/architecture to non technical folks (who likely understand the concept of debt).  By the way, I don't understand the acronym ADHOC, but it seems like the latin words ad hoc.

Todd Merritt replied on Wed, 2012/10/17 - 11:46pm in response to: Orlin Gueorguiev

Hi Orlin,
You bring up a very good point that not all managers are technical. However, in order for us to succeed as technical professionals we must be able to tailor our communications based on our target audiences.

I think you are partially correct when you stated that until IT management understands that you can't build a large scale application without a given set of tools and processes then maintainable architectural approaches will never be made a priority.

I think this issue goes much deeper. I do not think that some IT/executive management can see the real value and cost savings incurred by incorporating tools and process. In my personal opinion most managers make IT decision based on the potential return on investment (ROI) gained by the decision. Unfortunately some manager only focus on short term ROI when they should really consider the mid to long term ROI in their decision making process. If we can get them to see how the extra initial costs incurred by developing an application on a maintainable/solid architecture  increases their ROI over time compared to the initial ROI they may see with an application that is built on a less ideal architecture.

One way I would try to demonstrate this is through showing the potential technical debt incurred by both architectural approaches over a given set of time.

- Todd

Todd Merritt replied on Wed, 2012/10/17 - 11:56pm in response to: Stephane Vaucher

Hi Stephane,

You bring up a good point about using technical debt to communicate with the business. I would hope the business understands the concept of debt. :)

On another note, thanks for pointing out "ADHOC". That is what I get for only using MS Word's Spell Check feature.

You are right it should have been spelled like this "ad hoc".

Thanks,

- Todd

Lund Wolfe replied on Sat, 2012/10/20 - 1:52am

I also believe "anything worth doing is worth doing right".  This is somewhat idealistic for the business world, though.  It's easy to judge software apps and systems in hindsight as "legacy" with no or pitiful architecture/design, but I don't think there is really any mystery or evil or management stupidity involved here.

You'll swear they used unskilled developers, but to be pragmatic, the application is needed to keep the company going and it has to be built now and enhanced now.  Skilled developers have always been few and far between and probably always will be.  If the company stays alive, the application has proved that it is "good enough" (and may be better than the competition, if any) even if only barely.

The business may also have only a vague understanding of what the actual business requirements are when the system is originally built or how it will be extended over time.  In hindsight, years later, it becomes obvious and it can now be cleanly designed to satisfy the now known requirements and priorities.

If the company is truly successful, the whole system can be refactored or even completely replaced.  It's never too late, and it may be required.

Jose Romero replied on Wed, 2012/10/24 - 7:40am

s/will integrate will within/will integrate well within/

 

 Cheers,

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.