Comments on: On the Topic of System Architecture… https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: barneyb https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1557 barneyb Fri, 15 Dec 2006 20:38:58 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1557 Peter, I definitely agree. For simple web apps a UI-centric approach is quite appropriate. That's really the central tenet behind FLiP: the UI is the application. I wasn't very clear (mostly because it's obvious to me, I suppose), but the app I've been working is not of that paradigm. The primary objective of the process has been to create a application platform that the company can use for the next 7-10 years, not so much on creating a new version of what we have today. THe UI has been something of an afterthought, exposing enough to replace our current product, but leaving the majority of the advanced functionality hidden, waiting to be exposed down the road. Peter, I definitely agree. For simple web apps a UI-centric approach is quite appropriate. That's really the central tenet behind FLiP: the UI is the application. I wasn't very clear (mostly because it's obvious to me, I suppose), but the app I've been working is not of that paradigm. The primary objective of the process has been to create a application platform that the company can use for the next 7-10 years, not so much on creating a new version of what we have today. THe UI has been something of an afterthought, exposing enough to replace our current product, but leaving the majority of the advanced functionality hidden, waiting to be exposed down the road.

]]> By: Peter Bell https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1556 Peter Bell Fri, 15 Dec 2006 20:24:16 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1556 Duh - take foot out of mouth. DDD is Eric Evans - Mr. Meyers is Mr. CSS. And while I'm not sure it was clear, I was suggesting that DDD is often NOT an optimal approach for web apps as you spend too much time learning stuff that you don't absolutely have to know. It's lovely if you have the time, but for the clients and price points I work with it's a luxury we can't justify! Duh – take foot out of mouth. DDD is Eric Evans – Mr. Meyers is Mr. CSS. And while I'm not sure it was clear, I was suggesting that DDD is often NOT an optimal approach for web apps as you spend too much time learning stuff that you don't absolutely have to know. It's lovely if you have the time, but for the clients and price points I work with it's a luxury we can't justify!

]]> By: Peter Bell https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1555 Peter Bell Fri, 15 Dec 2006 20:22:12 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1555 Hey Damon, I was just reading Eric Meyers domain driven design and I'm a fan of screen based elicitation of requirements for web apps. The truth is you don't need to know the domain. You only need to know how to create the screens, actions and steps to support the use cases for your application. We've developed a process similar to FLiP but a little broader (and honestly it was more influenced by our own experience, 37signals, Use Case modeling and Feature Driven Design than anything else). I wrote something about that for CFDJ: http://coldfusion.sys-con.com/read/311316.htm Bottom line is I think a screen based approach is typically more efficient for apps where UI is the core of the application and other approaches fit better for apps where UI doesn't capture much of the complexity inherent in the problem space. Hey Damon,

I was just reading Eric Meyers domain driven design and I'm a fan of screen based elicitation of requirements for web apps. The truth is you don't need to know the domain. You only need to know how to create the screens, actions and steps to support the use cases for your application. We've developed a process similar to FLiP but a little broader (and honestly it was more influenced by our own experience, 37signals, Use Case modeling and Feature Driven Design than anything else). I wrote something about that for CFDJ:

http://coldfusion.sys-con.com/read/311316.htm

Bottom line is I think a screen based approach is typically more efficient for apps where UI is the core of the application and other approaches fit better for apps where UI doesn't capture much of the complexity inherent in the problem space.

]]> By: barneyb https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1512 barneyb Fri, 15 Dec 2006 17:09:13 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1512 A good question, Damon. I'm going to defer until I can spend a bit of time on the topic, as I think it warrants more than a "from the hip" comment. In a nutshell, however, comparing the two is like apples and oranges; they're targeted at rather different aspects of development. A good question, Damon. I'm going to defer until I can spend a bit of time on the topic, as I think it warrants more than a "from the hip" comment. In a nutshell, however, comparing the two is like apples and oranges; they're targeted at rather different aspects of development.

]]> By: Damon https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1511 Damon Fri, 15 Dec 2006 17:00:11 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1511 Barney, Nice post. Always glad to read about people's real-world experience with application architecture and design. My question to you is this: How would you compare the Rational approach (UML, Sequence Interface Diagrams, Use Cases, etc..) with FLiP? In my experience, the Rational approach doesn't really fit well with 'web' application development (too time consuming, too much documentation that gets tossed out, etc..). On the other hand, FLiP has its own shortcomings in that it doesn't require (or even suggest) that the architects do much documentation beyond wireframes, prototypes, and fusedocs (or their equivalent). Barney,

