If I Was Only in It for the Money - A Business Idea for a Startup

Cover of The Mothers of Invention album We're Only in It for the Money

If I was only in it for the money, I cannot think of a better business than taking my share of the public sector ITC projects in Finland.

Take for instance this € 90 million project that I found from the Facebook updates of my friends (Thanks for the links Ville, Vessi et al): Helsinki Region Transport (HSL) is purchasing a new ticketing and information system for € 60 million (plus € 30 million for maintenance) in a project lasting five years. It's not the only one of its kind. There are plenty of others but this is the latest future failure.

Alas, they have fixed budget, schedule and scope in the contract. As everyone in the business knows this means that it has been fixed that budget, schedule and scope will grow. They will find out from day one that some show stopper features are missing from scope and because everything else is required too they need more time and money to build it all. The vendor will not accept anything removed from the scope. Or at least from any of the monies they have been promised for the features.

I guess that the Facebook comment stating that it will cost around one guggenheim (€ 140 million w/o maintenance) to build the system is quite an accurate estimate.

The funniest thing in this particular case (if it was funny, which it is not because it is tax money, my money, they are playing with) is that during the tender process the buyer went to court with one of the vendors with a bid who claimed that they were dropped with unjustness because the buyer claimed that there cannot be SOA without ESB. So we now have a court solution that you do not need to have an ESB in your SOA! Remember this if anyone brings any of those ESB things nearby.

Market Court solution in case MAO:126/11 translated by Google

So, to get into some serious money pop up a faustian lean startup generating money from public waterfall projects. Here's the plan:

• Make an offer for some public tender, 
• Pivot in the court if you do not win,
• Pivot again using the compensation from they court to build up a new bid for another tender and
• Repeat until successful.
• Then just wait for this certain nasty dude to appear and claim your soul.

Tell Me All I Know Already API

Have you ever had the joy of using a Tell Me All I Know Already API? It is usually an interface to some business system holding a lot of business data inside its databases. It is perhaps a bit obese and oldfashioned and therefore also maybe a little lonely. Therefore it is always delighted to have lengthy conversations with anyone willing to talk to it. Something like this:

You: Hi, Tell Me All I Know Already API! Could I have five oranges delivered to my home address XYZ, please.
Tell Me All I Know Already API: Hi You! What is the ID of the "oranges"?
You: Can you tell me what IDs you have?
TMAIKAA: Oh, oranges are 5 and apples are 8.
You: OK, could I have five of the items with id 5 delivered to my home address XYZ, please.
TMAIKAA: What do you mean with 5? Can you also give the product name, please.
You: OK, could I have five oranges with ID 5 delivered to my home address XYZ, please.
TMAIKAA: What is the ID of your home address XYZ?
You: Can you tell me what is the ID of my home address XYZ?
TMAIKAA: Yea, it has ID 3.
You: OK, could I have five oranges with ID 5 delivered to address ID 3, please.
TMAIKAA: Can you also give me the address of the address ID 3, please.
You: OK, could I hanve five oranges with ID 5 delivered to address ID 3 (XYZ ), please.
TMAIKAA: Hey, that address and ID do not match, could you try again.
[… ad nauseam...]

If a system has this kind of API, the discussions with the system's tech support also bear resemblance to the above.

What other API personalities have you seen?

On Architecture

From "Planning a Computer System - Project Stretch" [PDF]

Fred Brooks coined the term computer architecture as early as in the 1950s and ever since it has been a favorite in the computing circles and much has been written about it. The building analogue has been prevalent ever since and misused and stretched so much that most of the laws of physics and humanity must have been broken on the way. So I'll stretch it some more.

Currently in software the term architecture most commonly means a power point illustration of boxes and arrows with names of applications, products or imagined layers of software construction inside them. And if architecture is mentioned in a discussion the very definition of Mr. Brooks for architecture - the determining the needs of the user - is not mentioned at all. Architecture is the comfort zone of the techies who have been promoted away from the programming tasks in the corporate ladder but in a stairway not leading to the penthouse where the business people do the world domination thing but in the other one leading to the dusty attic of IT management.

