The Design Authority role is a vital role in large, architecture based programs. Unfortunately, this is not always recognized and particularly in times of tight budgets, often discarded or reduced.
Ideally, the Design Authority role is taken up by an Architect (or more) and is positioned outside of a project. The emphasise is on Authority, meaning that the Design Authority can approve or deny a particular design to be implemented. Obviously based on proper reasons.
How far does the Design Authority have to go? In my experience, very far. Even into the design of individual programs, services, etc., down to the actual set-up of networks, and so on. Even a simple piece of coding by a creative (or lazy) developer can undermine the ambitions of the company and reduce the investments in architecture to (development) business as usual.
Example 1: some years ago I was working as a Data Architect for a large Financial Service Institute and was assigned as Design Authority to a project that was about to implement a solution based on a CRM package. After having approved the Conceptual and Functional Designs, it was time to pick up on the Technical Designs. These documents were a farce: they included references to the Functional Design (the design, not a particular chapter or paragraph), decent technical specifications, pseudo code, real code (correct), real code (syntactical incorrect) and real code (syntactical correct but functionally wrong). A mess. And yet 10 developers were already working cheerfully away fine-tuning the CRM package. The reason the lead designer gave for this bad design is: “The developers know which 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.”.
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. We had some group meetings and workshops to make sure the developers were all aware of the greater plan and I went on to do the next best thing: go through the actual code.
I will spare you the list of items I have found, except for this one: I noticed that at least in 5 pieces of code, a unique key for the CRM database was created. One of these was incomplete yet the code was passed through testing. I asked the lead designer why it was necessary to have this code 5 times and why one was different. “Why not use a single function that can be used by all?”. The answer was: “They’re not supposed to write that at all, there is a standard function within the package that they must use.”
Peer-to-peer reviews had not revealed this, testing had not revealed this.
With this prove and in my role as the Design Authority I had the possibility to enforce the project team to repair this (and other issues) before they were released to production. This time, neither Project Management nor Program Management could object, since it was no longer a matter of “Don’t worry, they know what they’re doing.”
The following can be observed:
– the Technical Design was too open to guide the developers (the code to create the key was in there, instead of a reference to the function);
– 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 code;
– 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 fundaments of the architecture and Service Oriented Applications as a whole.
Example 2: Recently I was reviewing the technical designs and implementation of a functional design I had made some years ago. In order to link data to other data (thereby keeping the original data for audit purposes), I had designed a very generic method to link any data to any other data, including security and authorization procedures through meta-data. In total, a single program to which 5 parameters would be passed, would be able to perform all the linking and unlinking functions for all data.
The original developer understood the concept but failed to implement it because of time pressure. He only implemented the program with 2 parameters. Enough for the then-known required data links.
After some time, another data link was needed and the developer was confronted with the problem that those were more complex and needed 4 parameters. Instead of fixing the original program he decided to copy the program and hardcode the 2 new parameters. Again under pressure of time. Net result: 15 minutes of work instead of days and days of testing. Two weeks later, a similar request was made and a new copy was created.
The company wanted to outsource application management and asked me to come back in and go over the current status of the applications. I found about 7 more copies of the original program, some with added functionality, others without. Had they remain faithful to the single-program solution, then maintenance would be so much easier and all new functions would have been available for all data links.
When talking through the history of this, the following conclusions were drawn:
– Time pressure was the most significant contributing factor;
– Lack of understanding of the design was another major factor;
– Peer to peer reviews and testing had not revealed the faults;
– No Design Authority on hand to stop this from going into production.
More importantly, though, is the fact that the original design required no development when new data links are needed. Punch in the proper meta-data and it’s ready. The actual implementation, however, requires often that a new program is created. Takes about 15 minutes (plus the move through testing and to production), but so unnecessary.
So, as in example 1, the actual implementation undermined the architecture and service oriented application development.
Under the current struggle of companies to make ends meet and to do as much as possible with the little budget that is left, I see roles such as the Design Authority fade to the background. No money to have another reviewer, no time to wait until the Design Authority has approved the designs and a firm believe in the professionalism of the project team itself.
I too believe in the expertise of the average ICT people. Obviously there are some that are pretty bad, but on the whole, they’re quite good to excellent. That’s not the point. The point is that they are confined by deadlines and are sometimes hardly allowed to understand the complete picture. Only the parts they are supposed to work on are they allowed to read and understand.
Reviews within the team are usually focussed on delivering the requested functionality, not on whether it fits the environment or the architecture.
So here are a few tips:
– Make sure your project team not only understand the part that they are working on, but also the big picture and the longer term.
– Make sure that the big picture is clear, available and accessible. Not only documented, but explained by the architects.
– Make sure the lead designer is confident that the designers properly understand what they’re supposed to do
– Make sure peer-to-peer reviews address more aspects than whether the coding is good and neat
– Make sure you have someone outside of the project that can review and accept/deny the solution: Business Community for the business aspects, Operational Management for the maintenance and management aspects and the Design Authority for the architectural fit.
– Make sure that the Design Authority also looks at changes later on (maintenance phase).
I know, I know, it will cost you extra money upfront and may even add extra time to the project. But it will definitely add to getting that great lean and mean application you’ve always dreamed of.