Nice post. Always glad to read about people's real-world experience with application architecture and design.

My question to you is this: How would you compare the Rational approach (UML, Sequence Interface Diagrams, Use Cases, etc..) with FLiP? In my experience, the Rational approach doesn't really fit well with 'web' application development (too time consuming, too much documentation that gets tossed out, etc..). On the other hand, FLiP has its own shortcomings in that it doesn't require (or even suggest) that the architects do much documentation beyond wireframes, prototypes, and fusedocs (or their equivalent).

]]> By: Peter Bell https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1469 Peter Bell Fri, 15 Dec 2006 14:52:02 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1469 Hi Barney, Nice post and sounds like a cool project to have worked on! Just gotta say +1 for the pencil sketches. most of what I've been doing on my blog in the last month is "refactoring ideas" as there are certain very fundamental design choices that are extremely influential and a lot harder to refactor when embodies in code than when they're just a set of musings or whiteboard drawings. If you're just building another cms like the last 40 you did, it isn't so important, but if you're doing something either fundamentally new (or fundamentally new to you) I'd argue well over 80% of the project is done on paper. It was like writing LightWire. I'm gonna say it took me 50 hours to really grok DI, and the code base took less than 10 hours to write - including a fairly length false trip into pseudo constructors. Same with application generation. If the concepts are elegant enough, the rest is just metadata and a little bit of code . . . Hi Barney,

Nice post and sounds like a cool project to have worked on! Just gotta say +1 for the pencil sketches. most of what I've been doing on my blog in the last month is "refactoring ideas" as there are certain very fundamental design choices that are extremely influential and a lot harder to refactor when embodies in code than when they're just a set of musings or whiteboard drawings. If you're just building another cms like the last 40 you did, it isn't so important, but if you're doing something either fundamentally new (or fundamentally new to you) I'd argue well over 80% of the project is done on paper.

It was like writing LightWire. I'm gonna say it took me 50 hours to really grok DI, and the code base took less than 10 hours to write – including a fairly length false trip into pseudo constructors.

Same with application generation. If the concepts are elegant enough, the rest is just metadata and a little bit of code . . .

]]> By: Matthew Lesko https://www.barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/comment-page-1/#comment-1439 Matthew Lesko Fri, 15 Dec 2006 14:27:28 +0000 http://barneyb.com/barneyblog/2006/12/14/on-the-topic-of-system-architecture/#comment-1439 Great post. In fact, the concept I think is implicit in your post applies to the whole Software Development Life Cycle. That is, creating software from problem definition through implementation is not about a specific a technique, methodology or technology. Rather it's about understanding the problem(s) you are trying to solve and then using a good selection of the aforementioned to solve them. To expand on this idea further, I recommend the article "There is no spoon: why the best software design and development process is all in your head [http://www.agileproductdesign.com/blog/there_is_no_spoon.html]", which I think captures this sentiment better than I can express. Great post. In fact, the concept I think is implicit in your post applies to the whole Software Development Life Cycle. That is, creating software from problem definition through implementation is not about a specific a technique, methodology or technology. Rather it's about understanding the problem(s) you are trying to solve and then using a good selection of the aforementioned to solve them.

To expand on this idea further, I recommend the article "There is no spoon: why the best software design and development process is all in your head [http://www.agileproductdesign.com/blog/there_is_no_spoon.html]", which I think captures this sentiment better than I can express.

]]>