This is not the "where the rubber meets the road" architecture but architecture where someone not part of the problem (the biz) or the solution (the dev) tries to affect the result.This might be well meaning or malign but usually is done too far away from those who are actually accountable for their deeds (the biz and the dev).

A beautiful day in Itä-Pasila.

Architectural styles are subject to fashion and trends like the clothing industry. And just like with high street fashion the garment that is most fashionable today is just a heartbeat away from being so totally out of fashion. This can also happen in the real world architecture of buildings and cityscapes.

The bridge integrates two areas in the top layer of the architecture and isolates them from the lower layer.

In the 1970s the eastbound neighboring country of Finland was not Russia but the Soviet Union. And that's where the architectural ideas came to Finland in the 1970s. The Itä-Pasila region of Helsinki built then looks like stuff made behind the iron curtain.

Here the architecture allows four paths to the other side - all not very inviting. But at least you have a choice.

The trend then seemed to be a 2-tier architecture where the system is divided in two layers: the bottom or "back end" layer is for the heavy lifting: cars and lorries transporting stuff. The second tier, the "front end" is then for more slow paced and lightweight traffic of more lightweight units called persons. However, these two layers need heavy integration and this is implemented with lifts, ramps and staircases between the layers.

In a flat architecture it would not matter which way you should walk if you want to go around the building in the picture. In this multilayer architecture you must make your navigational decision at this point.

The whole thing is built to serve the person units and their needs. That usually means moving from a place to another one and enjoy the company of other person units meeting them in some designated areas in the front end tier. The two tier architecture was said to enable this as the person units can freely move on the top tier without the impedance mismatch of mixing their paths to the remarkably faster moving cars. Something that the architects did not take into account was that the person units had to visit the bottom tier quite often as they use the cars to move about from region to another. And that they are quite good at finding routes from A to B in a two dimensional surface but really suck in the task if they have to move in a three dimensional surface consisting of two levels where the navigational rules of the 2D environment do not apply.

Good naming conventions are a must. This indoor hallway with a concrete ceiling is named "Aurinkoraitti" which translates to "Sun Passage".

The architects seem to have this obsession with organizing stuff in layers and making barriers between them but it is more natural to people when things are not that well in order as long as they are simple and the scale of things is convenient. So perhaps also in computing making the small decisions right, keeping the needs of the user in mind all the time and having the right scale is more important than forcing everything to some artificial layers in a heavy foundation framework based on the latest sales pitches of large IT vendors.

The lift on the left comes from a parking hall underground straight to the top layer where there is nothing of interest but from where you can descend to lower levels with either a staircase or a ramp or take the bridge crossing the road below.

Can Toyoda Navigate Back to the Toyota Way?

Yesterday the Finnish Broadcasting Company showed a BBC feature Total Recall: The Toyota Story on Toyota's current huge problems on reputation and quality mostly related to the deadly accidents caused by "sudden unintended acceleration" problems with Toyota and Lexus vehicles.

The presentation of the Toyota Way and the Toyota Production System (TPS) would be good material for any introductory course on Your Toyotaish Method Of The Day. It goes in some ten minutes through the basic concepts: genchi genbutsu or "go and see", chosen meaning challenge or long term vision, teamwork, sonkei soncho or respect and humility and finally kaizen or continuous improvement. There is also about the history of the TPS showing how it was actually innovated from seeing the US grocery store chain Piggly Wiggly and how it operated with minimum inventory and a Just In Time system. Not to forget the hilarious company videos.

Rest of the programme is mostly on whether the Toyota was in the know of the problems with sudden unintended acceleration and hiding the problems or not. But there is also some analysis on the reasons why Toyota faced these problems. The biggest mistake seems to be changing the chosen of manufacturing the best quality cars to ruling the market and maximizing growth which resulted in some very basic mistakes all the LeanBanGuard consultants out there lecture about:

• Toyota started to look for cheaper unit costs with parts subcontractors in order to cut those costs by 30% and resulting in poor quality using subcontractors not up to the standards of the long term partners it had been using for decades.
• Toyota wanted to hugely grow volumes (increase velocity if you want) but had to trade its principles of "go and see" and kaizen for that.

