Over a million developers have joined DZone.

Systematic Reuse Success Factor #12 – Empower Tech Architects

DZone 's Guide to

Systematic Reuse Success Factor #12 – Empower Tech Architects

· Java Zone ·
Free Resource

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

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}