Is Architecture Evaluation a Waste of Time and Money?
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
(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
Orlin Gueorguiev replied on Wed, 2012/10/17 - 3:40am
Stephane Vaucher replied on Wed, 2012/10/17 - 1:31pm
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
Cheers,