So it seems that Toyota has a sudden intended acceleration problem to fix and it has to navigate back to the sustainable pace of the original Toyota Way. This feels very familiar to me as it seems this has happened in my IT endeavors more than often. Not that I have ever been on the right path myself. But maybe with some more genchi genbutsu and kaizen I'll get there some day.

(If you are in Finland you can catch the show in Yle Areena for some more days)

Business Process Orchestration - The Original Soundtrack

The Mad Men had their presentation. The CIO was impressed and decided to buy the Orchestration System™. After all it promised to remove the programming tasks from the organization leaving mere process configuration to do whenever changes were required. And the business changes constantly. Everyone knows that. The deal was signed and the license fee calling to mind a phone number was paid to the vendor. The system was installed from the DVD. The Business Managers configured the business processes. Everything was ready to just switch it all to production.

But the slideware promises did not quite hold. The orchestration system was just a tabula rasa: an empty development environment and a runtime engine. It was also a closed system that only a few people in the world knew how to master compared to standard open technologies like the ones behind REST interfaces.

The configuration task that was the responsibility of the Business Managers turned out to be a programming task they had no skills to handle. And a programming task to be accomplished with a visual programming language inferior not only to any contemporary development platform but also to anything from the 1970's. A development platform offering no mechanisms for proper composition to modules or layers of abstraction. And therefore there were no third party libraries of any kind whatsoever either.

The source code was saved in XML and thus was incomprehensible to any version control system around. All testing had to be done in a full blown live environment and manually as there was no support for unit testing of components. Remember: the system did not support any composition so there were no units to test. No automated tests means also no continuous integration.

But it is now the date that we have to go to production. So we can read from the Gantt Chart of the Project Manager. It is also the milestone to make the fat bonus tied to the project. So we turn on the system. And this is what we hear: Business Process Orchestration - The Original Soundtrack.

I hope that whenever anyone hears the words "Business Process Orchestration" this "Business Process Orchestration - The Original Soundtrack" starts to play in their heads. Many lives would be saved. Please help me to accomplish this altruistic task by playing this soundtrack whenever someone mentions the O word!

As A User I Want To...

User Stories, especially if used in a very formal way, are much criticized by my colleagues. One point is that the user (in any role) most probably does not want to use your system but just to get it over with. So, whenever someone says "As a (role) I want to" it has become somewhat of a meme to say:

As a user I want to drink piña colada in a swimming pool

I assumed that this was true but I wanted to be sure and made some empirical studies and it in fact is so.

Photo: Heikki Pora

Rituals of Hypocritical Scrum

The Certified Scrum Master training does not make anyone a great Scrum Master. News at 11. But one thing I think it makes is better agile team members. I like to suggest CSM training to each team member I work with. The two days of Scrum training usually do not give much new about the roles, artifacts or ceremonies of Scrum to the attendees. But it still makes a difference.

As it says in Scrum Alliance introduction to Scrum "The Scrum framework is deceptively simple." In fact it is quite possible to start up doing a sort of hypocritical Scrum with all the ceremonies in place: plannings, dailies, sprint reviews and perhaps even retrospects. And fail. With hypocritical I mean Scrum without touching the core of Scrum - its principles. The ceremonies of Scrum become mere empty rituals without some understanding of the principles below them.

The principles of Scrum are in Agile Manifesto and in Toyota Product Development System. On a higher level it is in embracing change and concentrating on producing value. On method level it is in using pull systems and JIT, removing waste and doing continuous improvement of the system. 

Someone just tweeted that when you write code you should know at least one level of abstraction below the level at which you operate. For instance when writing C it's good to understand about the call stack and dynamic and static linking to libraries and optimizations at compile time. The same goes with Scrum. It is not enough to know the secret handshake. You must understand the things that can make your process work. And the same goes with Kanban, XP or other agile process models.

The CSM training does not teach you all the principles of Scrum. But it does one thing that is very important. It demonstrates some of those principles at work with some very simple exercises and thus usually gives a some kind of incurable agile brain tumor to most of the participants.

I find myself often in the empty rituals mode. I envy my colleagues like Kaira who seems to be able to work on the principles level all the time in his daily work. I just have to train my nose to smell my own odors to keep up.