I’m the lead architect on a large CRM project that is about to start the Design phase (or in my RUP world, “Elaboration”), and my PM asked me what architectural tasks belong in her project plan for this phase of work. I don’t always get asked this question on projects as there’s usually either a large “system design” bucket, or, just a couple high level tasks assigned to the project architect.
So, I have three options here:
- Ask for one giant “system design” task that goes for 4 months. On the plus side, this let’s the design process be fairly fluid and doesn’t put the various design tasks into a strict linear path. However, obviously this makes tracking progress quite difficult, and, would force the PM to add 5-10 different “assigned to” parties because the various design tasks involve different parts of the organization.
- Go hyper-detailed and list every possible design milestone. The PM started down this path, but I’m not a fan. I don’t want every single system integration, or software plug-in choice called out as specific tasks. Those items must be captured and tracked somewhere (of course), but the project plan doesn’t seem to me to be the right place. It makes the plan too complicated and cross-referenced and makes maintenance such a chore for the PM.
- List high level design tasks which allow for segmentation of responsibility and milestone tracking. I naturally saved my personal preference for last, because that’s typically how my lists work. In this model, I break out “system design” into its core components.
So I provided the list below to my PM. I broke out each core task and flagged which dependencies are associated with each. If you “mouseover” the task title, I have a bit more text explaining what the details of that task are. Some of these tasks can and will happen simultaneously, so don’t totally read this as a linear sequence. I’d be interested in all of your feedback.
| Task | Dependency | ||
| 1 | System Design | ||
| 2 | Capture System Use Cases | Functional requirements
Non-functional requirements |
|
| 3 | Record System Dependencies | Functional requirements | |
| 4 | Identify Data Sources | Functional requirements | |
| 5 | List Design Constraints | Functional requirements
Non-functional requirements [Task 2] [Task 3] [Task 4] |
|
| 6 | Build High Level Data Flow | Functional requirements
[Task 2] [Task 3] [Task 4] |
|
| 7 | Catalog System Interfaces | Functional requirements
[Task 6] |
|
| 8 | Outline Security Strategy | Functional requirements
Non-functional requirements [Task 5] |
|
| 9 | Define Deployment Design | Non-functional requirements | |
| 10 | Design Review | ||
| 11 | Organization Architecture Board Review | [Task 1] | |
| 12 | Team Peer Review | [Task 11] | |
Hopefully this provides enough structure to keep track of key milestones, but not so much detail that I’m constantly updating the minutiae of my progress. How do your projects typically track architectural progress during a design phase?
Richard Seroter's Architecture Musings 
Nice high level plan! Most of the tasks seem to focus on the perimeter of the solution though. This will give you a nice crispy system boundary shell that plays nice in the landscape, but I’d add a task or two so you don’t end up with a squishy center!
Maybe add the delivery of a high level internal component model which will actually help drive some of the other tasks you have. For example, it will show which components support your interaces, help drive technology selection and influence your deployment. You can also make a technical risk assessment which will drive the planning for any needed PoC’s, which your PM will be very interested in.
Good point Ian. I should add the “functional decomposition” model to the list. Technical risk assessment is a good deliverable, but wondering if that is something maintained throughout the project, and thus tough to pin down for project planning purposes.
We typically use the Architecture Essentials Practice of EssUP to help drive through the architectural processes.
Following up Ian’s point this typically leads to identifying key architectural risks very early and finding ways to mitigate them. This can be as simple as a COTS product review and selection or as complex as looking at the key critical paths in the business use cases and creating a PoC that is a spike through the system to drive out the areas of design with highest risk.
We’d usuall do this pretty early on in design so it can help drive the development and iteration cycles, identifying and addressing key risk early.
I usually like getting some of this activity on a plan because showing a customer you’re addressing risk early can only ever be good!
I love squishy centres 🙂
Depndencies are everything. Avoid the problem we have on the project I’m currently engaged on. In order to release money to fund the next stage of the project, we have to first pass a critical design review. What is that next stage? Elaboration. The first ‘bucket’? Produce the high level and low level designs.
Go figure.
What we’re doing is creating user stories in the backlog (with a first version during the business case). We try to detail those based on our experience.
Hi Richard
I think the point above about risks is a good one. Although the risks are usually maintained throughout the project most places ive worked usually take a snapshot of the risks at key milestones for auditing purposes and project reviews.
I would normally expect that your team identified some technical risks during inception and will probably find some more during elaboration (or what ever your methodology calls them). I think in your current phase if you have risks that warrant a proof of concept to mitigate the risk you should outline these in your plan just to say you have n number of POC’s and if it will be done now or in a later iteration.
What sort of architectural deliverables do you hand over to the development teams? UML use case and activity diagrams? Schema stubs?
Hi Dave. We typically handle over a System Design Specification which includes system use cases, corresponding activities diagrams, dependency models, interface models, and in some cases, WSDL or data structure stubs.