I’ve been discussing with a lot of people, working in various organizations, about what process they are using in their companies. I received basically similar explanations from most of them even described with different words.
The main discussed questions are:
– Are you doing an up front or evolutionary design?
– Do you have architect role in your project?
– Do you have diagrams? At what stage of the project? How granular and detailed are they (if any)?
– Do you consider your process agile or waterfall?
There are different variations of answers to the above questions.
The big old corporations are used to work following the waterfall approach and doing all the big and juicy diagrams for the whole project before starting of any development. All the architectural decisions are made up front and everything is being documented in great details for the whole system which is going to be build. Full specification have to be created, tasks splitted and estimated. And then you have a release date and a green light for the developers to consume it and produce code. No iterations, no sprints, no features splits. Just one big piece called “The Project”.
At a contrast if you take a start-up team as an example (or some relatively new company) the process goes a bit different. They have adopted an agile framework like Scrum or Kanban.
Here the solution evolves in time. The work have been split by feature sets, represented in time by iterations (sprints). This way the team makes multiple small releases after every iteration and by every release a new feature (or set of features) is presented.
That approach continuously delivers to the business some important functionality of the software, which is with highest priority and will bring value to the company. Otherwise the company have to wait until the whole project is ready, which leads to loss of money, clients and competitors advantage.
Refactoring, evolutionary architecture and extreme programming (XP) are key principles of that approach.
The more extreme followers of the methodology say that they don’t need any architect in the team, simply because they do not need architectural diagrams and designs up front. Instead the developers are taking care of those decisions during the implementations – sprint by sprint and task by task.
However as I started the post I mentioned that most of the companies nowadays are having a similar working process. A process which is somewhere between the two described up there.
Some of the big corporations are trying to carefully switch from purely waterfall to kind-of agile process.
On the other hand lots of the new formed teams are using lean methodology but with some principles adapted from the planned designing approach.
So it appears for the time being the truth is in the middle, a hybrid which have taken practices and processes from both ends.
There are several methods like this – Rational Unified Process, Discipline Agile Delivery, DSDM Atern or whatever name your company gives to it.
Following this approach, I think that a company still do need some high level UML diagrams. Designing the big picture, the overall architectural approach, the integrations and collaborations between the systems and some basic sequence diagrams can be of a big help during the development of the system and also good documentation artifacts. The lack of such resources will lead to harder development, support and upgrade of the product. The idea is to have the right amount of those and to be as detailed as needed and no more than that.
There are some very good resources for the topic.
I can really recommend Martin Fowler’s article Is Design Dead?
Also a good book to read is Software Architecture for Developers by Simon Brown where you can find lots of information about what is software architecture about, considerations, practices and principles. He also writes about the dilemma for the planned and evolutionary design and the need of an architect.