My #1 motto currently is “Don’t do something until you understand what you’re doing“.
Software developers are often tasked with doing something they don’t understand. This is normal in the enterprise world, particularly where “segregation of duties” is fashionable. When requirements are hashed out between business people and requirement engineers, designs between requirement engineers and architects, and implementation concepts between those architects and product responsibles – the developer is mostly invited very late to the party. The developer is put under pressure to deliver by the entire enterprise software delivery apparatus and if the developer then starts asking questions, this invariably is “frowned” upon by the powers that be. This pressure psychology automatically stops developers asking necessary questions and a culture of “just do it” takes over. The results are unsatisfactory for everyone – the delivery quality suffers and developers do not learn and grow as much as they could to satisfy the needs of the larger corporation.
If everyone tried to work by this motto, and let work by this motto, then I’m sure IT projects would be more successful.
Personally i make every effort to really understand what i’m doing, and acting as scrum master or in roles where work is prepared for others, i put making things understandable for others at the top of my agenda.
Building a software application is analogous to the construction of a building in cyberspace. It progresses line by line, as opposed to brick by brick.
Last night, i came across a discussion thread on firstname.lastname@example.org
about how Email is unsecurable. This spiked my attention because in designing TDMX I came to the same conclusion. Some people propose a replacement for email, others want to “stitch” up the holes with incremental improvements. I tend to agree with the side which wants to make incremental fixes to standard email – taking the standard route through IETF.
Designing TDMX from the ground up as a secure messaging system is not contradictory to my feeling that email should be patched further. My point is that email is being used in many corporations where it is clearly better to not use email at all – when applications want to communicate with applications. For consumer to consumer or business to consumer communication, email security needs to be improved, but true end2end security is not even wanted ( See my previous blog entry ).
My next post will be an idea mentioned here about creating a email address to PGP key resolution service which could increase the usability of secure email. Who knows, maybe someone from IETF can take this up as a new draft!
I’m proud to announce the birth of SMT – Secure Messaging Transport. This specification is about a secure asynchronous transport mechanism – think of email for business applications.
This is currently just a concept waiting to be taken to a whole new level.
When a process is modeled in IT systems, it is normally designed with a large set of assumptions about the real world. The assumptions are just that – assumptions and sometimes wrong or incomplete. This leads to processes which do not “support” the full complexity of the real world. As a consequence, operational personal can spend a significant effort on “troubleshooting” the IT systems which are impacted by the process.
For instance – an order fulfillment process does not support the order to be cancelled after a certain point in the process, where in reality a customer can still exceptionally cancel his order through contacting the support staff and escalation. The IT system process will run to completion – requiring cleanup of the cancellation afterwards.
I call this the “Process Reality Disconnection”. It can make an organization incur significant running costs. It is worth specifying and implementing compensating / exceptional processes in IT systems with well defined pre and post conditions of each process outcome, because real world processes are always more complicated than initially assumed.
The DomainNameService (DNS) is arguably the most important internet service in existence today. Without it, the internet would not work as it does today, not email, not web browsing, nada. DNS is what gives a logical “name” to the “internet address” which every device attached to the internet has. Only in the most security conscious environments, where all forms of DNS attacks need to be avoided, do administrators setup collaboration between internet attached devices using IP addresses alone – forgoing DNS. For example enterprise VPNs and Telco equipment. This practice boils down to hardwiring devices or applications to each others’ physical internet location. This brings security at the high cost of maintenance and possibly reduced redundancy ( through lack of DNS load balancing ).
The predominant internet address “type” today is IPv4 addressing, the usual 4 byte address – like 10.243.14.2. The transition to a newer IPv6 address format is currently underway – or more accurately, the build up of a parallel internet which uses IPv6 addressing is underway. The IPv6 address is a 16byte construct – 4 times longer than the IPv4 address.
An IP address is effectively a topological address, or a geographic address in the internet v4 or v6 space. Like a postal address it is an indicator of location. Making an analogy to fixnet telecommunications, the IP address is the equivalent to a “geographic” phone number – the old PCM analog type – where each digit or set of digits brings the addressed payloads a bit closer to their final destination. In a mobile telecommunications context, the IP address has similarities to a Mobile phone’s IMSI, where the telephone number is actually a logical “name” ( albeit in the “phone” numbering scheme ) which the telco network looks up in a HLR ( analogy to DNS ) to find the IMSI and ultimately the mobile device’s position in the mobile network. With digital (including mobile) telephony, phone numbers have become names which some invisible telco internal DNS maps to some invisible address which routes calls to the physical phone equipment. Before smartphones came along, people had to remember phone numbers. At the best of times, 10 digit phone numbers were at the limit of what people could remember – maybe for one or two special numbers – parents, children etc. Also due to the continued use of “geographical” phone numbers even when digital switching was introduced – the “local area code” could be ignored – making most phone numbers to remember only 7 digits long. Todays smartphones and their contact applications like Whatsapp provide directory services ( aka DNS) from people’s names to phone numbers. People don’t have to remember any phonenumbers anymore.
My point is that the cost of not using DNS for security sensitive installations will increase with IPv6 due to the IP address length increase – because of the human factors which this brings with it. Nobody would ever be able to remember let alone type correctly a phonenumber of double length ( let alone 4x). An IPv6 address entered incorrectly into some configuration will need disproportionately more effort to recognize as incorrect because the address has less inherent meaning to the administrator. DNS itself is just as important as before in any case. Maybe DNSSEC will provide the solution.
If you want to your company to provide the best customer support in whatever industry you are in, you should build your own tools and put them in the hands of your customer supporting personal.
Figure out what you want to be the best at and build your optimal solution for this specific purpose. Use and integrate with Commercial-Off-The-Shelf COTS tools for parts of the business which should be standardized or which cannot differentiate you from your competitors.
The technology which is available these days to produce custom solutions is extremely powerful and well established. Cloud services and providers together with open source technologies provide a application development platform which can be used to make what you want very quickly in a capacity which fits your requirements – no problem.
The decision about “Build vs. Buy” should not be about about “Time to Market”. If you want “Time to Market” standardize the way you build and bring products to the market. Take Amazon AWS as an example. It blows my mind, every time Amazon brings out a new service fully integrated into it’s product portfolio.
With the today’s changed technology landscape, the time which it takes to bring a custom solution into operation becomes limited by whether you can formulate what you want well enough to implement – not whether you can implement. Time to market of custom solutions is bounded not anymore by development time, but by requirement eliciting time.