No Process As Process

Software projects are infamous for failure. These failures occur for a number of reasons. Many times these failed projects fail even though a software process was implemented. We might therefore conclude that process itself does not guarantee success. At the same time it is not the process that fails or succeeds but rather the resources that execute them.

Software processes try to encapsulate years of experience and knowledge of successfully delivering software. They consist of a number of techniques and steps coordinated within a workflow. They orchestrate all the resources required to deliver software.

Software projects consist of technology, people, process and context. These elements are all related in a multitude of ways. In fact they are related in an infinite number of ways, and therefore it would be foolish to think that a single process would be valid for all the relationships that could occur.

I would say that the process should provide the coordination of the technology, people and context. Process does not do this by itself (although most processes think they do), but unfortunately requires someone - typically the software architect - to execute the process in order to coordinate the technology, people and context. Due to the dynamic and unpredictable variables such as context and people, the process must be malleable and flexible. It is the software architect’s role to ensure that he is getting the desired outcomes from the process.

Also process is considered a risk in terms of the project, but I would rather see process as a mechanism used to mitigate risks in a project.

Bruce Lee a leading martial artist once said the following “No way as way, no limitation as limitation”. Bruce Lee was referring to the large number of martial arts styles that existed, including his very own style. Bruce Lee was of the view that a true master needs to be like water and adapt to its environment. Bruce Lee attributed his success to his adaptability – by adapting to his opponents fighting style he was able to overcome him. Thus a true master is not limited by a single style but rather adaptable enough to any style.

This analogy is also true for any software development process. While there are numerous experts punting their own or a particular method, a fixation with one particular method for every kind of project is not always in the best interest of the project itself.

Process is only a means to an end and not an end in itself. Process should be the collection of the best techniques that get utilised appropriately to deliver value. Thus it is the application of techniques, rather than the techniques themselves, that overcome the specific challenges of a delivery.

So can one size fit all? No. Yet we have the process evangelist screaming “use mine; use mine”, without really trying to understand what kind of project you wish to embark on.

The following concept is so important that I must repeat it again – every project consists of many different elements. User requirements, people, technology, business driving forces, and the process itself are all important elements of a software development project. On every project these elements combine differently, and the combination of these elements is infinite.

Furthermore each of these elements by themselves is complex enough and uniquely influences each project. Trying to synergise them is an immense task only to be undertaken by skilled individuals who can choose the appropriate courses of action for the specific project challenges.

Fortunately the techniques that can be used to implement a process are well known, but the application of each technique is where the failings continue. The application of these techniques is where skill, experience and a touch of good luck is required, and cannot be acquired from any one book, seminar, training course etc. It is a craft that can only learnt as a craft through some form of mentorship and experience.

I believe that our efforts should be directed at identifying the techniques required for the application of process to any development effort. We need to define the criteria for the use or non-use of each technique. In this way we will be able to select appropriate processes for projects, thus contributing to a project’s success.

However, this is not to say that the application of any particular process as it stands now would not succeed. If applied differently, it is possible that we could succeed with a lot less process for an equivalent quality of delivery.

Over the next few months I will be addressing how we categorise these process techniques, apply them and more importantly how we share this expertise in a simple manner for the benefit of all software developers.

Remember the focus – The end of any project is the delivery of value to its sponsor and not the process used.

What are Software Architects?

In recent times I have met many technical resources with the titles such as Software Architect, System Architect, Lead Architect and/or Enterprise Architect. Some of the architects that I met had no more than 3 years of IT experience. I began to ask the question – what is a Software Architect? What sort of skills should they have? The first thought that I had was that a Software Architect was synonymous with software delivery WISDOM.
Software delivery WISDOM is the key to my definition of an architect. It is the sum total of an architect. Thus in order to earn the right to be an architect one has to acquire wisdom. Delivery is important since these wise people can balance and trade off issues between delivery of solutions and technical perfection. They understand the place of IT within the broader context of solutions. They understand that IT does not exist for the sake of IT but rather as an enabler to solving real world problems.
How does one develop this skill? The question has to be asked of a person that does not have this skill – Is he still an architect? I THINK NOT. WISDOM has to be a prerequisite to have the title of architect. In addition to WISDOM, there are a few core essential skills that are essential to call oneself a Software Architect.
The next logical question is – how does one acquire WISDOM. One acquires this by working on and delivering a number and variety of large solutions in multiple domains and in different capacities. The minimum time period that I would attach to this is 7 years of experience. This experience must come from working in multiple domains on various sized systems. Also important, is experience in working with a range of different technologies. Responsibility for successful delivery is a key component. More importantly, developing insight into the factors that contribute to the failure of a project is essential.
Architects must have experience in other areas of the software lifecycle in addition to development i.e. deployment, operational areas, maintenance and decommissioning. The other areas provide feedback on the decisions taken early in the lifecycle of the software. The architect needs to experience the conveniences and pains of earlier decisions in order to develop architectural character. Having to live with the consequences one’s architectural decisions develops a respect and cautiousness for such key decisions.
Experience gained by using various technologies provides an architect with knowledge and understanding of various technologies. Like all things in this world each technology has its strengths and weaknesses, and it is important that architects understand the variants and subtle nuances of each. This understanding cannot be achieved at a theoretical level and has to be experienced in a hands on fashion. Once this understanding has been developed, it enables an architect to harness technology appropriately for complex solutions that he needs to deliver. If not the old adage that if you have a hammer all in the world looks like a nail always proves itself true.
Architects must also be leaders. Any sufficiently large software project requires a team of people to successfully deliver it. This team needs a leader. The architect provides this leadership. He directs all the effort towards a successful conclusion. If the architect is clear about the road ahead, then the team is able to work successfully on that road. The architect is an inspiration and leads by example. They are respected for their technical wisdom. The leader can always see the forest from the trees, providing the correct focus at the correct times.
Architects must also understand the business world in order to align his technical solutions to the relevant business problem. The architect will use this knowledge to balance technical perfection for business agility. He would be able to make the appropriate trade offs and prioritization easily.
Architects must have project management skills so that they can plan their solution implementations better. This skill provides the architect the ability to manage their delivery and teams on a day to day basis.
Architects are technical decision makers and decisions are dependent on one’s analysis and design abilities. This is the foundation on which architects are built. If this is not one of their character strengths and then unfortunately I do not think they would ever be good architects.
Architects can only produce the extraordinary and provide the technical edge over competitor solutions with creativeness and innovation. Architects need to develop their creativeness and outside the box thinking to become truly great architects. They would be able to use old technology in new ways thus extend the usefulness and competitiveness of systems. Architects are constantly seeking better and more elegant solutions and do not suffer from the NOT INVENTED HERE SYNDROME.
Architects need good communication skills. They need good listening skills and look towards their development teams to provide feedback and ideas on improving and enhancing their designs. They must have good oral and written communication skills so that their ideas can be expressed eloquently and influentially. In the architects world there is no right and wrong but rather more or less appropriate solutions.
The skills of software architects can only be learnt through mentorship and coaching by a number of other architects. So if you are still keen to develop into a world class software architect, your first step is to find a great software architect and get on his/her team and learn as much as you can.