Vijay Narayanan is a systematic reuse evangelist building reusable data services and business process automation components. He has worked on several software projects ranging from single user systems to large, distributed, multi-user platforms with several services. He is a technologist focusing on software reuse, agile development, and Service Oriented Architecture (SOA). Vijay is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

Systematic Reuse Success Factor #12 – Empower Tech Architects

09.05.2012
| 2035 views |
  • submit to reddit

They key word in the phrase “systematic software reuse” is “systematic” – that is what distinguished ad-hoc reuse from continuous, iterative, investment-oriented reuse that provides benefits across projects. Anyone that has driven change within an organization will attest that one of the key enabling factors is political will and top-management sponsorship. Similarly, systematic reuse efforts need intervention and influence across every project – it needs your architects to have a say in the design and the implementation. Technical architects cannot be passive and standing back whining and complaining that the development teams aren’t listening and they aren’t reusing existing assets or investing in creating new ones. In addition to hiring competent architects, management needs to empower them. They need to be given authority and made accountable for systematic reuse efforts – want architecture convergence? faster time to market? lesser cost of maintenance? All of these are possible with systematic reuse but only with proper investment and ongoing guidance and care.

Empowered architects should be able to alter/change the technical strategy, design, and implementation approaches to ensure that it is inline with the overarching technical strategy for reusing capabilities within the teams. Of course, this doesn’t mean they stop everything without delivering value to clients on a continuous basis. On the contrary, architects need to be focused on both alignment with reuse and business delivery. They need commitment from teams that pursue tactical measures that they will get out of technical debt and align completely with the technical strategy.  They should and be able to intervene throughout the development process – during requirements analysis, design, implementation and review by working with the development teams in a hands-on fashion. If the architect carries no decision making authority to stop releases, change approaches, or extract commitments – the technical debt will stay where it is and reuse will be an elusive goal.

Published at DZone with permission of Vijay Narayanan, 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.)