Privacy as a valuable asset

The more precious something is, the more value it have. Classic examples are gold and diamond as status symbols since dawn of mankind.

Today, other things are valuable. A well known example is time, as this is a finite resource, even as we get older by each generation.

Another valuable thing is health, and this is mostly a result of your lifestyle.

A third valuable asset is privacy. Something privat that gets public will never be private again. You can be wealthy, loose a fortune and get rich again. With privacy, there is no way back. 

The premium product that people will buy in the future will give them more time, better health and more privacy, compare to their competitors product. The billion dollar question is what product and which company that will find the next Holy Graal.

Why digital is not enough

We are talking about the promises of IoT and a connected world. After todays traffic problems in Stockholm after the first snowfall this winter, I doubt IoT will give any benefits.

Photo by: Greger Wikstrand

Photo by: Greger Wikstrand

As usual, all drivers was surprised by the sudden winter. They were struck in the snow because the lack of winter tires and other cars without them.  Public transport was not either prepared for the heavy snowfall and passengers were waiting from busses and trains that was not arriving. 

You can check the weather forcast on you mobile device. You can check how well the public transport works in different apps. But people didn't.

Until the car decides themselfs if it's proper conditions to drive, I don't have a hope for IoT and connected devices. Humans are not smarter than their devices. 

What is the purpose with requirements?

When talking about collecting requirements, one of the challanges is what we mean with requirements and level of detail. The requirements we ask for should also be possible to verify.

Therefore, one of the questions is why we need the requirements. Some examples, but not all are:

A future roadmap to fulfill a business strategy. An example could be the requirements needed to make a roadmap to a digital business with more customer involvement, faster and cheaper compared to as today.

Start a large transformation program. The cost of one horse is a tricky question and IT-systems are alike. When we are talking about large transformation programs it's much much worse. We need requirements to plan och make estimates for something that takes several years to finalize.

Pre-study for a medium size project. This is what I would call high-level requirements, e.g. manage orders & invoices, manage customers or manage a product catalogue.

Project planning for a medium size project. This is when we need more detail requirements in order to make estimations for a descision to start a development and implementation.

If we are going to implement COTS or cloud services, we only need requirements for configuration and for integration to other systems

Software development to replace legacy is very difficult. You need to define all requirements needed to develop your own application. The huge problem is to assure that you don't forget any undocumented functionality in the existing application. The concept of minimum viable product will not work when replacing legacy systems.

Software development to develop a new type of application. This is manageble from a development perspective as you could add more functionality step by step. The challenge is to prepare for and capture for requirements not known, or not asked for, by the users.

Small agile project to add functionality in existing application. This is the paradise where users work together interactivly with developers. The big issue is that agile development is very hard to scale. More people involved and often diffentent skill-levels in participants are some of the challenges.

The combination of why and for what purpose we need requirements, makes it utterly important to be very precise of the definition of a requirement.

Is your design implementable?

One of the challenges with Enterprise Architecture and high-level design is that the solution looks good on paper, but is not possible to implement in reality. This is especially tough if we are trying some new types of solution, at least in this organisation.

The question is how we can do a litmus test of the architecture before we pour down to much money in the project. Lets take our high-level design from our example as a way to show this.

We said that we would use REST API for integration to the database and that we should use standards if possible. Within TM Forum*, there is an information model, i.e. SID**. An approach is to take part of this model to model users and their roles, the information that should reside in the SQL-database. A class diagram based on this model would be similar to the picture below.

Extract from Party domain within SID-model from TM Forum

Extract from Party domain within SID-model from TM Forum

The next step would then to define REST API for each of these classes and the result would be:


Is this possible to do like this? What is your opinion?  

If you search a little bit more on TM Forum site, you will find a lot of information about REST API and standard interfaces. There are design guidelines how to make these REST API based on SID information model, using a domain model approach. It also includes a number of defined interfaces, example of JSON code and lots of other valuable information

I have also setup a development environment on Azure to define the initial database tables and relations for the class diagram as way to see if the high-level design holds.

My answer to the first question is yes. The high-level design we have proposed is implementable. The other question is if the business model works and that is very hard to find out without a minimum viable product that you could offer to the market.

TM Forum is member association, originally for telecom but now for digital providers
** Shared Information Datamodel