Custom software development blues

There are two main challenges with customer software development, compared to using package based software.

The first one is how to be ready in time, on budget and with the fulfilment of requirements. This is especially true when you develop a system that would replace something existing. 

The other is more long term and how to build a bespoke solution that could be maintained over the years. If it’s a bigger investment and core business, you will need to develop a solution that there for many years.

On the other and, package based solution with to much customer based code inside is also very cumbersome to maintain, so as a decision maker you are between a rock and a hard place.

Short term goals

When starting a software development project, you need to assure that you cover most of the requirements, both functional and non-functional, in the planning phase. I have seen a lot of examples where the initial estimates were a small fraction of the total cost. Therefore, as a project manager, you have to ask how the lead developer have assured that they don’t miss any requirements. 

Long term goals

In order to fullfil the long term goals of maintainability and compatibility of your software, you need to have some development guidelines in place. They should assure that; the code is readable; not to long units of code; not to complex code and have re-usable part of code instead of copied blocks of code. 

There are other guidelines for assuring quality in software, so these above are just an example.

These guidelines must be enforced from the beginning of the project, otherwise the technical debt will soon be to high. If running an agile project, these guidelines must also be part of each sprint, otherwise they will be forgotten.

Watch more

For more inspiration, watch the videos ”Like buying a horse” and "Fix it with duct tejp" at Architecture Corner on Youtube.

Will GDPR hit your small business?

I'm an employed consultant, bu I also have a side business in Sweden were I'm a sole owner of a film production company. This is the reason why I have to solve how to handle GPPR for myself, and not only for larger clients.

What I found out recently is that the knowledge about GDPR in smaller companies is more or less non-existent, and some of the industry associations are neither so well informed of the consequences of the new legislation.

As a small business owner, it's your responsibility as well as the CEO of a larger company, if you collect sensitive personal data. 

To solve my own issues with GDPR, I take an enterprise architecture approach, and define four different business use-cases as a starting point for the preparations. The question is how you should act after GDPR is in place in May 2018 in each of these for cases?  

FX-00347-0142 (medium).jpg

The four different business use cases are 

  • Street photography
  • Wedding photography
  • Child photography
  • Film production

What I have to do is find out how legislation impacts my workflow and storage of personal information in each case. Does it sound familiar?

Business use-case for street photographer

You have a professional business, and have a large number of photographs taken at a Pride festival in Stockholm (a public place). When people can be identified and Pride is about sexual orientation and opinions about this, I think the images can be considered as sensitive personal data.

Business use-case for wedding photography

You are a professional photographer and a year ago you had a mission to photograph a wedding.

Now the groom comes and says he wants all the pictures from the wedding, and refers to the right to transfer personal data in GDPR.

Two days later comes a very upset bride who talks that they are in divorce and she wants all the pictures from the wedding to be erased, with the right to be forgotten in GDPR.

Business use-case for an employed professional photographer

You are photographing mothers and children as a hobby, and your are invoicing through a company that pays your salary.

One day, you will receive an email from someone who tells you that he copied your entire image archive in a security breach at your home, and threatens to publish all images online if you do not pay a random. He also sent some pictures of minors you’ve taken to show that you that he is serious.

Business use-case as a film producer

You own a production company that produces a feature film. You have both employed and hired self-employed persons from several Nordic countries.

Now, the financiers of the movie want to find out how to make sure you follow GDPR, in order not to get some unpleasant surprises that can delay or increase cost for the movie, and in the worst case prevent distribution of the movie.

Bad software kills


Bad software development habits are like smoking cigarettes. 

The biggest challange for the organisation is to understand that those habits are as leathal to IT as smoking is to your lungs.

Your companys IT-systems will get a massive technical dept, and it will be to late to save them, if you don’t take action now.

Lack of disease insight make ad-hoc programming without design comparable to smoking a parties. You feel good and having a joyful evening. Eventually you cough a little in the morning the day after, but nothing serious.

Today, in many organisations, the health awerness for IT systems, are like the public knowledge of dangers of smoking in the fifthties. A time when smoking was glamourous.

 In order to avoid technical debt building up like tar in your lungs, you have to be aware and understand that bad software kills IT-systems. Not today, but slowly over time.

For an architect, in a organisation with lack of disease insight, the first step is to build up an awareness of the problem together with the major stakeholders.




The naked architect

I’m not thinking of Jamie Oliver and the naked chef, but instead H.C. Andersens classic story.

Today, lots of people in the industry put up the title Architect on their business card or profile. The problem with this approach from some architects, is my opinon threefold.

  1. They can’t define what they mean with Architecture and the benefits with it.
  2. They don’t have a described method of how to do Architecture, instead it is ad-hoc work and random activities.
  3. They only know architecture theory, but not how to apply it in the in the real world by using prior art and examples.

So when recruiting or hiring an Enterprise Architect, make sure his not naked, but have the right outfit for the job. 

If you are an Enterprise architect you should be able to:

  • Define what architecture is for you and the benefits you get from it
  • Describe the method you to make architecture work, according to above description of architecture and benefits
  • Be able to show how to apply this in real world examples

The below image is from an interview for a client in Sweden where I showed how to make a high level enterprise architecture (organisation, process, information, IT) in their type of business in 45 minutes.