Software Architecture Process: How do you don't get lost...

[AlexCode]

The architecture phase of a software development process is a complex thing. Even on small applications we must think a bit ahead, predicting difficulties, defining patterns, defining technologies, etc. Ideas must be well organized so we don't get lost within the line of thinking. I have my method that can be described by: 1- Make a sketch on paper of the overall scenario 2- Write about what the application is supposed to do 3- Create some workbench projects to test eventual areas that I'm not comfortable with 4- End up with a pros and cons on the possible/available implementations 5- Decide about the technologies to use (DB Engine, dev language, etc) The only software I sometimes use is Visio to store my sketches or Office OneNote on my TabletPC. Now I want to ear from you guys... How do you structure your architecture process?:doh:

[Marc Clifton]

AlexCode wrote:

How do you structure your architecture process?

A 12 step program, something about accepting the things I can't control, is a good start. ;P Seriously, trying to answer this question is harder than you think because the process has become so ingrained in me, it's actually hard to quantify it nowadays. That's probably a bad thing. I decided a while ago that the whole design process comes down to one simple (or not so simple) quality: communication. I have to be able to express the concepts clearly from a high level all the way down to the lowest detail level. Basically, your steps 1 and 2, but with a lot of emphasis on those two steps. So, I'm what you might call a "communicatist". I believe that if you can't properly communicate the concept, then you don't understand it yourself. And you need to be facile with different communication mediums--words, graphics, UML, etc. And it's an iterative process, repeatedly refining your communication, and a recursive process, drilling down into finer details. The end result is something that isn't necessarily perfect. Rather, it's something that is capable of dealing with the reality of change and challenges, both technological and "social" (the human interface side of things). So, for example, your item #4, pros and cons, and #5, decide about technologies--to me that's bad architecture--an architecture should be flexible enough to handle a variety of implementations, a variety of technologies, because that's what you'll be faced with in real life. So for me, architecture is not about deciding on tech A vs. tech B, it's about communicating up to the point of the decision, which, if you communicate clearly, you should be able to create an architecture that can handle a variety of decisions. Not all, because that's impossible, but at least many. Marc

Thyme In The Country
Interacx
My Blog

[Patrick Etc]

Marc Clifton wrote:

The end result is something that isn't necessarily perfect. Rather, it's something that is capable of dealing with the reality of change and challenges

To me, that's the definition of perfect. Perfection isn't a static state but a process... least that's how I look at it.

Marc Clifton wrote:

So for me, architecture is not about deciding on tech A vs. tech B, it's about communicating up to the point of the decision, which, if you communicate clearly, you should be able to create an architecture that can handle a variety of decisions.

I'm currently working on a project that originally only required data input from a serial port. Soon after, simulation files and bluetooth were added as possible inputs. When I realized what might happen later, I rewrote the architecture to accommodate any communications medium (within reason) so that the data processing would be communications agnostic and a new communications method would only require creating a new subclass and overriding a couple of methods. Specific examples aside, I'm finding myself leaning exactly the way you're describing. I think that eventually, for those who really care about the quality and maintainability of your software, it's inevitable.

[alex barylski]

If I understand correctly, I agree with Marc, in that architecture doesn't really need to include implementation details, such as which technology to use, etc. I personally don't keep a list of pros/cons of implementation specifics or patterns required. I keep those details in my head as I find they change most frequently. So long as I can communicate what patterns are required and where/why as well as which implementation to use, thats good enough for me. I usually sketch out the majority of the interface on paper and begin to write validating XHTML right off the hop (web apps). Around the same time as drawing the interface I begin planning the model. From this point I can usually begin finalizing the interface and wiring togather the models/controllers/views. I try not to plan much. I prefer frequent refactoring as required (such as the model API which I find is most likely to change).

I'm finding the only constant in software development is change it self.

[AlexCode]

