How to identify abstraction and scope for architecture and design respectively?

Question

I am in the architecture phase of my project. My challenge is that I am unable to maintain a certain level of abstraction at present. I often creep into areas that we generally address as part of design.

I don't know where to stop thinking & elaborating ... therefore I end up articulating very fine details of the solution which will directly be usable to the programmers. In the process I am losing the big picture (vision) and stretching time exclusively dedicate for the purpose of architecture.

Are there any ways / methodologies / approaches that can be used to restrict myself within boundaries of architecture while I am addressing it and likewise for design when I am in design phase?

Answer 1

I am afraid the only real answer is practice; practice; practice. However, I found that when considering distribution of topics between the different areas, it is useful to continually remind yourself of three things.

Firstly, try to keep in mind, all the time, what level of task you are currently working on. When considering any part of the architecture/design, keep saying (to yourself) - is this an appropriate topic for THIS task. (As an example, the project I am currently working on, requires the specification of a parser parser. This is essential to the architecture, but I failed to remember for a long time that the output of the program was a parser, rather than the description of the grammar.)

Secondly, simplify. I have found that both good design and good architecture tend to be simple - they tend to lead to an "aha" moment - it is obvious that this is the way to go. This does mean (particularly when working on architecture) to be prepared to reorganise things; to remove things from the architecture - into a "good idea fragment" location, so that you can go back to them. Remember also that if you have the appropriate level of abstraction, then even a very simple system description will have substantial depth.

Thirdly, keep track of your thinking, your ideas, your proposals. This need not be very elaborate - I use a textual diary format, timestamping entries as I make them. I capture things that seem to be significant at the time. I don't go back to it a lot, but I do go back, particularly if there is a break in my thinking. This tool is for my own personal use - it is not something that I make available to others.

Finally, delving too deep into design when working on architecture, may well be part of the process. One needs to really understand the implications and requirements you are trying to satisfy, and sometimes the only way to do this is to go deep. Just remember to surface yourself, be prepared to park elsewhere the results of going deep, and integrate the results of your investigations into your architecture - at an appropriate level of abstraction of course.

EDIT:

As far as tooling goes, I have found tools to aid thinking of most assistance. Mind mapping software such as Mind Manager; UML tools such as you mention; whiteboard type tools, where items can be placed and moved around and amended with the same facility as a whiteboard; and (if in corporate environment) brainstorming meeting software. I can't give references to these latter tools, because my knowledge is severely out of date. Also, putting all your notes under version control, separated by task into different projects can be of help.

As part of the project I mentioned originally, I am trying to develop a number of tools which will aid in this sort of process. The tools will be integrated by reference to a models of the architectural, design, and build processes. However, this is a recreational project with a sole developer, myself, and I am not yet at a point where I can provide tools.

Answer 2

Take a step back - you're at the architecture phase, so what are the deliverables that this phase needs to produce? Do you know who the stakeholders are in your project that you need to deliver to? - what they need / expect? The point I want to make is that if you haven't clearly identified what it is you need to do - it won't get done (regardless of what method you use).

Restrictions / Keeping yourself on target

A good architecture will go through 3 levels, and these are a good basis for an approach:

• High-level direction: do whatever it takes to verify (and be able to justify) a given direction. What sort of system do we build? A desktop system that is used by staff ion the office or one that can be used by remote users anywhere in the country-side?
• Logical options: stay completely away from implementation details, focus instead on identifying the major components that you'll need. We need to store data, we need to authenticate users against this existing external service, we need to provide a UI.
• Physical options: this is where you get into the detail of spelling out what is to be used. To jump back into an IT metaphor: are we using an entity mapping framework, rolling our own or re-using a pre-built in-house one?

For all of these you should be able to find reference architectures or "prior art" of some kind which backs up your approach.

Inputs into these 3 steps can be considerable, and should include:

• The context (everything about the environment the solution needs to work in): size of user population, distribution, technical maturity (both of the users and the staff who will support it), data sensitivity, nature of the business and how the system relates to that - does the system handle real-tine medical records (matter of life and death) or is it a wiki?
• Non-Functional Requirements (a): Identify the top 3 in order of priority as this will be a key guide for making architectural decisions. Is performance the most important? Or security? Availability? These will be driven by the context.
• Non-Functional requirements (b): these will also be driven by the context but they also provide (hopefully testable) marks that you need to hit: how fast, how available how usable, how it handles DR.

Outputs you should be able to provide (so think about how you can do these) include:

• Some sort of Solution Architecture Definition. usually is a formal doc but might not need to be. It should include information that addresses the "views" relevant to the solution / problem / context: the logical view of system components including external interfaces and systems you interact with, a physical view of where the components of the system will be deployed, if you're writing software you'll also need to describe how that software is divided up into physical packages that can be deployed, security, data and so on.
• A Decisions Register: this will be a living register that you add to throughout the life of the project. Use it to explain why certain decisions were made. This both protects you if you're challenged at any point, and will help you / others in 6 months time when an issue comes up and you need to remember why you did what you did.

Details & Design

Design is where you get into detailed specifics, this could include patterns to be used at the object level, and so on. This is the time and place where you might find yourself providing reference implementations: this is how we need to structure our services, etc.