> This is actually the hardest part. I can write detailed requirements about the car I need. Create a PowerPoint presentation that shows a schema of the system and subsystems; the engine block, transmission and steering wheel etc. with lines how they are connected.
> That's the easy part. Now you need the team of skilled engineers developing the actual car. And you need them to be experienced and good at it.
In this analogy, the engineers who design the car are the equivalent of the systems analysts. The programmers are the machinists on the shop floor actually building the car.
> You need at least one guy who is able to load a complete mental map of everything that's needed to be engineered. Who understands the business requirements and is able to create a vision for the product and technical solution. He needs to understand databases, web services, authentication, authorization, security, performance, web standards back- and front-end solutions. Be smart about what logical components are needed and have an high level idea how they could be implemented technically. Ideally that guy can also open a repository and read what's going on.
Yes -- that's your systems analyst! More importantly, they need to understand the business and the information needs of the people involved. A high-level, 10,000-foot understanding of technical requirements is important, but the details should be left to the programmers. That's what programmers are good at. It's the big-picture, business-centric, people-oriented view that's missing in today's culture, and prevents us from "building the right thing right".
> The programmers are the machinists on the shop floor actually building the car.
No, because with software there's no human execution. It's the computers that execute the design. The developers design the blueprints of what the computers need to execute. They are the architects.
For an analogy you can probably best compare this with 3D printed houses.
> A high-level, 10,000-foot understanding of technical requirements is important, but the details should be left to the programmers.
But why leave the details to the programmers? Why doesn't the systems analyst produce a proper CAD-like blueprint that leaves no room for interpretation? His system design should produce the exact same result regardless which contractor implements it. Yet that's never the case.
The reason is because he can't. The systems analyst doesn't have a clue what he's designing. If he would be able to write a proper blueprint we could just hand it off to the computer and have it executed. No need for programmers. But now the systems analyst has become a developer.
> That's the easy part. Now you need the team of skilled engineers developing the actual car. And you need them to be experienced and good at it.
In this analogy, the engineers who design the car are the equivalent of the systems analysts. The programmers are the machinists on the shop floor actually building the car.
> You need at least one guy who is able to load a complete mental map of everything that's needed to be engineered. Who understands the business requirements and is able to create a vision for the product and technical solution. He needs to understand databases, web services, authentication, authorization, security, performance, web standards back- and front-end solutions. Be smart about what logical components are needed and have an high level idea how they could be implemented technically. Ideally that guy can also open a repository and read what's going on.
Yes -- that's your systems analyst! More importantly, they need to understand the business and the information needs of the people involved. A high-level, 10,000-foot understanding of technical requirements is important, but the details should be left to the programmers. That's what programmers are good at. It's the big-picture, business-centric, people-oriented view that's missing in today's culture, and prevents us from "building the right thing right".