Tag Archives: ITarchitecture

What I find interesting in tech in general, Apr 2022


Well, I didn’t expect this week to be “what I find interesting in IT Week” , but here we are! I hope you have found it all useful. While the other posts were specific, these are of a general nature. From weird cool stuff to mainframes to iphones to architecture. Dig in!

IT Architecture: Here’s some tools you IT architects can use:

Cloud: some cloud related stuff:

Programming: here’s some things software and hardware folks might find interesting:

Finally: here’s some links that need to be seen without falling into a particular category:

On DevOps, or the important of a good reference architecture when doing IT Architecture

If you are designing an IT system, you can greatly benefit from a good reference architecture. A good reference architecture can be:

  • a superset of whatever architecture you design
  • a guide to what is possible in your design
  • a reminder of what is essential and what you may have left out
  • an explainer of all the potentially relevant parts to your design
  • a supporter of whatever architecture you do decide on
  • like a mentor providing you thought leadership and guidance on what works and why you need it

IBM has long put together such good reference architectures. Of all I have seen, this is one of the better ones I have seen: DevOps architecture: Reference diagram – IBM Cloud Architecture Center.


It covers all the stages of DevOps, from Planning to  Deployment to Learning. It shows the logical parts of the DevOps Architecture and what tools support that. It reveals the relationships between the parts, both static and dynamic. It reminds you of the things you need that you might not be aware of. I think it’s fantastic.

I think it is great for another reason. Implicit in the architecture is the definition —  at least for IBM and I — of what DevOps should be. It’s not just CI and CD. It’s not just a toolchain/pipeline from Dev to Ops. DevOps is really this entire cycle:

Each stage is important. Too often the focus is on Development and Deployment. But stages like Planning and Learning are an essential part of the DevOps cycle  that are essential not just for code quality but testing quality and ops quality.  It all ends up with better results for all the stakeholders of an IT system, from the business sponsors to the users.

Anyone involved with IT architecture, system design, IT testing, system operations or DevOps in general would benefit from studying that reference architecture.

(Images are links to IBM pages)

What are NFRs (non-functional requirements) and why should you care?


If you have any role in the design of an IT system, you should care about NFRs.  As this piece (Nonfunctional requirements: A checklist – IBM Cloud Architecture Center), states:

Defining and addressing the nonfunctional requirements (NFRs) for a system are among the most important of a software architect’s responsibilities. NFRs are the system quality attributes for a system, as distinct from the functional requirements, which detail a system’s business features and capabilities.

Examples of NFRs include key concepts such as reliability, performance, scalability, and security. NFRs are cross-cutting in nature and affect multiple aspects of a system’s architecture. It’s important to articulate and address the NFRs early in the project lifecycle and to keep them under review as the system is produced. To help with that task, you can use the following checklist of key NFRs. The checklist designed to be consulted when you define and evolve a system’s architecture.

The bold text is key. NFRs describe the qualities your system should have. You have functional requirements and you have quality requirements (i.e. , NFRs). Any system design needs to address both.

The number of specified NFRs your system can have are endless. Three of the key ones found at the top of that list are:

Those three are typically covered in any system design I work on. The piece goes on with a great rundown on the various NFRs you’d expect to address in most system architectures.

Three NFRs missing from that list that I think are important and that I would ask you to consider are:

  • Accuracy
  • Maintainability (related to complexity)
  • Cost

There is often a tradeoff with accuracy and other NFRs, such as performance. To gain better performance, data will often be cached and served up even when it is out of date (i.e., inaccurate). That may be fine. But accuracy should always be taken into account and not just assumed.

Maintainability is often ignored, but it is key for the long term success of a system. Two examples of this. One, developers will sometimes not externalize values in their code; changes to the code require a fix and an outage. That is less maintainable than code with external values in a simple text file that can be changed on the fly. Two, code that is not well documented and not peer reviewed will be harder to maintain. Externalization, code reviews and documentation are examples of maintainability requirements you may have and should have for your IT system.

Cost is an important NFR because it causes tradeoffs with most other NFRs. For example, without cost considerations, stakeholders might have availability requirements that are for 99.99999….. It’s only when cost (and complexity and maintainability) become factors do we see often see availability (and other NFRs) scale back.

Finally, NFRs are not just for software architects: they are for everyone. In fact, I wish the term “non-functional requirement” was replaced with “quality requirement”. However I suspect software architects — for whom functional requirements are key — came up with that term, so we all have to live with it. When you think of NFRs, think Quality Requirements. Everyone involved in the design of an IT system wants it to have good quality. Understanding the NFRs/QRs are key to this.

 

Tiny DOOM! And other things I find interesting in tech, February 2022


I’ve been doing work in a number of areas recently: IT architecture, Azure, Kubernetes and more. As I do that, I collect a number of links, which I have below. As well, I put together some Raspberrry Pi links, because I love my Pi. Also DOOM because I will always click on a DOOM link. Lots of good material. Let’s review!

IT architecture: I’ve been thinking much about IT architecture these days, and I’ve been writing about it here: BLM on IT. One thing that helped me think about it was this: 5 diagrams you need to document your solution architecture. This is also helpful: Editable architecture diagram resources: IBM IT Architect Assistant. In addition, something on DDD:  Apply Domain-Driven Design to microservices architecture.

Devices: These two pieces are on new trends in devices:  Dell envisions a sustainable laptop allowing you to replace parts creating a design you could grow old with and Lenovo ThinkBook Plus Gen 3 Laptop.

On the other hand, we have this: BlackBerry phone with keyboard is not dead. Remember netbooks? They were great little devices. Here’s a piece on them: Netbooks: The Form Factor Time Forgot.

Cool: Here’s something fun: The Best of 404PageFound and Other Primitive ’90s Websites That Still Exist. I love DOOM, so: Is this one of the smallest playable DOOM devices? and Pocket-Sized Doom Is Actually Playable. Speaking of small things, we have this, A VM in your browser,  this Writing a simple 16 bit VM in less than 125 lines of C and this System/360 simulator. Also this: CHUNGUS 2 – A very powerful 1Hz Minecraft CPU.

Raspberry Pi: for Pi fans, here’s some good links:

Cloud and DevOps: here’s some things I found worthwhile in that space

IBM: Here are two good initiatives my employer is providing: Good probono program from IBM to help environmental groups  and A good initiative from IBM to help on the matter of Racial Justice.

Azure: I have been doing tons of research of Microsoft’s Azure and so I have many links on it here. Enjoy!

Kubernetes:  I have been doing some Kubernetes work too which lead to these links in

Finally, here’s some other useful links I didn’t want to lose: