Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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).</p> <p><strong>Restrictions / Keeping yourself on target</strong></p> <p>A good architecture will go through 3 levels, and these are a good basis for an approach:</p> <ul> <li>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?</li> <li>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.</li> <li>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? </li> </ul> <p>For all of these you should be able to find reference architectures or "prior art" of some kind which backs up your approach.</p> <p><strong>Inputs</strong> into these 3 steps can be considerable, and should include:</p> <ul> <li>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?</li> <li>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.</li> <li>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.</li> </ul> <p><strong>Outputs</strong> you should be able to provide (so think about how you can do these) include:</p> <ul> <li>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.</li> <li>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 <strong>why</strong> you did what you did.</li> </ul> <p><strong>Details &amp; Design</strong></p> <p>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload