A workflow engine is useful when you need to go from a start to a finish but there are many different paths/logic/rules to get there.
For example, let's say I write a program that publishes content. So, in my case, the publishing goes through a review process, legal, and then final approval. I write up the program implementing my process logic and steps. Now this work great for me and my company. So, I decide others should use my program.
Unfortunately, not everyone publishes content using the same process, so instead of writing separate processes for each different case, we would implement a work flow process so the program is flexible to accomodate everyone. No matter how many steps or rules or logic are between those two points the result is the same.
So, if you have processes that are variable from start to end, use a workflow. If the same process can be used by everyone, then you don't need a workflow.
The problem is that the MVC pattern was designed in a system that doesn't really exist anymore. It was invented in Smalltalk at a time when UI libraries did not exist. To make a window dialog you drew all the boxes, highlighted the appropriate squares, made sure that the text you were drawing ended up in the right spot...etc...
Imagine what it would be like to write a dialog app using nothing but one large canvas. That's the world the MVC comes from.
A "view" in this system was a text box and it was a class that was responsible for drawing the box, the text, drawing selected areas, responding to changes in the text, etc...
A "controller" was another class that took mouse events that occured within this box like mouse moving, key down, key up, clicks, etc...and it would decide what happened. Should we change the text? Should we change the selection? Stuff like that.
A "model" was yet another class that represented the basic data and state of the component. A text box model would have the text of course, the font, selection, etc...
As you can see, in a situation like this the three components are very entangled in the representation of a single idea. It makes sense in this context to speak of a "triad".
Today, if you're working on creating a UI library and using raw drawing commands you might do something similar. But the application of the "MVC" pattern has spread beyond its initial purpose. Now days you have a "view" that may actually be a complete dialog, and a controller that's responding to events like "textChanged" or "buttonClicked". The model in today's MVC is normally something fairly disconnected from the system (but generally linked to the view by providing an observer interface of some sort) and there may be many views associated with the one model.
In a system I recently architected for example we had around 10+ views all observing a single document "holder" and its active document. A main drawing interface interacted with the layout of the document, various property views that observed the selected item and provided a record interface, and a smaller scale representation of the main view that showed the entire document instead of just the visible window. Some of these views had controllers of varying complexity that turned GUI events into changes to the document, which would in turn notify its various views.
Can you still call such a relationship a "triad"? Perhaps, but I think it implies too much of the former, older application of MVC.
Could you share controllers with different views? Depends on how similar the views are. I've found that generally speaking this type of object has behavior to specific to the view it's controlling AND the model it is manipulating to be very reusable...but there's always exceptions.
Best Answer
There's a third option, start by writing your tests. It's the better option, and it's not specific to MVC. If you do start by writing tests, then the next step depends on your approach to MVC:
Fat controllers / skinny models
Your controllers do all the heavy lifting, while your models are essentially POPOs, tasked with maintaining state between requests.
Skinny controllers / fat models
Your controllers are limited to passing stuff around, most (if not all) of your business logic lives in your models.
CodeIgniter favours the first approach but it doesn't restrict you from the latter one. It's completely up to you which one you'll follow, personally I'd strongly suggest the second approach, simply because with fat models you'll get the chance to test your business logic very early in the development cycle.
With skinny models, you'll have to build both your controllers and your models before you'll be able to test your business logic, and that's not particularly efficient. Your business logic is the more important part of your application, I think it's obvious that the sooner you build and test it, the better.
To summarize, my workflow is:
Further reading: