Better software through software architecture and devops


Category Archives: solution architecture

  • Bournemouth Library

    So this is the second attempt at writing this post. The first was very complete but read like a textbook and it makes more sense to read a real book – I recommend the stakeholder section in this book: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives.

    All stakeholders have requirements, needs and interests which collectively I call “concerns”. I even track them in the same work item tracking system used for requirements since it means they never get lost and you can ensure traceability from concerns to requirements and architectural decisions.

    The classes can be broadly split into three groups. The first being “receivers”:

    • Acquirers
    • Assessors
    • Users
    • Administrators
    • Support staff

    Acquirers may be wanting your software for a number of reasons. They might not actually use it so their concerns are likely to be related to cost, need and satisfying other concerns indirectly, for example purchasing reporting software because a regulator has demanded accurate reporting of patient outcomes with possible penalties for failure.

    In the mental health arena there are many additional “assessor” agencies and regulators such as the Care Quality Commission, Monitor, professional bodies such as the General Medical Council and watchdogs like Healthwatch. Fortunately they are mainly concerned with the quality of healthcare, patient outcomes and overall costs; less so about software.

    Administrators and support staff want to spend as little time, money and effort as possible with your solution so anything that eases deployment, automatically heals or diagnoses issues and keeps the software running will help. Its worth looking further though – what if an administrator has a review objective of reducing disk costs over the year and you turn up asking for terabytes of clustered storage?

    The second group of stakeholders are the “producers”:

    • Developers
    • Testers
    • Maintainers
    • Suppliers

    Their concerns should be easy to list and meet since they want the same things as you. In this sample project the only producer is me and anyone who supplies me with coffee.

    The remaining category are “communicators”. The book defines them as those who “…explain the system to other stakeholders…” but I think is should also include anyone who will discuss, promote, detract, educate, deny, network, rally and gossip about your project and are not in either of the other two groups. They may only by interested in your project for their own political reasons.

    Do you have stakeholders from all these categories? If so look at things from each stakeholder’s angle and try to imagine what their needs are. Then go talk to them and confirm it.

    This entry was posted in solution-architecture  and tagged #mental-health #mental-health-project #stakeholder #stakeholders  on .
    Discuss this on Twitter or LinkedIn
  • I have a meeting tomorrow to discuss a number of deployments we have in the next couple of weeks. One thing to note is that all installations come with their own set of problems and I don’t always have the answers. However, preparation is key; as they say - “pathetic preparation makes for a piss poor presentation”.

    One thing I’m going to try is a bit of brainstorming. I’m going to draw up each installation on a white-board and we’ll list up anything that could go wrong. From that we should be able to plan for nearly every eventuality. Hopefully it won’t be a too depressing experience.

    The main stay of my deployment plans is practice. If you have done it in the office without a customer breathing down your neck then the real thing is usually much easier. We try to get hold of a backup from the customer as they usually have data-sets containing unforeseen combinations of data (especially as the source database doesn’t have any constraints - shame on you Cisco!).

    The last thing that commonly trips us up is firewalls - most of our customers are in retail or banking so security is sometimes taken to the extreme. It would be costly for us to reproduce their firewall configuration (one customer has DMZ’s around each server), so a quick tip is to use personal firewalls such as ZoneAlarm to lock down your test servers similar to a DMZ deployment.

    This entry was posted in solution-architecture  and tagged #deployment  on .
    Discuss this on Twitter or LinkedIn