Mastering New Technologies Takes Time

Things move fast in the IT industry. Half of the technologies I use today didn’t exist ten years ago. There’s a constant push to switch to new technologies.  But when it comes to technologies, I’m kind of conservative. I like proven technologies. The thing that makes me conservative is that mastering a technology takes a lot longer that we think. Most advocates of new technologies … Continue reading Mastering New Technologies Takes Time

Autonomy and Microservices

Discussions about monolith vs microservice are hotter than ever. Usually, a monolith is synonym for “big ball of mud” in these discussions. It of course needn’t be so. A modular monolith is perfectly possible. Also, microservices isn’t an entirely new idea either. As some says, it’s SOA done right. The usual argument in favor of microservices is that autonomy is a good thing: teams can … Continue reading Autonomy and Microservices

Do You Need an Architect?

Architects do typically three things: they own, they coordinate, and they mentor. As an owner, the architect maintains the integrity of the system at a high level. He designs the foundations, identifies tradeoffs, decides on essential changes. As a coordinator, the architect facilitates work and optimizes the exchange of information. He connects people, gather information, and plan activities. As a mentor, the architect provides the … Continue reading Do You Need an Architect?

Conceptual Integrity in Large Systems

The central argument of the Mythical Man Month from Fred Brooks is that conceptual integrity is the most important consideration in system design, and that conceptual integrity will only be achieved if the design comes from one, or a few resonant minds. I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain … Continue reading Conceptual Integrity in Large Systems

10 Tips to Fail with Enterprise Integration

If you want to make enterprise integration needlessly complicated, follow these tips. 1. Model poorly A poor model is always a nice way to make things more complicated than they should. Examples: You can name thing badly. You can model everyting as strings (key, list, etc.). Or you can reuse overly generic abstractions in multiple contexts instead of defining one abstraction per context. Or you … Continue reading 10 Tips to Fail with Enterprise Integration

Taming Size and Complexity

The only real problem with modern software is size and complexity. If we had a bigger brain able to apprehend and reason about software as a whole without omitting details, we wouldn’t have that many issues. Unfortunately, our mental abilities are limited, and as a consequence, we need to have ways to build software whose complexity is beyond our own analytical power. The same is … Continue reading Taming Size and Complexity

Software Evolution

Software evolution studies software engineering under the perspective of software maintenance and change management. The term was coined in the 70 after the seminal work of Lehman and his laws of software evolution. As such, software evolution is a topic as broad as software engineering itself – any aspect of software engineering (being a process, methodology, tool, or technique) can indeed be studied under the … Continue reading Software Evolution

Threat modeling: tools in practice

We’ve investigated two tools for our threat model. Here is an overview of both tools (from Microsoft) and our experience with them. Threat Modeling Tool The first tool supports system modelling with the definition of Entry Points, Trust Levels, Protected Resources, plus some general background information. Data Flows can be authored directory with the tool or imported from Visio. The tool main strength comes however … Continue reading Threat modeling: tools in practice