The Design Authority (DA) role is one that is often overlooked, yet critical to the majority of software development projects. This is usually due to macro level business decisions where upper management do not directly see the benefits gained from having a mission focused design position, at the micro levels of delivery.
There are a variety of reasons for the reduction or absence of a DA including prioritisation of other project factors such as budget, schedule, and resourcing to maintain and monitor the design principals. The consequences of such reduced prioritisation are significant in the long term, specifically to a company’s reputation and re-usability of Intellectual Property – which result in lower investment in architecture for development Business As Usual. So, what needs to happen for this way of thinking to change?
Use Case – Design gone bad (Data Architect – Anonymous)
A Data Architect for a large Financial Service Institute has been brought on board and was assigned as Design Authority to a project that was about to implement a solution based on a CRM product. After having approved the Process and Solution Design Document, it was time to review the Technical Design Documents. The included technical specifications and other reusable IP were above board however when digging deeper into the technical documentation and planning some underlying flaws were apparent.
These documents were poorly structured and inconsistent: they included references to the Functional Design (the design, not a particular chapter or paragraph), pseudo code (that was logically correct however functionally lacking), real code (correct), real code (syntactically incorrect), real code (syntactically correct but functionally wrong). A mess…
Yet ten developers were already working cheerfully away fine-tuning the CRM package. The reason the lead designer gave for this bad design was: “The developers know which object is which and know what they’re supposed to build: they’re experts. The design itself will not be a deliverable, we are in a hurry and we’re not fixing it”. Additionally, it was found that several keys were being created instead of using a function that had been created for this specific purpose.
Project Management as well as Program Management agreed that this was not really acceptable but also that there was no time to stop development completely and do a proper design. Peer reviews had not uncovered the flaws and it was too late to fix. After careful review by the new design authority it was apparent that:
- The Technical Design Document was too open to guide the developers
- The Design Standards did not make it clear that reusable functions should be identified and coded only once
- The developers were not expert enough in the package they were customizing
- In-project reviews do not have enough authority to stop bad developments
- Time pressure forced developers to crunch out code rather than proper and well-structured code
- The developers had the mentality that “recoding something can be done very fast, sometimes faster than looking for existing code”
The biggest conclusion was, however, that the result of the duplicate code is that it undermined the fundamentals of the architecture and Service Oriented Applications as a whole.
It is the role of software development organisations to take responsibility where action needs to transpire. It is therefore the best approach to put a business case forward on the tangible and non-tangible benefits that can be realised from investment in a DA. From this case study it can be seen that without implementing a DA the business case is clear.
This is where Continuous Group can help and provide an accurate representation of the benefits realised not only at a current project level but at a future program level, where the material benefits of investment in a DA will occur.