I don't know but maybe we're thinking of those items #4 and #5 in a different way. At some point we must decide about the tools that will be used to do what we idealized before. Some times we even face technological limitations that will leave us no choice but redefining some aspects of our architecture.

[AlexCode]

Hockey wrote:

I try not to plan much. I prefer frequent refactoring as required (such as the model API which I find is most likely to change).

This is probably the most used method, but when used on bigger projects can lead to a disaster. If a refactoring process must be done on a software that already is partially implemented on customers can be a vary nasty thing to explain and harder to execute. I usually develop thing in modules, using the Plug-in architecture a lot. I also user the "Adapter" model to implement functionalities that may vary or evolute in time. These two are my main safety bags in the development process.

[Marc Clifton]

AlexCode wrote:

At some point we must decide about the tools that will be used to do what we idealized before.

True, however, I tend to design architectures that look at the tools available and then architect a level of or two of abstraction so I'm not bound to a particular too.

AlexCode wrote:

Some times we even face technological limitations that will leave us no choice but redefining some aspects of our architecture.

In the situations where I've experienced this (most recently when dealing with DVD's and video playback) I've discovered that I didn't know enough about the technology limitations and had not designed an appropriate architecture to begin with, particular in the areas of error detection and error recovery. However, once the architecture was fixed, the whole application began working better as even further technology limitations were discovered. So, in the final analysis, I would conclude that my architecture was flawed because I didn't understand the situation well enough to begin with and communicate the requirements. Basically, I expected these third party tools to "just work". Sigh. How I fell for that, I don't know. Marc

Thyme In The Country
Interacx
My Blog

[AlexCode]

Right... and here we go into the swamp. As we add abstraction to our architecture we face productivity problems. Dealing with a, lets say, 10 developers team, and introduce an architecture with an high level of abstraction can force you to have better developers (more expensive) than the project can handle or you want to pay. The architecture paradigm can be very complex, and I'm not only talking about how to develop.

[Marc Clifton]

AlexCode wrote:

Dealing with a, lets say, 10 developers team, and introduce an architecture with an high level of abstraction can force you to have better developers (more expensive) than the project can handle or you want to pay.

You raise a good point, but one that I ultimately disagree with. I've been in a situation a couple years ago where my architecture was rewritten because the inhouse staff couldn't understand my abstraction. However, in the long run, the abstraction does pay, I've found. That same company, after two years and who knows how many rewrites (I left them about that time) still does not have a product out, and this is after throwing 7-10 programmers at the job fulltime for those two years. As a comparison, I've developed applications with good abstraction and found that the development goes faster, can be done with fewer people, and is resilient to change. Conversely, it does require two things--above average programmers and one person that drives the architecture and makes the final decisions. Software design by committee is asking for a disaster to happen.

AlexCode wrote:

The architecture paradigm can be very complex, and I'm not only talking about how to develop.

Again, it seems like that up front, but I disagree. I've never found architecture to be complex. You perform an analytical process to reduce things to core components and you perform a synthesis process to abstract the components and an infrastructure allowing those components to communicate with each other. In a very real sense, I've found that a well architected application is truly greater than the sum of the parts. Marc

Thyme In The Country
Interacx
My Blog

[AlexCode]

For me, to be a Software Architect is to: 1. Be the face for the customer right after the commercial department gets in 2nd place 2. Define how the application will be done 3. Define the tools needed and choose 4. Estimate the time needed to execute mostly based on: 4.1. What do do 4.2. Milestones 4.3. How many people and what the capabilities of who will execute it 4.4. ... 5. Give a price for the job 5.1. Get back to point 3 if needed to adjust price or time If you're working for the company that will execute: 6. Define who will do it 7. Build a team with the chosen ones 8. Get it started If you're part of the team: As I never worked on a team where I was "only" an architect, I always impersonate the Project Manager or the Team Manager person depending on the team size and a developer. For me this is the very basic process to have any warranty that the project will be delivered on schedule and on budget.