Part of what makes me a professional developer, in my opinion, is the fact that I always make it a point to learn and evolve. When what I knew and was certain of yesterday becomes intertwined with some new thing I learn today, great things happen and my understandings and persepectives change. Recently, that very thing occurred regarding my mindset on how to approach any new development project, so I thought I would share the experience and the results.
First, Some Definitions
(User) Interface-Driven Architecture (aka IDA, care of Mr. Clark Valberg, esquire :) )
(User) Interface-Driven Architecture means that the first thing I do is create a visual, hopefully somewhat interactive prototype of what my finished product will be; I build a mockup of the GUI that demonstrates and represents the functionality of the app as seen from an end user's perspective. At this time, I don't even think about the code that will power the app (at least I try hard not to), but rather focus on the end results. Once the prototype is approved by the client, it is then reverse engineered by the architect and transformed into a living, breathing application.
Model Driven Development
Model Driven Development takes an opposite approach. Forcing yourself to not even consider what the user interface might look like or how it might behave, you architect the application's model based solely on use cases, static class diagrams, and whatever other artifacts you have been given that describe what goals the app will accomplish.You remove yourself so far from the user interface, in fact, that you architect your classes in such a way that ANY user interface could consume your API and all scenarios, present and potential, would be covered.
A Little History
My earlier development years were spent coding mostly by instinct, as I had no formal training on the subject, no mentor whom I desired to emulate, and nobody telling me how they wanted me to do it. So, depending on the project and what kind of direction had been given me, I would often find myself starting a project in different places. If I had been given a clear scope of the functionality the app was to provide, I would typically begin by designing a relational database schema to accommodate that scope. If someone had drawn me a picture on a napkin and handed it to me telling me to "build this", I'd start with an html GUI that simulated functionality so that I could make sure the vision of the requester was the same as mine. And if I was left to my own devices as to how I would approach development, then it just depended on whether or not I was in the mood to design a database or write code as to which I did first.
The next natural step in my personal evolution was to attempt to leave chaos behind and adopt standards and methodologies to allow me to be more efficient and DRY. This abandonment of solely using instinct as a methodology (which actually didn't work too badly for me) occurred when CF 7 was about 6 months old. At this point I began listening to the OO buzz, attending conferences, opening my mind to ideas and concepts that were new to me, and leveraging CFCs and frameworks; all in an effort to apply rhyme and reason to my approach to development. Even so, there was still no clear starting point; every project began differently.
So, about two years ago, I settled on the fact that (User) Interface-Driven Architecture was THE way to go. By designing the customer-approved, semi-functioning GUI first, I could avoid the developer's most arch nemesis, Scope Creep, and ensure that both the customer and myself both had the exact same end result in mind. It makes perfect sense, right? It does indeed. But, does it always? This is where my road forks.
For the past six months, our local RIA user group has been building a media player as a group using AS3. The group manager is basically leading the sessions, as he is a seasoned AS3 architect, and it has been within these sessions that I have come to see and appreciate the value and application of the Model-driven approach. It all gelled for me during our most recent session when one of the attendees who was having some difficulty following the abstractness of the classes and their relationships raised his hand and asked that we stop working on the model and build the GUI that would consume it. For him, seeing the GUI would help him assimilate all of the model pieces we had been writing for the past several months. The group manager then took a moment to expound upon why he thought it good to purposefully NOT create the GUI. In a nutshell, creating the model with the GUI in mind would cause us to design a backend that would be limited to only what the GUI needed and would hinder our creativity as we thought out the specifics of our model's behavior, organization, and flexibility.
The two poles of my thinking collided at that moment, and out of the momentary synapsial confusion that followed emerged the same two ideas, intact. This time, however, rather than me viewing them as opposing ideas where only one could rule, I saw them as inverse to one another, yet equal in their relevance and application. Which one ruled, then, depended entirely upon the circumstances and goals of the specific project at hand.
(User) Interface-Driven Architecture evolved in response to the need to help clients answer the one question they have such a hard time with: "What is it that I really want?", and it is in this context where this approach rules. With a visual, interactive interface in place at the beginning of the project, there is little room for unplanned scope creep to stall or even derail a project's progress. If the goal then of the project is to "build this customer exactly what he wants", then this is definitely the approach I would go with, hands down.
In the opposite universe, there are times when the goal of the project is to produce something more of an enterprise nature that must be able to expand and contract, bear dynamic loads, and present a consumable API to third parties of unknown origin. This scenario then clearly shines the spotlight on the architecture of the model. Although the user interface always matters, if we were to design it first and then attempt to build a model that accommodated only its needs, we would in many senses be forcing ourselves to think inside of the box that the GUI built around us, and thus likely end up with a product much less robust than it could have and should have been. For a project such as this, then, I say that the Model-driven approach is the way to go, hands down.
Conclusion
As you can tell, I still feel very passionate about (User) Interface-Driven Architecture, and will continue to use it and apply it where I see it as a best approach. It is very sound, and very effective at producing happy customers and a nearly unmovable project scope, except where it is concentual. I now also feel very passionate about Model Driven Architecture as well, and find it to be a more liberating experience, if you will, when designing applications of a grander, more enterprise scale. This approach places absolutely no bounds on your ability to explore possibilities and configurations, the only confines at all (if you can call them that) being the resulting API your project will expose, if one is to be created.
Of course, I'm always learning and evolving, and one day in the future I may have a completely new perspective on application architecture. It never hurts, though, to share your epiphanies along the way; you never know what will be produced when your epiphany collides with someone else's universe.
Keep evolving, my friends.
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
It is primarily when you don't know who your client or potential clients are that model-driven architecture is most important. Though that's not at all limited to "enterprise" applications. It could just as easily be an app for small businesses, in which case the flexibility of a model-driven approach may be even more important because there are more potential clients and likely a wider variety of different kinds of clients who might license your software.
---
"(User) Interface-Driven Architecture evolved in response to the need to help clients answer the one question they have such a hard time with: "What is it that I really want?"
---
This is true, but only *partially* true! In fact, I would say it is only 30% of the picture (33.33333% anyhow).
* The first part is to do just that - help the client understand what they want... as they first envisioned it.
* The second part, which might be even MORE critical is that it helps the developer and the client to be on the same page so that there is as little miscommunication as possible (what you eluded to in the background info).... one of the biggest causes of software failure.
* The third part, which is also *hugely* important, is that the IDA process provides a platform on which evolutionary and innovative conversations about the software can be had. Because it is the marriage of high-fidelity design and agile development, new concepts can be explored, scratched, re-envisioned, and fleshed out with less cost and effort. Once you start writing real code underneath, this agility is lost... and a lot of the ability to innovate with it.
The second issue I have ties into my previous bullet point:
---
..."creating the model with the GUI in mind would cause us to design a backend that would be limited to only what the GUI needed and would hinder our creativity as we thought out the specifics of our model's behavior, organization, and flexibility."
---
This, I feel, makes the large assumption that GUI in mind is anywhere near accurate or fitting to the client's needs. If the IDA process has shown us anything it's that 1) the client doesn't know what they want, 2) we rarely understand the client's business or what they want, and 3) we are only able to have truly innovative connversations when we have a high-fidelity prototype in front of our eyes. As such, basing anything on the assumption that an existing GUI has any "correctness" to it feels to me to be a very slippery slope, and directly opposed to all the reasons we love IDA.
Also, the concept of "what the GUI needed" is a non-issue; the GUI doesn't need anything - it's the *client* that needs stuff. And ultimately, the software is ONLY successful if it does what the client needs.
... sorry if this seems overly emotional. I have been living this for the past 2 years and would never change the way I develop.
Thanks for taking the time to comment! If anybody knows the IDA approach, it's you and Epicenter.
Your point 1: I totally agree with you and feel more educated on that perspective now. :)
Your point 2: Just for clarification, my statement is based on the hard fact that at some point in the IDA process, there IS a final prototype upon which both the client and developer agree accurately represents what the end product should be...correct? At least that's how I implement the IDA process, but I could be using some home brewed hybrid (wouldn't be the first time I did that!). Based on my understanding of IDA, then, what I meant by the statement "what the GUI needed" refers to very specific pieces of functionality. If, for instance, one part of the GUI is a user administration screen that adds, modifies, and deletes users, and allows the admin to assign specific privileges to users, then "the GUI needs" a model that will add a user, delete a user, modify a user's attributes, and preserve n number of permissions assigned. I guess I was thinking more specifically when I shared that statement, not so much "big picture".
So then, do you agree that one of the largest milestones in the IDA process is creating a rich prototype that accurately represents the final product to such a degree that any developer could look at it and from it accurately derive the required CSS AND the backend model to support that GUI? If that is true, then I believe it is highly likely that the developer contractor I select would probably deliver to me a model that accommodates that GUI and probably nothing more (unless I specifically asked for it). If the understandings and assumptions outlined above are correct, THAT is where I derive my point of view that a model created based on a GUI will be limited in scope and functionality, and lack the more liberal creativity that a model-driven approach would provide.
Tag. :)
Yes, there is a point at which a "version" of the prototype is considered done and then the software is fabricated off of that. And, as much as we think of the prototype as the spec document, I would not expect someone to be able to build a model solely based on the prototype; there will always be things that cannot be expressed graphically, especially as the workflow gets more complex (or even simple things like *who* gets emailed when this action happens). It is important to have some sort of "story" that goes along with the prototype. .... HOW that story gets delivered???? We're still figuring out how to best do that :) We're working on a visual annotation system, but that only rough ideas right now. We've managed so far because we usually handle both the architecture and the fabrication process so the knowledge is kept in-house.
If I may play devil's advocate for a moment, though, the one hitch behind IDA is that it is so subjective. Theoretically, an interface could always be made more effective; but, at some point, you have to not let Best be the enemy of Good and just decide that its good, if perhaps only to say that it's good for "version X".
That said, intentionally thinking in terms of "Versions" is also good and somewhat addresses the point you make about the model being only as big as the GUI requires. It's always a good thing to think about the future and scalability. I don't think the IDA process helps OR hurts this. I could (read: have) built systems using both old-school and IDA approaches that are not particularly future-proofed; but I think that's more about my level of coding, not the process I used (hey, I'm learning new stuff every day).
And of course, there's always a time and a place to use something and not to use it. But, I might go the reverse - the more "enterprise level" and mission critical something becomes, the more I would advocate prototyping; the more simple, the less mission-critical something is, the more I might just slap something together, code first.
And that's all I have to say about that.
:)
Another great posting, as usual.
My hope is that people who read this will understand that at the very least, a great way to nip scope creep in the bud is by using Interface Driven Architecture. I've saved many, many hours with clients over the last few years since I've adopted a similar approach:
I build the screens, on each screen beneath it I print out, in bullet points, the exact functionality to be wired into the screen. Finally, and this is the biggie.... I make the client initial and sign off. They appreciate it, because they've taken the printouts and passed them around to their colleagues who told the project guy what I should build. There's a minimal level of accountability, much less gray, more black and white and I'm protected since, should they come back and say "we forgot that we need X, Y and Z..." then I amend my invoice, which is completely understandable to all parties involved.
I had a much more difficult time accomplishing this same thing with a Model Driven approach, so ironically I find myself incorporating the 2 ideologies at some point.
My 2 cents worth, keep up the great work and thanks for your postings!
Rich