Findings and thingies

Whilst some people employ lightweight modelling techniques such as C4, most diagrams in use today, are what I call, somewhat derogatorily, masala diagrams. No hard feelings, I call my own diagrams like this. Why masala? Because they are informal; they cover multiple dimensions at once, they may be both structural and behavioural, logical and physical. They are often a mishmash of the 4+1 architectural model’s views.

I must admit that I never liked UML for describing systems architecture. I can't name any special reason for this. However, I really like the term masala diagrams for diagrams illustrated in the linked article. From my point of view these kinds of diagrams feed the needs of the separate roles in a business context. And somehow everybody looking at these kind of diagrams gets a grasp of how the system is architected and what its intension is.

Even though I still see why UML has been appealing in the first place to describe business models.

I've written about the maps of Stephane Eyskens before. I must admit that I did not follow up on the following publishing's by him. Today I just noticed that he added another map to his portfolio.

The Azure Data Architecture Map - Microsoft Tech Community

It is pretty neat that he simply put a link to all of his maps in his most recent post so that one has all information in one place.

The same “brain drain” applies to any potential distractor even when they aren’t actively distracting us. Research in cognitive psychology tells us that we automatically pay attention to things that are habitually relevant to us, even when we are focused on something else.

Maybe it's time to get rid of even more apps on your smartphone.

Today I was facing the challenge that an import of a BACPAC file did not finish in a reasonable amount of time.

The process simply remained unchanged for about 4 hours in the state you can see in the above screenshot.

After investigating this further I found the money quote in the Microsoft documentation [1].

The Azure SQL Database Import/Export service provides a limited number of compute virtual machines (VMs) per region to process import and export operations. The compute VMs are hosted per region to make sure that the import or export avoids cross-region bandwidth delays and charges. If too many requests are made at the same time in the same region, significant delays can occur in processing the operations. The time that's required to complete requests can vary from a few seconds to many hours.

The documentation also states that an import will be cancelled if it is not processed within four days.

Unfortunately the Azure portal does not offer an option to cancel an import out of the box. For this you need to use the PowerShell (inside the portal). You can find a detailed description for this here.

To speed things up you can perform this import using your local SQL Server Management Studio (SSMS). For this simply refer to the necessary steps in [3] specifically section »Importing a data-tier application in SQL Server Management Studio«. Of course this is only an option if your internet connection is sufficient for the amount of data that needs to be moved. If not you can still deploy an Azure VM and run the import process from there.

Resources

1. Import and export of a database takes a long time - Azure SQL Database | Microsoft Docs
2. How to cancel Azure SQL Database Import or Export operation - Microsoft Tech Community
3. An introduction to Data-Tier applications in SQL Server - WayBack

Most important, it’s time for a new mindset. Businesses should focus more on building toward a better future and less on assessing where things are. Making this shift means embracing the unknown and accepting complexity.

This. Don't ask your employees once a year what they think about their professional environment. Talk to them, look where things can be improved. And work together with them to tackle these issues.

In an interview with NPR, Facebook's director of privacy and public policy Steve Satterfield said Apple's forthcoming alert is an attempt to undercut the business model used by Facebook and other ad-supported free apps.

I really hope that this will create a backclash for Facebook because people will start to recognize that they are not the users but the product of this plattform ("If You're Not Paying For It, You Become The Product").

This "always-open self" Wells speaks of, though admirable, doesn’t always guarantee a happy time of things. Often it is exhausting. Often it is heartbreaking. But no worthwhile life ever had it different. Sic transit Gloria Mundi.

Nothing to add from my side...

To become great at technology strategy, start by getting good at making boring plans. Get clear about the problem you are overcoming with your plans.

As mentioned before it is good to use boring technology but it is also a good idea to make boring plans.

So I’m making a case here that you should tend to prefer mature things, and you should try not to use too many things.

But it’s not an absolute principle. Obviously sometimes it does make sense to add new technology to your stack. And it can even make sense to use a weird new thing.

It is always good to stick to/use technology which has a proven trackrecord and is known well by you. But as always your mileage may vary and as always the answer in technology is: "It depends".

What you really want is a repeatable, automatic pipeline that takes your code, merges it with everyone else's, runs some tests, deploys it to a test server, runs some more testing and validation, then automatically promotes it to production once you know it works.

Simply obey the rule that you never ever should do use this tool in any production environment.