Hey there,
I find Eric Evans’ book on Domain-driven Design quite brilliant. It preceded the idea of microservices by ~8 years, which is alone incredible. Especially the chapter on strategic design, and the patterns explained there were very interesting to me. So I searched for a visual overview of them. When I found none, I drew this: Continue reading Domain-driven Design quick reference
For a while now I’ve been intending to add https support to the blog. Although it would have required a switch from the current hosting provider.
Now I’ve gladly realized that my hosting provider has done the switch to https for me, just at the time Google is enforcing it more vigorously. So I don’t have to bother. Many thanks HelpingHost!
All parts of BAPO[1]BAPO model explains how the business, architecture, process and organization should play with each other in a SW organization. I like it personally, as it helps me explain several things such as … Continue reading have a home turf of problems/aspects/challenges it can address efficiently. For instance, maintainability is best addressed in the architecture, rather than some complex maintenance processes or special teams designated in the organization. In most cases, modifiability is best first addressed in the business, where only the essential modifiability is prioritized and rest is eliminated to save on complexity. Knowhow management and regulations etc. are mostly best addressed in the organization and process areas. While some technical risks are best addressed in the architecture, I was surprised to hear of a case where the business people covered against a risk by just arranging an insurance, thereby relieving the architecture of the complexity. Continue reading BAPO imbalance
Footnotes
| ↑1 | BAPO model explains how the business, architecture, process and organization should play with each other in a SW organization. I like it personally, as it helps me explain several things such as Conway’s Law being an inverse interaction of architecture and organization. Check out the following document for details, or just Google it: Obbink, H., Müller, J., America, P., van Ommering, R., Muller, G., van der Sterren, W., & Wijnstra, J. G. (2000, August). COPA: A component-oriented platform architecting method for families of software-intensive electronic products. In Tutorial for the First Software Product Line Conference, Denver, Colorado. |
|---|
Hi there,
Some of you have probably noticed that there was a long delay in the posts. The reason was, as I indicated before, our move as a family to Switzerland. The move still tends to take most of my available time (ramping myself up in the new role as well as chores such as registration, insurance, finding daycare…), so I still cannot promise a regular rhythm of posts. In the meantime, I’d like to convey two observations about my posting rhythm. Continue reading The vicious cycle of delay
Anecdotal observations tell me that NIH (not invented here) is for the most part dying[1]I couldn’t find any studies examining reuse statistics yet, so please send them if you know about some., and the general level of software reuse has increased significantly in the last ten years: Continue reading Choosing SW for reuse
Footnotes
| ↑1 | I couldn’t find any studies examining reuse statistics yet, so please send them if you know about some. |
|---|
When I was a developer, I could work on a single task for several days. It was a bliss. When I started doing architecture, I noticed I had to do a lot of multi-tasking. At the very least, there will be multiple developers working on different tasks, whom I will support. Moreover, I need to talk to testers about testability, integration strategy etc. At the more senior end of the architect role, I need to talk to business stakeholders about product strategies and so on. And sometimes all this happens on a single day. Frank Buschmann wrote a nice article demonstrating A Week in the Life of an Architect, where he emphasizes keeping focus over the course of the week to ensure progress.
Thus, around the time I started architecting, I also started looking for some time management techniques: Continue reading Personal time management for the architect
Hello, it is somewhat embarrassing to have to send another heartbeat after such a short while. I’m mainly busy moving from Turkey to Switzerland, and my blog suffers from the interruption of the routine. Anyway, next post will come up in a few days. Stay tuned.
A good vision can be demotivating. An architect maintains a vision (north star) for a system that is hopefully shared by at least the key stakeholders. Every step of the evolution of the architecture is taken towards to this vision. However, there are also cases where the evolution is not advancing towards this vision: it can be stagnating, maybe even moving in another direction due to uncontrollable factors. “We could be so much better, but we are still faltering in this quicksand!” Such a situation is frustrating as hell. Continue reading The demotivation by vision
In a couple months, I’m going to switch to another division of my company, so I’m leaving my current project after 5+ years as an architect. The new architects of the project, the project leadership and I have thought about how to manage a successful transition. I’d like to share the measures we are currently implementing, and kindly ask for feedback on them and for new ideas, as well. Continue reading When an architect leaves his project
Hi there, I know it’s been awhile since the last post. So here a heartbeat to tell you: next post will come up in a few days, blog is alive and well. ;-)